Menu
Use when a feature, refactor, or fix needs an implementation plan before coding - turning an approved spec, ticket, or explicit user request into an executable, verifiable plan document.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when reviewing code, a diff, a module, an architecture, or a design/spec document against house standards - including multi-expert panel reviews ("review with a DDD expert and an asset-finance expert"). Also when running a removal-first simplification sweep: "what can we remove", "product simplification review".
Use when executing an implementation plan or building a scoped feature or fix - after scope is clear, before code gets written. Triggers on "implement the plan at PATH", "start slice SP-2b".
Use when investigating any bug, error, crash, stack trace, failing or flaky test, incident, regression, unexpected behavior, or "why is this happening" question - before proposing or applying a fix.
Use when an implementation needs proof against the live running stack: after build completes, before ship, or when asked to verify, e2e-test, smoke-test, or demo that an API, UI, or DB change actually works.
Use when building or styling sportsbook, betting, or casino (iGaming) interfaces: odds displays, betslips, live-event states, suspended markets, casino game grids, or wallet and money surfaces.
Use when writing or reviewing code that posts, holds, voids, reverses, or reconciles money movements - double-entry postings, wallet balances, idempotency keys, FX conversion, or Blnk / pgledger integration.
| name | plan |
| description | Use when a feature, refactor, or fix needs an implementation plan before coding - turning an approved spec, ticket, or explicit user request into an executable, verifiable plan document. |
Plans are repo artifacts, not chat messages. They are also the durable session state - a fresh session must be able to pick one up and continue.
Follow the repo's existing convention: docs/superpowers/plans/ where established, else docs/plans/. Naming matches the repo's pattern: YYYY-MM-DD-<slug>-plan.md, with phase/ticket codes when in use (sp2b, l7, 2a-backend). Split large work into paired plans (backend/frontend, a/b) like the existing corpus.
docs/adr/ convention when one exists.Done when any slice could be executed by a fresh session without questions, and every slice says how it will be verified. As short as completeness allows - no essay sections. Execution proceeds slice by slice via build.