菜单
Executes implementation plans by dispatching a fresh subagent per task with two-stage review after each (spec compliance, then code quality). Use when executing a plan with independent tasks in the current session.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a major project step has been completed and needs review against the original plan and coding standards. Provides the Senior Code Reviewer persona for structured 6-phase review: plan alignment, code quality, architecture, documentation, issue categorization, and communication.
Use when you need to trigger brainstorm, write-plan, or execute-plan workflows via short command shortcuts. These are thin dispatchers that invoke the corresponding sp- skills.
Use when creating new skills, editing existing skills, or verifying skills work before deployment. Apply TDD cycle: baseline test first, write skill second, refactor to close loopholes.
Use when completing tasks, implementing major features, or before merging. Dispatches a code-reviewer session to catch issues before they cascade. Review early, review often.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Decision framework for when and how to dispatch parallel sub-agent sessions for faster resolution.
Use when implementation is complete and all tests pass, to decide how to integrate the work. Guides branch completion by presenting 4 structured options: merge locally, push and create a PR, keep as-is, or discard.
| name | sp-subagent-driven-development |
| description | Executes implementation plans by dispatching a fresh subagent per task with two-stage review after each (spec compliance, then code quality). Use when executing a plan with independent tasks in the current session. |
| tags | ["workflow","subagents","implementation","code-review","planning"] |
| version | 1.0.0 |
| risk | guarded |
| triggers | ["execute this plan with subagents","subagent-driven development","dispatch subagents for each task","implement plan with review","fresh subagent per task"] |
| requirements | {"cli":[],"env":[]} |
| upstream_ref | skills/subagent-driven-development/SKILL.md |
| author | AlphaComposite |
| license | MIT |
| dependencies | ["sp-writing-plans","sp-test-driven-development","sp-requesting-code-review","sp-finishing-a-development-branch","sp-using-git-worktrees","sp-brainstorming","sp-executing-plans"] |
Execute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
Dependency notes:
sp-requesting-code-reviewhas not yet been ported. When unavailable, apply the code review prompt inline using the templates in this skill.sp-finishing-a-development-branchhas not yet been ported. When unavailable, handle branch completion manually (final review, merge/PR creation).- This skill requires an isolated worktree prepared by
sp-using-git-worktreesbefore starting.
Decision tree:
Have implementation plan?
├── No → Brainstorm first (sp-brainstorming → sp-writing-plans)
└── Yes → Tasks mostly independent?
├── No (tightly coupled) → Manual execution
└── Yes → Stay in this session?
├── Yes → Use sp-subagent-driven-development (this skill)
└── No → Use sp-executing-plans (parallel session)
vs. Executing Plans (parallel session):
For each task:
After all tasks:
sp-finishing-a-development-branchIn OpenClaw, subagents are spawned via the orchestration pattern in AGENTS.md. Use exec with PTY + background for builder subagents:
# Spawn an implementer subagent
exec pty:true background:true command:"<builder-cli> '<full task text + context>'"
Note: The specific CLI command depends on the configured coding agent (e.g. Claude Code, Aider, etc.). Check
AGENTS.mdor project config for the builder CLI.
For reviewer subagents, spawn similarly but pass the review prompt instead of the implementation prompt.
Key rules:
workdir to the project/worktree directorybackground:true for long tasksprocess action:log sessionId:<id>You are implementing Task N of M in <project-name>.
**Scene:** <Where this task fits in the overall plan — 1-2 sentences>
**Task:** <Full task text from the plan, verbatim>
**Context:**
- Worktree: <path>
- Branch: <branch-name>
- Relevant files: <list any files the implementer needs>
- Related tasks already done: <summary of completed tasks>
**Requirements:**
- Use TDD: write failing test first, verify it fails, then implement (sp-test-driven-development)
- Commit after each logical unit
- Self-review before reporting done
- Ask questions BEFORE starting if anything is unclear
Report when done: what you implemented, tests passing, commits made, any self-review findings.
You are a spec compliance reviewer. Your job: confirm the implementation matches the spec exactly — no more, no less.
**Task Spec:**
<Full task text from the plan, verbatim>
**Commits to review:**
<git SHAs>
**Review criteria:**
- Every requirement in the spec is implemented
- Nothing extra was added that wasn't requested
- Edge cases mentioned in spec are handled
Output:
✅ Spec compliant — list what was verified
OR
❌ Issues found:
- Missing: <requirement not implemented>
- Extra: <thing added that wasn't requested>
You are a code quality reviewer. The spec compliance reviewer has already confirmed the implementation matches spec. Your job: assess code quality.
**Commits to review:**
<git SHAs>
**Review criteria:**
- Code is readable and well-named
- No unnecessary duplication (DRY)
- No over-engineering (YAGNI)
- Tests are meaningful (not testing mocks, not testing implementation details)
- Error handling is appropriate
- No obvious performance issues
Output:
✅ Approved — brief summary of strengths
OR
⚠️ Issues (label each as Critical / Important / Minor):
- <issue description and suggested fix>
[Read plan: docs/plans/2024-01-15-auth.md]
[Extract 5 tasks with full text]
[Create task list: Task 1-5]
Task 1: Hook installation script
[Dispatch implementer with full task text + context]
Implementer: "Before I begin — should the hook be installed at user or system level?"
You: "User level (~/.config/superpowers/hooks/)"
Implementer: "Got it. Implementing now..."
[Later] Implementer:
- Implemented install-hook command
- Added tests, 5/5 passing
- Self-review: Found I missed --force flag, added it
- Committed: abc1234, def5678
[Dispatch spec compliance reviewer with task spec + SHAs]
Spec reviewer: ✅ Spec compliant — all requirements met, nothing extra
[Dispatch code quality reviewer with SHAs]
Code reviewer: ✅ Approved. Good test coverage, clean naming.
[Mark Task 1 complete]
Task 2: Recovery modes
[Dispatch implementer with full task text + context]
Implementer: [No questions, proceeds]
Implementer:
- Added verify/repair modes
- 8/8 tests passing
- Committed: 9ab0123
[Dispatch spec compliance reviewer]
Spec reviewer: ❌ Issues:
- Missing: Progress reporting (spec says "report every 100 items")
- Extra: Added --json flag (not requested)
[Implementer fixes issues]
Implementer: Removed --json flag, added progress reporting. Committed: cd23456
[Spec reviewer re-reviews]
Spec reviewer: ✅ Spec compliant now
[Dispatch code quality reviewer]
Code reviewer: ⚠️ Issues (Important): Magic number (100) — extract as constant
[Implementer fixes]
Implementer: Extracted PROGRESS_INTERVAL constant. Committed: ef34567
[Code reviewer re-reviews]
Code reviewer: ✅ Approved
[Mark Task 2 complete]
...
[After all tasks: final review → sp-finishing-a-development-branch]
vs. Manual execution:
vs. Executing Plans:
Quality gates:
Never:
If subagent asks questions:
If reviewer finds issues:
If subagent fails task: