superflow

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Scan the repo end-to-end and write CODEBASE_RULEBOOK.md — the conventions every future code change is checked against. Use when the user runs /superflow:codebase-rulebook, asks to generate or refresh the rulebook, or when non-trivial code work is starting and no CODEBASE_RULEBOOK.md exists at the repo root.

Summarize the current diff and propose a commit message, without committing unless explicitly asked. Use when the user runs /superflow:commit-prep or asks what changed / for a commit message before committing.

Multi-voice deliberation on a hard, expensive-to-reverse architectural or product decision — independent schema-forced votes from each persona, synthesized by architect. Use when the user runs /superflow:council or explicitly asks for a full council on a decision.

Fast session start — where you left off and what to do next, reconstructed from git state and recent work. Use when the user runs /superflow:daily-brief or asks to pick up where they left off.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Full session handoff — what changed, current state, verified vs not, pending work, next steps, and watch-outs, so another session can resume cleanly. Use when the user runs /superflow:handoff or asks for a handoff or wrap-up before switching context.

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 completing tasks, implementing major features, or before merging to verify work meets requirements

The front door for non-trivial coding work in this repo — pairs a process skill (brainstorming for builds, systematic-debugging for bugs, receiving-code-review for review feedback) with the right specialist persona, in the right order. Load when deciding how to approach a build, bug, review, or design task, or when unsure which skill/persona applies.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

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

A step-by-step method for turning a complex, cluttered screen into a simpler one — structure before styling. Load before the taste pass whenever a screen is multi-section, does more than one job, or the user says "simplify", "declutter", "clean up", "messy", "cluttered", or "busy". Used by the designer persona's reduction gate.

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 starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions

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

Use when you have a spec or requirements for a multi-step task, before touching code