Do In Steps

do-in-steps

<task> Execute a complex task by decomposing it into sequential subtasks and orchestrating sub-agents to complete each step in order. Automatically analyze the task to identify dependencies, select a right-sized model for each subtask, pass relevant context from completed steps to subsequent ones, and verify each step with an independent judge (using a meta-judge evaluation specification) before proceeding. </task>

<context> This command implements the Supervisor/Orchestrator pattern for sequential task execution with context passing and meta-judge → LLM-as-a-judge verification. You (the orchestrator) analyze a complex task, decompose it into ordered subtasks, then for each step dispatch a meta-judge AND implementation agent in parallel. The meta-judge generates step-specific evaluation criteria while the implementation runs concurrently. Each sub-agent receives:

• Isolated context - Clean context window for its specific subtask
• Right-sized model - Chosen per step by the Model Selection Policy: sonnet/haiku by default, opus only when earned
• Previous step context - Summary of relevant outputs from preceding steps
• Structured reasoning - Zero-shot CoT prefix for systematic thinking
• Self-critique - Internal verification before submission
• Structured evaluation - Meta-judge produces tailored rubrics and checklists per step before judging occurs
• External judge - LLM-as-a-judge verification using meta-judge specification with iteration loop
• Parallel speed - Meta-judge and implementation agent run in parallel per step; meta-judge specification reused across retries within that step

</context>

Arguments

Example: /do-in-steps Refactor UserService class and update all consumers --strict

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:

1. Analyze and decompose the task
2. Select the model tier and agent for each subtask per the Model Selection Policy — sonnet/haiku by default, opus only when earned
3. For each step: dispatch meta-judge AND implementation agent in parallel (meta-judge FIRST in dispatch order)
4. Wait for BOTH to complete, then dispatch judge with meta-judge's specification
5. Iterate if judge fails the step (max 3 retries), reusing same meta-judge specification
6. Collect outputs and pass context forward
7. 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)
• Apply the Iteration Discretion Rule to every step verdict, unless --strict was provided

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!

Model Selection Policy

Picking the model is the single highest-leverage decision you make — more than any prompt wording, it decides whether a step comes back correct and how long the chain takes. You MUST NOT treat it as a formality: name the tier and give a one-line justification before dispatching each step. Reaching for the strongest model because you did not want to think is a failure, not caution.

Tier default: sonnet and haiku are the default. opus is reserved and opt-in — it MUST be earned by a trigger in the table below, never picked because you are unsure.

Per step, not per run: a tier is chosen independently for every step, from that step's own scope, complexity and risk. One decomposition may legitimately mix tiers — opus for a contract change, haiku for the mechanical follow-ups. A tier reached in one step (including one reached by escalation) MUST NOT be carried into the next.

Selection Rules