superdev

Activate the superdev workflow for the rest of the conversation (alias of /superdev:superdev)

Use to obtain a critical review of an implementation plan via Google Gemini CLI when the run state is `gemini` (i.e. codex has hit quota and gemini is the current coder family). Pass the absolute repo path on the first line and the plan text below it. Returns gemini's critique tagged AGREE / CONCERN / QUESTION / SUMMARY, verbatim. Mirrors codex-reviewer's contract so the orchestrator can swap dispatch with zero prompt changes.

Use when planning a non-trivial feature for multi-engineer parallel implementation via EM-led peer-debate planning. Translates requirements into a complete planning bundle at docs/<feature-slug>/ (README, planning, tasks, engineer-N-tasks, engineering-standards, and optionally allocations.md) by dispatching 2 max-effort senior-engineer subagents in parallel (default biases - Pragmatism vs Rigor), running a bounded peer debate (≤ 2 rounds, EM-orchestrated alternating turns), handing the result to a max-effort staff-engineer subagent for adjudication + task decomposition, and optionally allocating engineer slots to named team members (Phase 7, only when a team roster is provided in Phase 3). Sits alongside em-ship-feature in the em-* family — em-feature-plan plans, em-ship-feature ships. Implicit triggers - "plan this feature", "two engineers debate this design", "EM plan this", "split this across the team with debate", "act as engineering manager to plan this feature", "plan and allocate this feature to my team". Composes with team-brainstorm upstream and em-ship-feature downstream.

Use when shipping a feature whose plan exists at docs/<feature-slug>/ — typically the artifact set produced by /superdev:em-feature-plan (tasks.md, engineer-*-tasks.md, engineering-standards.md, planning.md, and optionally allocations.md). Consumes the plan and ships it autonomously - one max-effort senior-engineer subagent per task in DAG-driven parallel waves, each senior delegates coding to codex → gemini → claude sonnet (run-wide quota fallback chain), per-task senior↔coder debate bounded to 2 rounds, single max-effort staff-engineer review across bugs · simplification · codebase style. If allocations.md is present (from em-feature-plan Phase 7), auto-detects it and attributes per-task ownership to named team members in commits (Co-Authored-By) and the execution-report.md Owner column; graceful fallback to slot-only if absent. Produces a live-updated docs/<feature-slug>/execution-report.md as the single deliverable. Requires /effort max and --dangerously-skip-permissions to be active, and a clean working tree. Sits alongside em-feature-plan in the em-* family — em-feature-plan plans, em-ship-feature ships. Implicit triggers - "ship this feature", "execute the plan", "EM-run this feature", "build out the tasks", "let the team ship this", "go build this end-to-end".

Use when designing a new feature before implementation — to gather requirements, designs, and engineering perspectives through a multi-agent pipeline. Seven phases - (1) identify work area / entry points / screens, (2) acquire designs (Figma MCP, screenshots, references), (3) gather requirements per entry point and per screen, (4) fan out 6 specialist parallel agents (Senior UI/UX, two senior engineers from the current platform, one senior engineer from the opposite platform for cross-pollination, backend engineer for response-shape check, QA engineer for test cases), (5) debate disagreements with staff-engineer adjudication, (6) staff-engineer web research for current best practices and synthesis, (7) produce a short brainstorm document with feature description, short plan, open questions, and concerns. Use before /superdev:superdev when a feature is non-trivial; the brainstorm document becomes the input to superdev's plan phase.

Use when reviewing code changes — PR diffs, branch diffs, or specific file changes — through a multi-agent pipeline. Spawns 7 specialist parallel reviewers (code standards / team style, architecture, clean code, simplification, market standards [SOLID · Clean Architecture · DDD], bug detection, security), aggregates findings via a staff engineer, runs a debate phase on disputed findings, proposes and debates solutions, and produces a structured findings checklist with file:line references and team-recommended solutions. Use for PR review, pre-merge review, security audit, periodic codebase review, or end-of-implementation review (composes with superdev Phase 5/6).

Use when planning a non-trivial feature for multi-engineer parallel implementation — translates requirements into architecture, plan, and per-engineer task packets via a staff-engineer pipeline. Eight phases - (1) input + slug, (2) codebase grounding (parallel reads of layering, DI, test harness) + per-requirement validation for edge cases and bottlenecks, (3) clarifying questions before design, (4) staff-engineer architecture applying TDD red-then-green, DDD, Clean Architecture, SOLID at module/class/function, interface-first DI, (5) 3 parallel architect agents (Clean Architecture, DDD, SOLID/Testability) + senior-architect adjudicator, (6) task decomposition with foundation tasks (senior-only, runs first to avoid shared-interface conflicts) + engineer headcount, (7) senior-architect debate on the full package, (8) write artifacts to docs/<feature-slug>/: architecture.md, plan.md, tasks.md, engineer<i>-tasks.md per engineer. Output flows into superdev.