메뉴
Use when executing implementation plans with independent tasks — dispatches fresh subagents per task with two-stage review (spec compliance, then code quality)
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | subagent-driven-development |
| description | Use when executing implementation plans with independent tasks — dispatches fresh subagents per task with two-stage review (spec compliance, then code quality) |
On-demand loading: Read this skill only when the task clearly matches the description above or trigger phrases below. Do not load for unrelated work.
Execute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance first, then code quality.
Why subagents: Fresh subagents have isolated context. By precisely crafting their instructions, you ensure they stay focused. They should never inherit the 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. inline execution:
using-git-worktrees if neededFor each task:
Dispatch implementer subagent using ./implementer-prompt.md template
Handle implementer status:
DONE → proceed to spec reviewDONE_WITH_CONCERNS → read concerns, address if correctness/scope issue, then proceedNEEDS_CONTEXT → provide missing info, re-dispatchBLOCKED → assess: provide more context / upgrade model / break task smaller / escalate to humanDispatch spec compliance reviewer using ./spec-reviewer-prompt.md
Dispatch code quality reviewer using ./code-quality-reviewer-prompt.md
Mark task complete in TodoWrite
finishing-a-development-branch skillFleet policy: Composer 2.5 only — omit Task model for composer-2.5[fast=false] (default), or pass model: fast for shallow tasks. Never pass Sonnet/Opus/GPT.
| Task type | Model |
|---|---|
| Isolated functions, clear spec, 1-2 files | fast |
| Multi-file coordination, integration concerns | omit Task model (frontmatter default) |
| Architecture, design, broad review | omit Task model (frontmatter default) |
DONE: Proceed to spec compliance review.
DONE_WITH_CONCERNS: Read concerns before proceeding. If correctness/scope concerns → address first. If observations (file getting large, etc.) → note and proceed.
NEEDS_CONTEXT: Provide missing information and re-dispatch.
BLOCKED:
Never ignore an escalation or force the same model to retry without changes.
Never:
./implementer-prompt.md — Dispatch implementer subagent./spec-reviewer-prompt.md — Dispatch spec compliance reviewer./code-quality-reviewer-prompt.md — Dispatch code quality reviewerRequired before starting:
using-git-worktrees — Set up isolated workspaceCreates the plan this skill executes:
writing-plansSubagents should use:
test-driven-development — For each implementation taskAfter all tasks complete:
finishing-a-development-branchOrchestrate continual learning by delegating transcript mining and AGENTS.md updates to the knowledge-synthesizer subagent. Use when asked to mine prior chats, maintain AGENTS.md, update learned preferences, or run the continual-learning loop.
Security-focused review of code diffs and PRs with surface classification and Semgrep on changed files. Use when reviewing pull requests, branch diffs, or validating security regressions before merge.
Live Notion session log (L4b) — create, incremental updates during work, finalize on CLOSE. Works on any Cursor project workspace.
Bootstrap a new project with Cursor-ready configuration: AGENTS.md, per-project .cursor/rules/project-conventions.mdc, and optional memory_bank/ scaffold. Use at project initialization, when starting a new repo, or when the user says "set up Cursor for this project" / "bootstrap this project" / "init project config".
Phase-1 repo reconnaissance as a standalone skill: stack detection, relevant files, validation commands from repo evidence, workflow hints, and risk flags. Use inside /scout, /ks-conductor pre-flight, or any read-only discovery before planning or implementation.
Validates phase outputs before advancing the SDLC. Defines expected artifacts per phase (intake, scout, plan, critic, build, test, review, document, close) and produces a clear PASS / CONDITIONAL / BLOCK verdict with gaps. Use at orchestrator or command phase boundaries, before expensive work, or when the user asks to verify a gate or "are we ready to proceed".