Menú
Use when executing implementation plans with independent tasks in the current session
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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: