domains / families / software-engineering / subagent-driven-development

subagent-driven-development

combined

Use when executing implementation plans with independent tasks in the current session

When to use

• Same session (no context switch)
• Fresh subagent per task (no context pollution)
• Two-stage review after each task: spec compliance first, then code quality
• Faster iteration (no human-in-loop between tasks)
• Fresh subagent per task (no context pollution) instead of one context doing every task
• Review after each task (spec compliance + code quality) instead of only at the end
• Costs a fresh context per task and per review; inline costs one context plus one final reviewer
• Both run in this session, share the same plan workspace and ledger, and never pause between tasks

When not to use

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Skill page

Conflict

The copies overlap on the core loop (fresh implementer subagent per task, spec compliance review, code quality review, final whole-branch review, then finishing-a-development-branch), but they disagree on the review architecture and on operational constraints. obra/superpowers uses a single task reviewer that checks spec and quality together, adds a ledger, a 5-round fix cap with model escalation, adjudication of load-bearing findings, and explicit stop conditions. The other three copies use two separate reviewer subagents (spec then quality) and a simpler TodoWrite-based flow. Crowning one would hide a real alternative review strategy and the extra governance steps.