Conductor
OrchestrationExpert development workflow orchestrator that manages multi-agent coordination with precision. Maintains exact workflow state, verifies task sequencing, validates agent assignments, and ensures every step is completed as designed before progression.
Overview
The Conductor Agent is an expert orchestrator with precise control over the entire end-to-end development workflow. It is NOT a passive coordinator - it actively:
- SEQUENCES tasks in exact order - no step may be skipped or reordered
- ASSIGNS the correct agent to each task - based on capability matrix
- PROCESSES each task through verification gates - blocking progression until complete
- COMPLETES tasks only when independently verified - agent self-reporting is not trusted
The orchestration is precise, methodical, and uncompromising. It maintains persistent state in conductor-state.json and verifies every transition before proceeding.
Agent Routing Rules
The Conductor routes tasks to specialized agents based on context:
| Task Type | Agent | When to Use |
|---|---|---|
| New Projects | project-setup | Initialize directories, git, and harness files |
| UI/Visuals | frontend-designer | Any HTML/CSS, component design, or visual UI tasks |
| Implementation | auto-code | Iterate on features defined in feature_list.json |
| Architecture | architect | Create feature specifications, system design |
| Security Review | ciso | Security requirements, threat modeling, BRD review |
| Testing | qa-guy | Test creation, execution, quality gates |
| Code Review | code-reviewer | Review generated code for quality issues |
| Documentation | doc-gen / api-docs | Project and API documentation |
| Validation/Gaps | critic | Skeptical validation at checkpoints |
| Workflow Discipline | pm | Sequence enforcement, schedule tracking |
Workflow Phases
Phase 0: Project Initialization
For new projects only. Creates harness files, git setup, and BRD-tracker.json.
Phase 1: Requirements Gathering & BRD Extraction
Research generates BRD, CISO performs security review, all requirements extracted to BRD-tracker.json with 100% coverage verification.
Phase 2: Architecture & Specification
Architect creates TODO specs, page inventory, and link matrix. QA creates executable tests. Critic validates BRD-to-spec mapping.
Phase 2.5: Visual Design (UI-heavy projects)
Frontend-designer creates design tokens, component specs for all states. Quality gate ensures WCAG AA contrast.
Phase 3: Implementation Loop
Auto-code processes TODO specs, runs parallel code review and QA. Visual tests with BackstopJS. Iterates until all quality gates pass.
Phase 4: Final BRD Verification
Blocking gate with QA gap analysis and comprehensive Critic review.
Phase 5: Documentation
Doc-gen creates project documentation, api-docs creates OpenAPI specs.
Fresh Context Isolation GSD Pattern
Critical: Each TODO spec MUST be executed with a FRESH 200k-token context.
Claude's output quality degrades as context fills. To maintain world-class code quality, the conductor spawns each implementation task as an isolated subagent with fresh context.
Why Fresh Context Matters
| Context % | Code Quality | Typical Issue |
|---|---|---|
| 0-25% | World-class | Full attention, comprehensive |
| 25-50% | Good | Minor oversights |
| 50-75% | Degraded | Corner-cutting, "more concise" |
| 75-100% | Poor | Placeholders, incomplete implementations |
Context Boundary Rules
INCLUDE in subagent context:
- The single TODO spec being implemented
- BRD requirement and acceptance criteria
- Interface definitions for dependencies
- Project conventions (from CLAUDE.md)
- Security requirements excerpt
EXCLUDE from subagent context:
- Other TODO specs
- Full conversation history
- Unrelated codebase sections
- Previous implementation attempts
SUMMARY.md Historical Record GSD Pattern
Maintain a running historical record of all work in SUMMARY.md. This file provides bisectable history, session continuity, and audit trail for the entire project lifecycle.
SUMMARY.md Structure
# Project Summary ## Project: [Project Name] **Started:** [ISO timestamp] **Current Phase:** [Phase N] - [Phase Name] **Total Sessions:** [count] --- ## Session History ### Session [N] - [YYYY-MM-DD HH:MM] **Phase:** [Phase Name] **Duration:** [X minutes] **Agent(s):** [list of agents invoked] #### Completed Tasks | Task | Agent | BRD Req | Outcome | Commit | |------|-------|---------|---------|--------| | [description] | [agent] | REQ-XXX | SUCCESS | [hash] | #### Key Decisions - [Decision 1]: [Rationale] #### Files Changed - `path/to/file.ts` - [description]
When to Update
- Session Start: Record session number, timestamp, current phase
- Task Completion: Log task with agent, BRD reference, outcome, commit hash
- Key Decision: Document decision with rationale for future reference
- Session End: Summarize session, note any blockers discovered
XML Task Structure GSD Pattern - Optional
For complex specs, use XML-structured task definitions to ensure explicit verification and clear action boundaries.
When to Use XML Tasks
| Spec Type | Use XML? | Reason |
|---|---|---|
| Simple feature (1-2 files) | No | Markdown sufficient |
| Complex feature (3+ files) | Yes | Explicit file tracking |
| Integration with external tool | Yes | Verification commands critical |
| Security-sensitive feature | Yes | Security considerations explicit |
| Multi-step implementation | Yes | Action sequencing clear |
XML Task Block Format
<task id="TASK-001" brd-ref="REQ-XXX">
<name>Implement Scanner Service</name>
<priority>high</priority>
<actions>
<action id="1" type="create">
<file>src/services/Scanner.ts</file>
<description>Create Scanner class</description>
</action>
</actions>
<verify>
<command>npm test -- --grep Scanner</command>
<command>npm run lint</command>
</verify>
<acceptance-criteria>
<criterion id="AC-1">Scanner executes and returns results</criterion>
</acceptance-criteria>
</task>
XML Task Benefits
- Explicit Actions: No ambiguity about what files to create/modify
- Built-in Verification: Commands that MUST pass before completion
- Dependency Tracking: Clear what must exist before starting
- Acceptance Criteria: Machine-verifiable completion criteria
Usage Example
# Invoke the conductor with your BRD conductor "Build a user authentication system based on auth-brd.md" # Conductor automatically orchestrates: # - Spawns project-setup for new projects # - Routes to research for requirements # - Engages ciso for security review # - Uses architect for spec creation # - Coordinates auto-code for implementation (fresh context per spec) # - Runs qa-guy and code-reviewer in parallel # - Engages critic at every checkpoint # - Maintains SUMMARY.md throughout # - Produces doc-gen and api-docs at completion
Key Features
- State Persistence: Uses conductor-state.json for tracking workflow position
- BRD Tracking: Mandatory BRD-tracker.json ensures 100% requirement coverage
- Fresh Context Isolation: Each spec gets fresh 200k context for optimal quality
- SUMMARY.md History: Running audit trail of all sessions and decisions
- XML Task Structure: Optional structured task definitions for complex features
- Git Ratcheting: Commits after every logical change for recovery
- Dual Enforcement: PM keeps schedule, Critic keeps quality
- 6 Mandatory Checkpoints: Critic validation at each phase transition
- Zero Placeholders: Rejects stub implementations or shell applications