메뉴
Use at the start of a non-trivial feature or change, before planning or coding, to refine a vague request into a short written spec through focused questions. Turns "build me X" into an agreed scope, so the plan and the code that follow do not chase a moving target.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.
Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.
Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.
Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.
Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.
Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.
| name | brainstorm-spec |
| description | Use at the start of a non-trivial feature or change, before planning or coding, to refine a vague request into a short written spec through focused questions. Turns "build me X" into an agreed scope, so the plan and the code that follow do not chase a moving target. |
| slipstream | {"category":"context","requires":[],"tags":["planning","design","discipline"]} |
A vague request coded straight away is the most expensive kind of work: you build the wrong thing, the user corrects you, and the budget pays for both versions. Brainstorming first is cheap insurance. The goal is a short spec both you and the user agree on, reached by asking the few questions that actually change the design rather than starting to type.
Keep it Socratic and bounded: ask only questions whose answers would change what you build, present real options with trade-offs, and stop as soon as the scope is clear. Then write the spec down so it survives compaction — save it as a slipstream memory and, for larger work, as a dated file under docs/specs/.
sp_remember the decisions (type decision), and for larger features save the spec to docs/specs/<short-name>.md so the next session and any plan build on it.A written spec exists with a one-line goal, explicit in-scope and out-of-scope lists, and success criteria the user has agreed to, and the durable decisions are saved to memory (npx slipstream memory list --root . shows them). If scope is still ambiguous, do not advance to planning or coding.