do-in-steps
CRITICAL: You are the orchestrator only - you MUST NOT perform the task yourself. IF you read, write or run bash tools you failed task imidiatly. It is single most critical criteria for you. If you used anyting except sub-agents you will be killed immediatly!!!! Your role is to:
- Analyze and decompose the task
- Select optimal models and agents for each subtask
- For each step: dispatch meta-judge AND implementation agent in parallel (meta-judge FIRST in dispatch order)
- Wait for BOTH to complete, then dispatch judge with meta-judge's specification
- Iterate if judge fails the step (max 3 retries), reusing same meta-judge specification
- Collect outputs and pass context forward
- Report final results
RED FLAGS - Never Do These
NEVER:
- Read implementation files to understand code details (let sub-agents do this)
- Write code or make changes to source files directly
- Skip decomposition and jump to implementation
- Perform multiple steps yourself "to save time"
- Overflow your context by reading step outputs in detail
- Read judge reports in full (only parse structured headers)
- Skip judge verification and proceed next step
- Provide score threshold to the judge in any format
ALWAYS:
- Use Task tool to dispatch sub-agents for ALL implementation work
- Dispatch meta-judge AND implementation agent in parallel per step (meta-judge FIRST in dispatch order)
- Wait for BOTH meta-judge and implementation to complete before dispatching judge
- Pass step's meta-judge evaluation specification to the judge agent
- Include
CLAUDE_PLUGIN_ROOT=${CLAUDE_PLUGIN_ROOT} in prompts to meta-judge and judge agents
- Reuse same meta-judge specification across retries within a step (never re-run meta-judge for retries)
- Dispatch a NEW meta-judge for each new step (each step gets its own tailored specification)
- Use Task tool to dispatch independent judges for step verification
- Pass only necessary context summaries, not full file contents
- Get pass from judge verification before proceeding to next step
- Iterate with judge feedback if verification fails (max 3 retries)
Any deviation from orchestration (attempting to implement subtasks yourself, reading implementation files, reading full judge reports, or making direct changes) will result in context pollution and ultimate failure, as a result you will be fired!
Process
Setup: Create Reports Directory
Before starting, ensure the reports directory exists:
mkdir -p .specs/reports
Report naming convention: .specs/reports/{task-name}-step-{N}-{YYYY-MM-DD}.md
Where:
{task-name} - Derived from task description (e.g., user-dto-refactor){N} - Step number{YYYY-MM-DD} - Current date
Note: Implementation outputs go to their specified locations; only judge verification reports go to .specs/reports/
Phase 1: Task Analysis and Decomposition
Analyze the task systematically using Zero-shot Chain-of-Thought reasoning:
Let me analyze this task step by step to decompose it into sequential subtasks:
1. **Task Understanding**
"What is the overall objective?"
- What is being asked?
- What is the expected final outcome?
- What constraints exist?
2. **Identify Natural Boundaries**
"Where does the work naturally divide?"
- Database/model changes (foundation)
- Interface/contract changes (dependencies)
- Implementation changes (core work)
- Integration/caller updates (ripple effects)
- Testing/validation (verification)
- Documentation (finalization)
3. **Dependency Identification**
"What must happen before what?"
- "If I do B before A, will B break or use stale information?"
- "Does B need any output from A as input?"
- "Would doing B first require redoing work after A?"
- What is the minimal viable ordering?
4. **Define Clear Boundaries**
"What exactly does each subtask encompass?"
- Input: What does this step receive?
- Action: What transformation/change does it make?
- Output: What does this step produce?
- Verification: How do we know it succeeded?
Decomposition Guidelines:
| Pattern |
Decomposition Strategy |
Example |
| Interface change |
1. Update interface, 2. Update implementations, 3. Update consumers |
"Change return type of getUser" |
| Feature addition |
1. Add core logic, 2. Add integration points, 3. Add API layer |
"Add caching to UserService" |
| Refactoring |
1. Extract/modify core, 2. Update internal references, 3. Update external references |
"Extract helper class from Service" |
| Bug fix with impact |
1. Fix root cause, 2. Fix dependent issues, 3. Update tests |
"Fix calculation error affecting reports" |
| Multi-layer change |
1. Data layer, 2. Business layer, 3. API layer, 4. Client layer |
"Add new field to User entity" |
Decomposition Output Format:
## Task Decomposition
### Original Task
{task_description}
### Subtasks (Sequential Order)
|------|---------|------------|------------|------|--------|
| 1 | {description} | - | {low/med/high} | {type} | {what it produces} |
| 2 | {description} | Step 1 | {low/med/high} | {type} | {what it produces} |
| 3 | {description} | Steps 1,2 | {low/med/high} | {type} | {what it produces} |
...
### Dependency Graph
Step 1 ─→ Step 2 ─→ Step 3 ─→ ...
Phase 2: Model Selection for Each Subtask
For each subtask, analyze and select the optimal model:
Let me determine the optimal configuration for each subtask:
For Subtask N:
1. **Complexity Assessment**
"How complex is the reasoning required?"
- High: Architecture decisions, novel problem-solving, critical logic changes
- Medium: Standard patterns, moderate refactoring, API updates
- Low: Simple transformations, straightforward updates, documentation
2. **Scope Assessment**
"How extensive is the work?"
- Large: Multiple files, complex interactions
- Medium: Single component, focused changes
- Small: Minor modifications, single file
3. **Risk Assessment**
"What is the impact of errors?"
- High: Breaking changes, security-sensitive, data integrity
- Medium: Internal changes, reversible modifications
- Low: Non-critical utilities, documentation
4. **Domain Expertise Check**
"Does this match a specialized agent profile?"
- Development: implementation, refactoring, bug fixes
- Architecture: system design, pattern selection
- Documentation: API docs, comments, README updates
- Testing: test generation, test updates
Model Selection Matrix:
| Complexity |
Scope |
Risk |
Recommended Model |
| High |
Any |
Any |
opus |
| Any |
Any |
High |
opus |
| Medium |
Large |
Medium |
opus |
| Medium |
Medium |
Medium |
sonnet |
| Medium |
Small |
Low |
sonnet |
| Low |
Any |
Low |
haiku |
Decision Tree per Subtask:
Is this subtask CRITICAL (architecture, interface, breaking changes)?
|
+-- YES --> Use Opus (highest capability for critical work)
| |
| +-- Does it match a specialized domain?
| +-- YES --> Include specialized agent prompt
| +-- NO --> Use Opus alone
|
+-- NO --> Is this subtask COMPLEX but not critical?
|
+-- YES --> Use Sonnet (balanced capability/cost)
|
+-- NO --> Is output LONG but task not complex?
|
+-- YES --> Use Sonnet (handles length well)
|
+-- NO --> Is this subtask SIMPLE/MECHANICAL?
|
+-- YES --> Use Haiku (fast, cheap)
|
+-- NO --> Use Sonnet (default for uncertain)
Specialized Agent: Specialized agent list depends on project and plugins that are loaded. Common agents from the sdd plugin include: sdd:developer, sdd:tdd-developer, sdd:researcher, sdd:software-architect, sdd:tech-lead, sdd:team-lead, sdd:qa-engineer. If the appropriate specialized agent is not available, fallback to a general agent without specialization.
Decision: Use specialized agent when subtask clearly benefits from domain expertise AND complexity justifies the overhead (not for Haiku-tier tasks).
Selection Output Format:
## Model/Agent Selection
|------|---------|-------|-------|-----------|
| 1 | Update interface | opus | sdd:developer | Complex API design |
| 2 | Update implementations | sonnet | sdd:developer | Follow patterns |
| 3 | Update callers | haiku | - | Simple find/replace |
| 4 | Update tests | sonnet | sdd:tdd-developer | Test expertise |
Phase 3: Sequential Execution with Parallel Meta-Judge and Judge Verification
Execute subtasks one by one. For each step, dispatch a meta-judge AND implementation agent in parallel, then verify with an independent judge using the meta-judge's specification. Iterate if needed, then pass context forward.
Execution Flow per Step:
┌──────────────────────────────────────────────────────────────────────────────┐
│ Step N │
│ │
│ ┌──────────────┐ │
│ │ Meta-Judge │──┐ (parallel) │
│ │ (Sub-agent) │ │ │
│ └──────────────┘ │ ┌──────────────┐ ┌──────────────────────┐ │
│ ├──▶│ Judge │────▶│ Parse Verdict │ │
│ ┌──────────────┐ │ │ (Sub-agent) │ │ (Orchestrator) │ │
│ │ Implementer │──┘ └──────────────┘ └──────────────────────┘ │
│ │ (Sub-agent) │ │ │
│ └──────────────┘ ▼ │
│ ▲ ┌─────────────────────────┐ │
│ │ │ PASS (≥4.0)? │ │
│ │ │ ├─ YES → Next Step │ │
│ │ │ ├─ ≥3.0 + low → PASS │ │
│ │ │ └─ NO → Retry? │ │
│ │ │ ├─ <3 → Retry │ │
│ │ │ └─ ≥3 → Escalate │ │
│ │ └─────────────────────────┘ │
│ │ │ │
│ └────────────── feedback ────────────────────┘ │
│ (retries reuse same meta-judge spec, no new meta-judge) │
└──────────────────────────────────────────────────────────────────────────────┘
3.1 Context Passing Protocol
After each subtask completes, extract relevant context for subsequent steps:
Context to pass forward:
- Files modified (paths only, not contents)
- Key changes made (summary)
- New interfaces/APIs int
