원클릭으로
subagent-driven-development
Use when executing implementation plans with independent tasks in the current session
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
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: