super-puper-powers

Use when specs are approved (phase 4 approved in docs/spp/pipeline-state.md) OR when the user directly asks to turn a spec into an implementation plan outside a running pipeline (e.g. "turn this spec into an implementation plan") - writes implementation plans as bite-sized tasks to docs/spp/05-plans/ for subagent-driven execution

Use after completing a task or major feature, before merging, or when the user asks to review a branch, PR, or work-in-progress diff. Run independent Standards and Spec reviews so clean code cannot hide the wrong behavior and correct behavior cannot hide broken standards.

Diagnose bugs, test failures, build failures, unexpected behavior, and performance regressions before proposing fixes. Build a tight reproduction loop, find the root cause, fix it once, and lock it down with a regression test.

Use when implementing any feature or bugfix, before writing implementation code

Use when starting any conversation - routes each request to a single SPP skill by default, running the full idea-to-deploy pipeline only when the user explicitly asks for "pipeline"

Use when a product is ready to ship, OR when the user directly asks how or where to deploy or to write a deploy runbook - chooses a deploy strategy with the owner in cost-and-consequence terms, then executes it into a repeatable runbook. Self-checks on disk for a fixed release version first — it warns and offers to fix it, it does not block.

Use when the user describes a product idea, OR directly asks to capture or write up a product idea brief - captures an idea brief through a one-question-at-a-time interview. Runnable standalone; if docs/spp/pipeline-state.md is absent it starts a fresh journal, if present it appends.

Use when the idea brief is approved (phase 0 approved in docs/spp/pipeline-state.md) OR when the user directly asks to check an idea for competitors, legal risk, or whether it is worth building, outside a running pipeline (e.g. "check this idea for competitors / legal risk / whether it is worth building") - researches competitors, legal risks, market and feasibility before any scoping, with an explicit right to stop the project

Use when MVP scope is approved (phase 2 approved in docs/spp/pipeline-state.md) OR when the user directly asks to pick a tech stack outside a running pipeline (e.g. "pick a tech stack for this") - picks the tech stack from 2-3 options judged by agent maintainability, running cost and time to MVP, explained in owner consequences

Use when spec-review passed and docs/spp/04-specs/ contains more than one spec - reviews the whole spec set for interface consistency, seam gaps, contradictions and build order

Use during phase 6, after implementation's final whole-branch review and before the acceptance demo (orchestrator-driven) - makes data storage explicit, verifies export, and checks storage boundaries and risks, writing docs/spp/06-data-boundaries.md; also runnable standalone when asked where a product's data lives or whether its storage and export are sound

Use when discovery is approved with a go decision (phase 1 approved in docs/spp/pipeline-state.md) OR when the user directly asks to draft an MVP scope outside a running pipeline (e.g. "draft an MVP scope / what should the first version do") - turns the brief and discovery report into a prioritized MVP scope built around a walking skeleton scenario

Use when plan-writing finished a plan after author self-review - dispatches a clean-context subagent to verify spec coverage, cross-task consistency and absence of placeholders before execution

Use when a product is deployed or about to be, OR when the user directly asks to set up monitoring or a feedback channel after release - sets up minimal monitoring and a feedback channel, then closes the loop back to new ideas.

Use during phase 6, after data-boundaries and before the acceptance demo (orchestrator-driven) - audits a built product for hidden pre-show risks (broken mobile, failing build, stray debug text, leaky export, input that breaks the UI) plus minimal security, writes docs/spp/06-pre-show-audit.md and turns blockers into fix-tasks; also runnable standalone when asked to check a product before showing it

Use when a development branch is complete and ready to become a release, OR when the user directly asks to fix a version, write release notes, or finish the branch - verifies the work, finishes the branch on the agent's own decision, fixes a semver version and writes owner-language release notes. Self-checks on disk for a passed acceptance demo first — it warns and asks for confirmation, it does not block.

Use when spec-writing finished a spec after author self-review - dispatches a clean-context subagent to adversarially review the spec against MVP scope before any planning happens

Use when stack is approved (phase 3 approved in docs/spp/pipeline-state.md) and specs are not yet written, OR when the user directly asks to write a spec outside a running pipeline (e.g. "write a spec for this feature/product") - designs the product through product-behavior questions only and writes implementation specs to docs/spp/04-specs/

Use when asked to check or fix basic accessibility (a11y) of an MVP's UI - runs a baseline audit of keyboard navigation, contrast, visible focus, form labels, error clarity and basic screen-reader support, then applies or lists fixes without expanding scope

Use when asked about GEO (generative engine optimization) or making a product understandable to AI assistants - packages a public page so AI and summary tools grasp what the product does, for whom, its limits and where the facts are; sibling of seo-baseline, does not duplicate search-engine packaging

Use when asked to make an MVP work on phones or check it on a narrow screen - a design-only responsive pass that stops the existing desktop UI from breaking on mobile (overflow, tap targets, forms) without touching the data model, features or scope

Use when asked for SEO baseline or to make a public page shareable - adds the technical page packaging (title, description, favicon, Open Graph preview, robots, sitemap, page structure) so links and previews look intentional

Use when asked to set up tests or a test runner for a project that has none - installs a test runner and one smoke test so behavior checks become a command, without requiring full coverage

Use when asked to write or improve UI text or microcopy - produces interface copy and states (empty, error, loading) from screen context, state and user action, scoped to the current scenario

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 executing implementation plans with independent tasks in the current session

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

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 starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always