菜单
Use when executing implementation plans with independent tasks in the current session
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
| name | subagent-driven-development |
| description | Use when executing implementation plans with independent tasks in the current session |
Execute plan by dispatching fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
Why subagents: You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration
vs. Executing Plans (parallel session):
Per-task workflow:
Use the least powerful model that can handle each role to conserve cost and increase speed.
Mechanical implementation tasks (isolated functions, clear specs, 1-2 files): use fast, cheap model.
Integration and judgment tasks (multi-file coordination, pattern matching, debugging): use standard model.
Architecture, design, and review tasks: use most capable available model.
Task complexity signals:
DONE: Proceed to spec compliance review.
DONE_WITH_CONCERNS: Read concerns before proceeding. Address correctness/scope issues before review.
NEEDS_CONTEXT: Provide missing context and re-dispatch.
BLOCKED: Assess the blocker:
Never ignore escalation or force same model retry without changes.
./implementer-prompt.md - Dispatch implementer subagent./spec-reviewer-prompt.md - Dispatch spec compliance reviewer subagent./code-quality-reviewer-prompt.md - Dispatch code quality reviewer subagentNever:
If reviewer finds issues:
Required workflow skills:
Subagents should use:
Alternative workflow: