Menu
Turn a rough idea into a reviewed design spec before any implementation.
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
Step-by-step teaching mode for implementation guidance. Use when the user asks Codex to teach them how to implement a change themselves, says "use instruct", "teach me step by step", "walk me through implementing", "show me incrementally", or otherwise wants guidance-first coding help instead of Codex directly editing files.
Guidance for designing, writing, reviewing, or refactoring tests in this project. Use when adding tests for features or bugs, deciding unit vs integration boundaries, choosing what to mock, improving test structure, or reducing brittle/slow/flaky tests.
Debug issues using a structured, evidence-first process.
Execute a written implementation plan in this session with checkpoints.
Execute a written implementation plan task-by-task using pi subagents with review gates.
Verify tests, present merge options, and clean up a finished branch.
| name | brainstorm |
| description | Turn a rough idea into a reviewed design spec before any implementation. |
| disable-model-invocation | true |
You are running the brainstorm skill. This is a manual workflow. Use it only because the user explicitly invoked it.
Turn the user's idea into a reviewed design before any implementation work begins.
Do not write code, scaffold files, invoke implementation workflows, or take implementation actions until all of the following are true:
Track progress through each step internally and complete them in order. Do not print a checklist by default; only summarize progress when it is useful for orientation or when the user asks for it.
Before asking design questions, inspect the current project:
Build enough context to ask good questions and avoid proposing designs that fight the existing codebase.
If the request spans multiple independent subsystems, say so early and help the user decompose the work. Brainstorm only the first coherent slice instead of trying to design everything at once.
Ask one question per message.
Focus on:
Prefer multiple-choice questions when possible, but use open-ended questions when needed.
If the topic is likely to involve visual layout or structure, you may offer to use mockups or diagrams, but keep that offer separate from the clarifying question itself.
When you understand the problem well enough, propose 2-3 approaches.
For each approach, cover:
Lead with the recommended option and explain why.
Present the design in sections sized to the complexity of the work. Typical sections:
After each section, ask whether it looks right so far before moving on.
Keep the design concrete. Avoid vague statements like "add error handling" or "write tests" without specifying what errors matter or what behavior must be tested.
Prefer designs with:
Follow the existing project's patterns. If the current codebase has an issue that materially affects this work, include the smallest targeted improvement needed to support the feature cleanly. Do not turn the session into unrelated refactoring.
After the user approves the design, write it to:
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
If the user prefers a different location, use that instead.
The written spec should be precise enough that the write-plan skill can turn it into an implementation plan without having to rediscover the design.
After writing the spec, read it again and fix issues inline:
TBD, TODO, and vague requirements.After self-review, ask the user to review the written spec before moving on.
Use this handoff:
Spec written to
<path>. Please review it and let me know what you want to change before we move on to planning.
Wait for the user's response.
If they request changes, update the spec and re-run the self-review.
Once the user approves the written spec, recommend the write-plan skill as the next step.