Skip to main content
Execute plans via delegate_task subagents (2-stage review).

Skill metadata

Reference: full SKILL.md

The following is the complete skill definition that Mibyan loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.

Subagent-Driven Development

Overview

Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review. Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.

When to Use

Use this skill when:
  • You have an implementation plan (from the plan skill or user requirements)
  • Tasks are mostly independent
  • Quality and spec compliance are important
  • You want automated review between tasks
vs. manual execution:
  • Fresh context per task (no confusion from accumulated state)
  • Automated review process catches issues early
  • Consistent quality checks across all tasks
  • Subagents can ask questions before starting work

The Process

1. Read and Parse Plan

Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
Key: Read the plan ONCE. Extract everything. Don’t make subagents read the plan file — provide the full task text directly in context.

2. Per-Task Workflow

For EACH task in the plan:

Step 1: Dispatch Implementer Subagent

Use delegate_task with complete context:

Step 2: Dispatch Spec Compliance Reviewer

After the implementer completes, verify against the original spec:
If spec issues found: Fix gaps, then re-run spec review. Continue only when spec-compliant.

Step 3: Dispatch Code Quality Reviewer

After spec compliance passes:
If quality issues found: Fix issues, re-review. Continue only when approved.

Step 4: Mark Complete

3. Final Review

After ALL tasks are complete, dispatch a final integration reviewer:

4. Verify and Commit

Task Granularity

Each task = 2-5 minutes of focused work. Too big:
  • “Implement user authentication system”
Right size:
  • “Create User model with email and password fields”
  • “Add password hashing function”
  • “Create login endpoint”
  • “Add JWT token generation”
  • “Create registration endpoint”

Red Flags — Never Do These

  • Start implementation without a plan
  • Skip reviews (spec compliance OR code quality)
  • Proceed with unfixed critical/important issues
  • Dispatch multiple implementation subagents for tasks that touch the same files
  • Make subagent read the plan file (provide full text in context instead)
  • Skip scene-setting context (subagent needs to understand where the task fits)
  • Ignore subagent questions (answer before letting them proceed)
  • Accept “close enough” on spec compliance
  • Skip review loops (reviewer found issues → implementer fixes → review again)
  • Let implementer self-review replace actual review (both are needed)
  • Start code quality review before spec compliance is PASS (wrong order)
  • Move to next task while either review has open issues

Handling Issues

If Subagent Asks Questions

  • Answer clearly and completely
  • Provide additional context if needed
  • Don’t rush them into implementation

If Reviewer Finds Issues

  • Implementer subagent (or a new one) fixes them
  • Reviewer reviews again
  • Repeat until approved
  • Don’t skip the re-review

If Subagent Fails a Task

  • Dispatch a new fix subagent with specific instructions about what went wrong
  • Don’t try to fix manually in the controller session (context pollution)

Efficiency Notes

Why fresh subagent per task:
  • Prevents context pollution from accumulated state
  • Each subagent gets clean, focused context
  • No confusion from prior tasks’ code or reasoning
Why two-stage review:
  • Spec review catches under/over-building early
  • Quality review ensures the implementation is well-built
  • Catches issues before they compound across tasks
Cost trade-off:
  • More subagent invocations (implementer + 2 reviewers per task)
  • But catches issues early (cheaper than debugging compounded problems later)

Integration with Other Skills

With plan

This skill EXECUTES plans created by the plan skill:
  1. User requirements → plan → implementation plan
  2. Implementation plan → subagent-driven-development → working code

With test-driven-development

Implementer subagents should follow TDD:
  1. Write failing test first
  2. Implement minimal code
  3. Verify test passes
  4. Commit
Include TDD instructions in every implementer context.

With requesting-code-review

The two-stage review process IS the code review. For final integration review, use the requesting-code-review skill’s review dimensions.

With systematic-debugging

If a subagent encounters bugs during implementation:
  1. Follow systematic-debugging process
  2. Find root cause before fixing
  3. Write regression test
  4. Resume implementation

Example Workflow

Remember

Quality is not an accident. It’s the result of systematic process.

Further reading (load when relevant)

When the orchestration involves significant context usage, long review loops, or complex validation checkpoints, load these references for the specific discipline:
  • references/context-budget-discipline.md — Four-tier context degradation model (PEAK / GOOD / DEGRADING / POOR), read-depth rules that scale with context window size, and early warning signs of silent degradation. Load when a run will clearly consume significant context (multi-phase plans, many subagents, large artifacts).
  • references/gates-taxonomy.md — The four canonical gate types (Pre-flight, Revision, Escalation, Abort) with behavior, recovery, and examples. Load when designing or reviewing any workflow that has validation checkpoints — use the vocabulary explicitly so each gate has defined entry, failure behavior, and resumption rules.
Both references adapted from gsd-build/get-shit-done (MIT © 2025 Lex Christopherson).