菜单
Use when executing implementation plans with independent tasks - dispatch coder agents for bounded slices and run reviewer agents on cadence, size, risk triggers, and final integration
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | subagent-driven-development |
| description | Use when executing implementation plans with independent tasks - dispatch coder agents for bounded slices and run reviewer agents on cadence, size, risk triggers, and final integration |
Execute an implementation plan with fresh coder agents and bounded reviewer agents.
Core principle: the controller owns the plan, context, verification, and escalation. Coder agents implement bounded slices until there is a coherent PR-sized batch to review. Reviewer agents do code quality plus spec/drift detection for that batch, not after every slice by default. After all slices are complete, one wider integration reviewer checks that the app/workflow works as a whole.
This skill is project-agnostic. Use the current repository's plans, architecture docs, coding standards, tests, evals, apps, and runtime surfaces as evidence. Do not hand-author proof or certification artifacts; when a project has those concepts, they must be byproducts of real commands or runtime effects.
Do not use this for a single small edit, unclear requirements, or tightly coupled work that needs one owner to keep the full implementation in context.
coder-prompt.md - template for the implementation agent.reviewer-prompt.md - template for checkpoint review: code quality plus spec/drift detection.final-integration-reviewer-prompt.md - template for the end-of-slices integration review.The default review unit is a meaty PR-sized batch: as much completed work as can be safely grouped into one coherent pull-request-sized review. Do not review every task by default, and do not keep coding past the point where the batch would be too large to review well.
At the start, the controller sets a batch target:
Tune the caps to the work: smaller batches for shared/risky code; larger batches for mechanical edits with strong deterministic tests. If a slice alone is PR-sized, review after that slice; if several small slices compose one coherent PR-sized chunk, review them together.
The controller runs declared verifiers before checkpoint review. If those gates fail, the batch is not ready for approval review. Either fix it directly when the patch is surgical or send the concrete failure back to a coder. Use a reviewer on a known-failing batch only when the reviewer is being asked for diagnosis, not approval.
Run a checkpoint reviewer before continuing when a slice touches:
Checkpoint reviewers only do:
They do not invent new requirements, run broad architecture redesign, produce certification, or ask for re-review loops. They report blocking evidence and concrete patch recommendations for the PR-sized batch under review.
Give reviewers a compact packet:
Objective:
Completed slices since last review:
Remaining slices:
Batch boundary / why this is PR-sized:
Acceptance criteria:
Risk triggers hit:
Changed files:
Diffstat:
Important file refs/diffs:
Verifier commands and results:
App/runtime smoke or e2e status:
Known concerns/blockers:
Questions for reviewer:
Ask for new blocking evidence. Do not ask for generic commentary.
APPROVED: continue.NEEDS_CHANGES: fix the concrete findings, verify with commands, and continue; do not spawn an approval loop.BLOCKED: stop new slices until the blocker is resolved, reduced, or explicitly deferred by the controller.NO_RESULT or timeout: retry once only with a smaller evidence packet or clearer prompt; if it fails again, escalate.There is no automatic re-review after every fix. The next scheduled checkpoint or the final integration review validates that prior fixes stayed fixed.
No subagent should run silently past the batch's expected window. The controller should set a bounded wait for each coder/reviewer based on batch size, poll or request status when needed, and avoid blocking the whole run on a stale child. If a coder or reviewer produces no usable result after one retry, the controller either continues locally when safe or escalates with the exact blocker.
When the project goal says pass = commit/push, APPROVED means the controller
stages only scoped files, follows the repository commit protocol, pushes, and
leaves unrelated dirty work untouched.
Escalate when:
After all planned slices are complete, run one final integration reviewer with the whole evidence packet.
The final reviewer verifies:
If the app or runtime cannot be exercised, the closeout must say exactly what was not verified.
Never:
Completed:
Files changed:
Verification:
Reviews:
Integration status:
Unresolved risks:
Next action:
Routes adaptive multi-agent deliberation with fractal context cycles. Use when using /cdo, think/deep/debug/parliament work, or long runs paired with autoresearch scheduling.
Use when you need an evidence-first provenance report from `cass`, repo docs, `.lev`, `~/.agents/diagrams`, `qmd`, or Grep/Glob tools.
Use the codebase knowledge graph for structural code queries. Triggers on: explore the codebase, understand the architecture, what functions exist, show me the structure, who calls this function, what does X call, trace the call chain, find callers of, show dependencies, impact analysis, dead code, unused functions, high fan-out, refactor candidates, code quality audit, graph query syntax, Cypher query examples, edge types, how to use search_graph.
Handle blocked destructive commands. Use when dcg blocks rm -rf, git reset --hard, DROP DATABASE, kubectl delete, or when configuring agent safety guardrails.
Use when running a visible Lev autopilot that coordinates research, interview, arch, propose, AgentPing, warm-worker intent, realtime dashboard intent, and lev exec updates across the lifecycle.
Heartbeat-driven autonomous development loop using lev loop autodev, with interval, budget, and tick controls for in-process SDLC execution.