Production Line: Digital Talent
Production Line: Digital Talent
Author: Pablo (Production Line Architect) Based on: Elena's Production Line Architecture Blueprint Version: 1.0 Date: 2026-03-18 Status: Active
1. Identity
| Field | Value |
|---|---|
| Line name | digital-talent |
| Purpose | Produce configured, tested digital talent for SMB clients |
| Product types | Any Claude Code agent: EA, data governance, compliance, project management, DevOps, etc. |
| Target segment | SMBs who need specialist capabilities but cannot justify a full-time hire |
2. What This Line Produces
A standalone digital talent -- a Claude Code agent deployed to the client repository with:
Standard Deliverable Set (all products)
| Artifact | Description |
|---|---|
| CLAUDE.md | Client-specific agent configuration: role definition, workspace rules, conventions, model selection |
| .claude/commands/*.md | Domain-specific skill commands tailored to client methodology and outputs |
| .claude/commands/templates/ | Output templates appropriate to the product domain |
| content-in/ | Reference materials: methodology docs, domain knowledge, checklists |
| workflows/ | Orchestration workflows (if the product uses orchestration) |
| Client documentation | User guide, configuration guide, skill reference |
Capabilities Vary by Product Type
The specific capabilities are defined in the work order, not in this line. Examples:
| Product Type | Example Capabilities |
|---|---|
| Enterprise Architecture | Requirements capture, solution design, diagram generation, decision records, validation |
| Data Governance | Data discovery, classification, lineage mapping, quality rules, governance reporting |
| Compliance | Policy analysis, gap assessment, audit preparation, evidence collection |
| Project Management | Planning, status tracking, risk assessment, stakeholder reporting |
3. Pipeline
INTAKE -> REQUIREMENTS -> PATTERN SELECT -> BUILD -> QA GATE -> DEPLOY -> DELIVER -> BILLING -> FEEDBACK
Nine stages, eight blocking gates. See stages/ for details. Follows Elena's Production Line Architecture Blueprint.
4. Customization Dimensions
What varies per work order -- the dials Pablo turns when configuring a new digital talent instance.
| Dimension | What Varies | Examples |
|---|---|---|
| Product type | Domain and capability set | EA agent, data governance agent, compliance agent |
| Domain skills | The specific skills built into .claude/commands/ | EA: orientation, solution, diagrams. Data: discovery, lineage, quality |
| Methodology | Client's domain framework | TOGAF, COBIT, ISO 27001, PMBOK, custom |
| Language | Working language for all deliverables | English, French Canadian, Spanish |
| Repository/tool integration | Client's existing domain tool | LeanIX, Ardoq, Collibra, Jira, none |
| Publication target | Where outputs are published | Confluence, SharePoint, Notion, markdown |
| Template library | Domain-specific output templates | Draw.io diagrams, schemas, report templates |
| Model selection | Cost/quality preference | Haiku for execution, Sonnet for analysis, Opus for orchestration |
| Quality thresholds | Client-specific quality criteria | Tool completeness scores, coverage metrics |
| Naming conventions | Client artifact naming | Deliverable codes, request numbering, decision format |
5. Standard vs. Custom Components
Standard Components (reused across all products)
| Component | Description |
|---|---|
| Agent architecture | CLAUDE.md structure, command layout, workspace conventions |
| Skill template | Markdown skill template with standard sections (frontmatter, inputs, processing, outputs, quality checks) |
| Verification framework | Structural checks, smoke tests, CLAUDE.md consistency |
| Documentation templates | User guide, config guide, and skill reference card templates |
| Model selection guidance | Cost-optimization matrix for model routing |
| Quality gate framework | Gate criteria structure and scoring rubric |
Custom Components (built per work order)
| Component | Description |
|---|---|
| Domain skills | Skills specific to the product type, built from solution spec |
| Methodology references | Client domain framework documentation loaded into content-in/ |
| Tool integration | Client tool meta-model, validation rules, API integration |
| Output templates | Templates matching client visual and document standards |
| Publication pipeline | Integration with client documentation platform |
| Orchestration | Product-specific orchestrator skill (if the workflow requires one) |
| Naming conventions | Client artifact codes, request numbering, file naming |
| Language configuration | All prompts, templates, and outputs in client language |
6. Capacity
| Metric | Estimate |
|---|---|
| New product type, first client | 5-8 days |
| Same product type, new client | 1-3 days (clone + customize) |
| QA cycle | 1-2 days |
| Deployment | 0.5 day |
7. Work Orders
Each client engagement creates a work order in production-lines/orders/{client-slug}/. The work order contains all product-specific and client-specific configuration that this generic line needs to produce the talent.
See production-lines/orders/ for active and completed work orders.
9. Request Type Routing
Not all requests go through this production line. Four request types exist — the factory handles Types 1-3. Type 4 goes directly to the deployed talent.
| Type | Description | Route | Pipeline |
|---|---|---|---|
| Type 1 | New talent, new client | Full pipeline | All 9 stages |
| Type 2 | New talent, existing client | Full pipeline, abbreviated intake | All 9 stages — Stage 1 pulls from client registry instead of full discovery |
| Type 3 | Enhancement to deployed talent | Lightweight pipeline | Requirements → Build → QA → Deploy (skip intake, pattern selection, billing, feedback) |
| Type 4 | Work request for deployed talent | Not this line | Goes directly to the deployed talent in the client environment |
How to Route
Is this about BUILDING or CHANGING a digital talent?
YES → Is the client new?
YES → Type 1 (full pipeline, full intake)
NO → Is this a NEW talent for the client?
YES → Type 2 (full pipeline, abbreviated intake)
NO → Type 3 (enhancement — delta pipeline)
NO → Type 4 (talent does the work — factory not involved)
Type 2: Existing Client Path
When the client already has a profile in production-lines/clients/{client-slug}/:
- Skip discovery session (1.1) — client context is known
- Skip organizational questions in intake (1.2) — pull from
profile.md - Focus intake on the new product type and any changes since last engagement
- Still requires full requirements, pattern selection, build, QA, deploy, deliver
Type 3: Enhancement Path
When the client requests changes to an already-deployed talent:
- Start with a delta requirements capture — what's changing and why
- Skip pattern selection (unless the enhancement introduces a new pattern)
- Build only the changed components
- QA covers regression (existing capabilities still work) + new capability validation
- Deploy as an update to the existing talent repository
Type 4: Not Our Problem (In a Good Way)
Type 4 means the talent is working. The client is using the talent to do real work — requirements capture, analysis, design, etc. This is the success case. The factory built it, the talent does it.
Example: "Capture requirements for Azure Dataset" → the deployed EA talent runs /ea-exigences-intrant, not the factory.
Client Context Registry
Client profiles persist at production-lines/clients/{client-slug}/ to support Type 2 abbreviated intake and track deployments across engagements.
See TFD-0006 for the decision record.
8. Dependencies
| Dependency | Source | Status |
|---|---|---|
| Pattern catalog | Ada (Agentic Pattern Designer) | Available |
| Production line blueprint | Elena (Enterprise Architect) | Available |
| QA framework | Quinn (QA Engineer) | Available |
| Deployment standards | Diego (Deployment Specialist) | Available |
| Client intake process | Camille (Client Intake Manager) | Available |
| Naming conventions | Nora (Nomenclature Specialist) | Available |