メニュー
Use when executing implementation plans with independent tasks in the current session
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before any DevOps build, change, or new feature — refine requirements through dialogue before touching infrastructure or code
Use when working with Docker — building images, writing Dockerfiles, debugging container issues
Use to execute a written implementation plan via subagents with review checkpoints
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 working with Kubernetes or Helm — authoring, reviewing, hardening, or debugging manifests, Deployments, Services, Ingress, RBAC, NetworkPolicy, or cluster operations
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
| name | subagent-driven-development |
| description | Use when executing implementation plans with independent tasks in the current session |
Execute a plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.
Core principle: Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration.
Narration: between tool calls, narrate at most one short line — the ledger and the tool results carry the record.
Use when:
vs. Executing Plans (parallel session):
Before dispatching Task 1, scan the plan once for conflicts:
Present everything you find to your human partner as one batched question — each finding beside the plan text that mandates it, asking which governs — before execution begins, not one interrupt per discovery mid-plan. If the scan is clean, proceed without comment.
Setup: Read plan, extract all tasks with full text, note context, create TodoWrite.
Per task:
After all tasks:
superpowers-devops:finishing-a-development-branchUse 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 a fast, cheap model. Integration and judgment tasks (multi-file coordination, debugging): use a standard model. Architecture and design tasks: use the most capable available model. Review tasks: choose the model scaled to the diff's size, complexity, and risk.
Always specify the model explicitly when dispatching a subagent. An omitted model inherits your session's model — often the most capable and most expensive — which silently defeats this section.
Turn count beats token price. Wall-clock and context cost scale with how many turns a subagent takes. Use a mid-tier model as the floor for reviewers and for implementers working from prose descriptions.
Task complexity signals (implementation tasks):
Never ignore a BLOCKED status or force retry without changes.
The task reviewer may report "⚠️ Cannot verify from diff" items — requirements that live in unchanged code or span tasks. These do not block the rest of the review, but you must resolve each one yourself before marking the task complete: you hold the plan and cross-task context the reviewer lacks. If you confirm an item is a real gap, treat it as a failed spec review — send it back to the implementer and re-review.
./implementer-prompt.md — Dispatch implementer subagentsuperpowers-devops:requesting-code-review for reviewer subagentsNever:
Required workflow skills:
Alternative: