Subagent Driven Development

Execute implementation plans by dispatching a fresh subagent per task with two-stage review (spec compliance then code quality). Use when you have an implementation plan with mostly independent tasks and want high-quality, fast iteration within a single session.

Security Scan

The skill's instructions match its stated purpose (orchestrating per-task subagents for development) but there are minor incoherencies and missing pieces that could lead to unexpected behavior if the agent is given repository or execution privileges.

Purpose & Capability

Name/description (dispatch fresh subagents, two-stage review) align with the SKILL.md content. The skill does not request unrelated credentials, binaries, or config paths.

Instruction Scope

The runtime instructions assume the controller/agent will implement dispatching subagents, run tests, make commits, and reference git SHAs — but the skill does not include the referenced prompt files (references/*.md) and does not declare or limit how subagents are dispatched. The instructions therefore implicitly assume repository, filesystem, and git/tool access that are not made explicit. This is coherent for a developer orchestration skill but incomplete and gives the agent broad discretion.

Install Mechanism

No install spec and no code files — lowest-risk installation model. The README shows an npx install example, but no actual install script or package is provided in the registry entry; that's a documentation/incompleteness issue rather than an install risk.

Credentials

The skill declares no required environment variables, credentials, or config paths. However, the instructions imply the need for access to the working repository, git, test runner, and possibly external issue trackers or CI; those are not requested explicitly.

Persistence & Privilege

always is false and model invocation is allowed (platform default). The skill does not request persistent presence or attempt to modify other skills or global agent settings in the provided text.

What to consider before installing

This is an instruction-only orchestration skill that looks coherent for per-task development work, but it omits some concrete pieces and implicitly requires repository/git/test-run privileges. Before installing or using it: - Confirm where the referenced prompt templates (references/implementer-prompt.md, spec-reviewer-prompt.md, code-quality-reviewer-prompt.md) come from — they are not included in the package. Ask the publisher for the exact prompt text. - Only run this skill in an environment you trust. It expects the controller to run tests, commit code, and operate on a repo; granting those capabilities to an agent gives it the ability to modify source and push commits. - If you plan autonomous invocation, limit the agent's repository/write/network permissions or test in a sandbox first. - If you need stricter guarantees, request an explicit install artifact or prompts and a clear dispatch mechanism (how subagents are spawned), and consider adding guardrails (dry-run mode, approval steps, scoped commit access). These gaps don't imply malicious intent, but they are practical inconsistencies you should clarify before handing the skill live repository or execution privileges.

Execute a plan by dispatching a fresh subagent per task, with two-stage review after each — spec compliance first, then code quality.

Core principle: Fresh subagent per task + two-stage review = no context pollution, high quality, fast iteration.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install subagent-driven-development

When to Use This Skill

• You have an implementation plan with discrete, mostly independent tasks
• You want to execute the plan within a single session (no human-in-the-loop between tasks)
• Tasks can be implemented and reviewed sequentially without tight coupling

Condition	This Skill	Alternative
Have a plan, same session	Yes	—
Have a plan, parallel session	No	executing-plans
No plan yet	No	Write a plan first
Tasks tightly coupled	No	Manual execution or decompose more

The Process

┌─────────────────────────────────────────────────────┐
│  1. Read plan, extract ALL tasks with full text      │
│  2. Note shared context (arch, deps, conventions)    │
│  3. Create TodoWrite with all tasks                  │
└──────────────────────┬──────────────────────────────┘
                       ▼
          ┌────── Per Task ──────┐
          │                      │
          │  Dispatch Implementer (references/implementer-prompt.md)
          │       │                                │
          │       ▼                                │
          │  Questions?──yes──► Answer, re-dispatch│
          │       │no                              │
          │       ▼                                │
          │  Implement + test + commit + self-review│
          │       │                                │
          │       ▼                                │
          │  Dispatch Spec Reviewer (references/spec-reviewer-prompt.md)
          │       │                                │
          │       ▼                                │
          │  Compliant?──no──► Implementer fixes──┘
          │       │yes             then re-review
          │       ▼
          │  Dispatch Code Reviewer (references/code-quality-reviewer-prompt.md)
          │       │
          │       ▼
          │  Approved?──no──► Implementer fixes, re-review
          │       │yes
          │       ▼
          │  Mark task complete
          └───────┬──────────────┘
                  ▼
          More tasks? ──yes──► next task
                  │no
                  ▼
          Final cross-task code review
                  ▼
          Finish development branch

Prompt Templates

Three reference prompts are provided for the subagent roles:

Role	File	Purpose
Implementer	references/implementer-prompt.md	Implement, test, commit, self-review
Spec reviewer	references/spec-reviewer-prompt.md	Verify code matches spec exactly
Code reviewer	references/code-quality-reviewer-prompt.md	Verify code is clean and maintainable

Example Workflow

Controller: Reading plan — 5 tasks extracted, TodoWrite created.

─── Task 1: Hook installation script ───

[Dispatch implementer with full task text + context]

Implementer: "Should the hook be installed at user or system level?"
Controller:  "User level (~/.config/hooks/)"

Implementer: ✅ Implemented install-hook command
  - Added tests (5/5 passing)
  - Self-review: missed --force flag, added it
  - Committed

[Dispatch spec reviewer]
Spec reviewer: ✅ Spec compliant — all requirements met

[Dispatch code reviewer with git SHAs]
Code reviewer: ✅ Approved — clean, good coverage

[Mark Task 1 complete]

─── Task 2: Recovery modes ───

[Dispatch implementer]

Implementer: ✅ Added verify/repair modes (8/8 tests passing)

[Dispatch spec reviewer]
Spec reviewer: ❌ Issues:
  - Missing: progress reporting ("report every 100 items")
  - Extra: added --json flag (not in spec)

[Implementer fixes: remove --json, add progress reporting]
Spec reviewer: ✅ Spec compliant

[Dispatch code reviewer]
Code reviewer: Important — magic number 100, extract constant

[Implementer fixes: extract PROGRESS_INTERVAL]
Code reviewer: ✅ Approved

[Mark Task 2 complete]

... (tasks 3-5) ...

[Final cross-task code review]
Final reviewer: ✅ All requirements met, ready to merge

Controller Responsibilities

The controller (you) orchestrates the flow. Key duties:

Responsibility	Detail
Extract tasks upfront	Read plan once, extract all task text — subagents never read the plan file
Provide full context	Give each subagent the complete task text + architectural context
Answer questions	Respond clearly and completely before letting subagent proceed
Enforce review order	Spec compliance first, code quality second — never reversed
Track progress	Update TodoWrite after each task completes
Dispatch sequentially	One implementation subagent at a time to avoid conflicts

Quality Gates

Each task passes through three quality checks:

Gate	Who	What
Self-review	Implementer	Completeness, naming, YAGNI, test quality
Spec review	Spec reviewer	Matches requirements exactly — nothing more, less
Code review	Code reviewer	Clean code, maintainability, test coverage

Advantages

vs. manual execution:

• Fresh context per task (no confusion from accumulated state)
• Subagents follow TDD naturally
• Questions surfaced before work begins, not after

vs. parallel-session plans:

• No handoff overhead
• Continuous progress
• Review checkpoints are automatic

Cost trade-off: More subagent invocations (implementer + 2 reviewers per task), but catches issues early — cheaper than debugging later.

NEVER Do

• Skip either review — both spec compliance and code quality are mandatory
• Start code review before spec review passes — wrong order wastes effort on code that doesn't meet spec
• Dispatch multiple implementers in parallel — causes merge conflicts and context corruption
• Make subagents read the plan file — provide full task text directly
• Skip scene-setting context — subagent needs to understand where the task fits architecturally
• Ignore subagent questions — answer fully before they proceed
• Accept "close enough" on spec compliance — if the reviewer found issues, it's not done
• Skip re-review after fixes — reviewer found issues → implementer fixes → reviewer reviews again
• Let self-review replace actual review — self-review is a first pass, not a substitute
• Move to next task with open review issues — current task must be fully approved first
• Fix issues manually instead of through a subagent — manual fixes pollute controller context

Handling Failures

Situation	Response
Subagent asks questions	Answer clearly, provide additional context if needed
Reviewer finds issues	Same implementer subagent fixes, reviewer re-reviews
Subagent fails task entirely	Dispatch a new fix subagent with specific instructions
Task blocked by dependency	Reorder remaining tasks or resolve dependency first