| name | supi-flow-brainstorm |
| description | You MUST use this before any implementation. Clarify intent, shape the design, and get approval before touching code. |
| disable-model-invocation | true |
Flow Brainstorm
Turn an idea into an approved design through focused collaboration. Default to lightweight conversation; add structure only when the change is larger, riskier, or likely to span sessions. No change is too small — unexamined assumptions cause the most rework.
Do NOT write code, scaffold anything, or take implementation action until you have presented a design and the user has approved it. This applies even to changes that seem simple.
Anti-Pattern: Stopping questions too early
The most common failure is jumping to approaches after 1-2 questions. The user nods along, you think you understand — but you haven't walked every branch. If you haven't covered purpose, non-goals, constraints, edge cases, and success criteria, you're not done. Ask another question.
Checklist
Complete these in order:
- Explore context — relevant files, docs, recent commits, existing tickets.
- Ask clarifying questions — one at a time, with a recommendation. Walk every branch of the decision tree before moving on.
- Propose 2-3 approaches — include trade-offs and a recommendation. One of the 2-3 should be intentionally "crazy" to surface overlooked ideas.
- Present the design — scale detail to complexity; get approval per section.
- Classify and persist — trivial (chat-only) or non-trivial (ticket). See below.
- Self-review — run the four checks.
- User review gate — pause for user review before proceeding.
- Handoff — present outcome, recommend next step.
Understanding the idea
- Check project state first. Follow existing patterns. Explore code, docs, and history before asking the user. Only ask when the answer requires judgment or intent.
- Flag multi-scope requests early. If the request spans independent changes, help decompose into sub-projects and brainstorm the first one.
- Ask one question per message, with a recommended answer. Guide — don't interrogate. The user can override, but shouldn't have to invent answers from scratch.
- Walk every branch relentlessly. Resolve dependencies between decisions one-by-one. For each answer, ask what it implies and what it rules out. Keep refining until goals, non-goals, constraints, edge cases, and success criteria are clear.
- Go back when needed. When a new answer contradicts an earlier assumption, loop back and clarify.
- Include targeted cleanup when it directly helps the work. Do not propose unrelated refactors.
Exploring approaches
- Propose 2-3 total approaches with trade-offs.
- Make one of those approaches intentionally "crazy" — unconventional, high-variance, or overpowered for the problem — so you can surface ideas that a conservative design might miss.
- Lead with your recommendation and say why.
- Prefer simple, well-bounded designs for the final recommendation.
Presenting the design
Cover the parts that matter for the change: approach, main components/files, data/control flow, edge cases and error handling, testing and verification, docs to update. Scale each section to complexity.
Classify and persist
Trivial (single file, no tests/docs, one step, or "just do it"): keep the design in chat. Implement directly. No ticket.
Non-trivial (multi-file, needs tests/docs, multi-step, or likely multi-session): call supi_flow_start, then store the approved design via supi_tndm_cli update content. Task authoring happens later, during plan phase.
Retroactive escalation: if a trivial change grows mid-implementation, stop, call supi_flow_start, and store a summary of completed work plus new scope.
Self-review
Design Self-Review: After writing the design document, look at it with fresh eyes:
- Placeholder scan: Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
- Internal consistency: Do any sections contradict each other? Does the architecture match the feature descriptions?
- Scope check: Is this focused enough for a single implementation plan, or does it need decomposition?
- Ambiguity check: Could any requirement be interpreted two different ways? If so, pick one and make it explicit. Use specific, unambiguous language — every claim in the design should survive a different agent reading it without context.
Fix any issues inline. No need to re-review — just fix and move on.
User review gate
After the design is persisted, pause:
"Design is ready in <chat or ticket ID>. Please review it and let me know if you want to make any changes before we proceed."
Wait for approval. Rerun self-review after any changes.
Handoff
## Brainstorming Outcome
**Problem**: ...
**Recommended approach**: ...
**Why**: ...
**Constraints / non-goals**: ...
**Open questions**: ...
**Ticket**: TNDM-XXXXXX / none
Then recommend:
- Non-trivial:
/skill:supi-flow-plan TNDM-XXXXXX
- Trivial: proceed with direct implementation
For non-trivial work, do NOT invoke any implementation skill or write code. The ONLY next step after brainstorming is `/skill:supi-flow-plan`. Trivial work may proceed directly.
