Get the FREE Ultimate OpenClaw Setup Guide →

subagent-driven-development

npx machina-cli add skill CodingCossack/agent-skills-library/subagent-driven-development --openclaw
Files (1)
SKILL.md
5.2 KB

Subagent-Driven Development

Dispatch fresh subagent per task with two-stage review after each.

Core principle: Fresh subagent per task + two-stage review (spec then quality) + diff-based validation = high quality, fast iteration

Quick Reference

PhaseActorActionExit Condition
1ControllerRead plan, extract tasks, capture BASE_SHA, create task listAll tasks tracked with BASE_SHA
2SubagentImplement (templates/implementer.md)Commit exists + tests pass + report includes HEAD_SHA
3SubagentSpec review (templates/spec-reviewer.md)Reviewer checked diff(BASE..HEAD) and returned ✅ or file:line issues
4SubagentQuality review (templates/code-quality-reviewer.md)Reviewer approved diff or returned severity-tagged issues
5ControllerUpdate state, mark complete, loop to step 2All tasks done
6SubagentFinal review of entire implementationApproved
7ControllerUse finishing-a-development-branchBranch complete

Task Contract

Every task must satisfy these constraints:

Scope:

  • One task = one commit (or tight commit stack)
  • No drive-by refactors; no formatting churn
  • No unrelated file changes

Verification:

  • All tests pass (run full suite or affected subset)
  • Lint/typecheck pass (if applicable)
  • Commands actually executed (not assumed)

Report must include:

  • BASE_SHA (from controller)
  • HEAD_SHA (after commit)
  • Commands run (exact, copy-pasteable)
  • Test output summary (pass/fail + counts)
  • Files changed (list)
  • Scope confirmation ("No unrelated changes")

State Tracking

Controller maintains per-task record:

{
  task_id: string,
  base_sha: string,      # Captured before implementer starts
  head_sha: string,      # From implementer report after commit
  status: pending|in_progress|spec_review|quality_review|complete,
  spec_review_cycles: number,
  quality_review_cycles: number
}

Update state after each phase transition.

Process

Setup (Once)

  1. Read plan file once
  2. Extract all tasks with full text and context
  3. Capture current HEAD as BASE_SHA for first task
  4. Create task list with all tasks (status: pending)

Per Task Loop

  1. Record BASE_SHA for this task (current HEAD)
  2. Dispatch implementer with full task text + context + BASE_SHA
  3. If questions: Answer completely, re-dispatch with answers
  4. Implementer completes: implements, tests, commits, reports HEAD_SHA
  5. Update state: Record HEAD_SHA, set status to spec_review
  6. Dispatch spec reviewer with task requirements + diff(BASE_SHA..HEAD_SHA)
  7. If spec issues: Implementer fixes → spec reviewer re-reviews → increment cycle count → repeat until ✅
  8. Update state: Set status to quality_review
  9. Dispatch code quality reviewer with BASE_SHA, HEAD_SHA
  10. If quality issues: Implementer fixes → quality reviewer re-reviews → increment cycle count → repeat until ✅
  11. Update state: Set status to complete, BASE_SHA for next task = current HEAD_SHA

Completion

  1. Dispatch final code reviewer for entire implementation (first BASE_SHA to final HEAD_SHA)
  2. Use finishing-a-development-branch skill

Prompt Templates

  • templates/implementer.md — Implementation subagent
  • templates/spec-reviewer.md — Spec compliance verification (diff-based)
  • templates/code-quality-reviewer.md — Code quality assessment (diff-based)

See references/example-workflow.md for complete walkthrough with SHA tracking.

Red Flags

Never:

  • Skip reviews (spec compliance OR code quality)
  • Proceed with unfixed issues
  • Dispatch parallel implementers in same working tree (conflicts)
  • Make subagent read plan file (provide full text)
  • Skip BASE_SHA/HEAD_SHA tracking
  • Let reviewers assess "the repo" instead of the specific diff
  • Accept reports without required fields (SHA, commands, test output)

Parallel clarification: "Parallel sessions" (separate branches/worktrees) is fine via executing-plans. "Parallel implementers" touching same working tree is forbidden.

If subagent asks questions: Answer clearly and completely before they proceed.

If reviewer finds issues: Implementer fixes → reviewer re-reviews specific diff → repeat until approved.

If implementer discovers required refactor: Stop, report to controller, request plan amendment. Don't bulldoze.

Dependencies

Requires: writing-plans (creates the plan)

Subagents use: test-driven-development, requesting-code-review (template)

Completes with: finishing-a-development-branch

Alternative: executing-plans (for parallel sessions/branches, not parallel implementers)

Environment notes: This skill assumes availability of: git (for SHA tracking), a task list tool (TodoWrite or equivalent), and ability to dispatch subagents. Adapt tool names to your environment.

Source

git clone https://github.com/CodingCossack/agent-skills-library/blob/main/skills/subagent-driven-development/SKILL.mdView on GitHub

Overview

Subagent-Driven Development deploys a fresh subagent for each task and enforces two-stage reviews after implementation: spec compliance followed by code quality review. It relies on diff-based validation to ensure each task meets standards before proceeding, enabling high-quality, fast iteration on multi-task plans.

How This Skill Works

For every task, the controller captures BASE_SHA, dispatches an implementer to produce a commit, then runs a spec reviewer to validate the diff(BASE_SHA..HEAD_SHA). If issues arise, cycles repeat until passing. Once spec is OK, a code-quality reviewer checks again; on success, the state advances to the next task and finally a complete, validated implementation is finalized with a finishing branch.

When to Use It

  • When executing multi-task plans within a single session
  • When tasks require fresh subagent context to avoid pollution
  • When formal review cycles (spec compliance then code quality) are required between tasks
  • When diff-based validation of each task is needed before proceeding
  • When you need to finalize by finishing a development branch after all tasks

Quick Start

  1. Step 1: Read the plan file, extract all tasks, and capture the initial BASE_SHA for the first task
  2. Step 2: For each task, dispatch an implementer, address questions, commit HEAD_SHA, then run spec and quality reviews (retries allowed until ✅)
  3. Step 3: After all tasks are complete, dispatch the final code reviewer for the entire implementation and use finishing-a-development-branch

Best Practices

  • Capture BASE_SHA for each task before starting implementation
  • Keep one task per commit (or a tight commit stack) and avoid churn
  • Run full tests and lint/typechecks for each task before proceeding
  • Use diff(BASE_SHA..HEAD_SHA) for both spec and quality reviews
  • Maintain per-task state with clear status transitions and cycle counters

Example Use Cases

  • Develop a multi-file feature with three tasks, each undergoing implementer, spec review, and quality review in sequence
  • Add a microservice integration where each API change is handled by a fresh subagent to prevent cross-task contamination
  • Refactor a module with no formatting churn and validate all changes via diff-based reviews per task
  • Introduce a security check where spec compliance is verified before any code quality checks
  • Finish the development branch after all tasks pass spec and quality reviews

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers