/ctx-brainstorm-ss — Deep Design Exploration
Same core as /ctx-brainstorm but with fresh-context review and stronger guardrails for complex work. The SS tax is 3-4x tokens — only pay it when the problem warrants it.
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any
implementation action until you have presented a design and the user has approved it.
Process
- Explore context — check files, docs, recent commits relevant to the idea
- Scope check — if the request covers multiple independent systems, decompose into sub-projects first. Each sub-project gets its own spec -> plan -> implementation cycle. Brainstorm the first sub-project through the normal flow.
- Visual factory gate — before asking any questions, evaluate: will this brainstorm involve architecture diagrams, layout comparisons, option cards, or spatial content? If yes, offer the factory as its own message and wait for the user's response before continuing (read
${CLAUDE_PLUGIN_ROOT}/skills/ctx-brainstorm/references/factory-guide.md). If no, proceed directly to questions — no extra message.
- Ask questions — one at a time, prefer multiple choice, understand purpose/constraints/success criteria
- Propose 2-3 approaches — with tradeoffs, lead with your recommendation. If the factory is active, present visually.
- Present design — sections scaled to complexity, get approval incrementally. Apply design-for-isolation (see below).
- Write spec — save to
docs/specs/YYYY-MM-DD-<topic>-design.md, commit
- Spec review loop — dispatch reviewer subagent (see below), fix issues, re-dispatch until approved (max 3 iterations, then surface to user)
- User reviews spec — ask user to review the written spec before proceeding
- Tag complexity — mark each planned unit (see
${CLAUDE_PLUGIN_ROOT}/skills/ctx-brainstorm/references/complexity-tags.md)
Design-for-Isolation
When presenting the design (step 6), apply these principles:
- Break the system into units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
- For each unit, answer: what does it do, how do you use it, what does it depend on?
- Can someone understand a unit without reading its internals? Can you change internals without breaking consumers? If not, the boundaries need work.
- Smaller, well-bounded units are easier for agents to work with — they reason better about code they can hold in context, and edits are more reliable when files are focused.
Spec Review Loop
After writing the spec (step 7), dispatch a fresh-context reviewer:
- Read
${CLAUDE_SKILL_DIR}/references/spec-reviewer-prompt.md for the dispatch template
- Dispatch via Agent tool (
subagent_type: "general-purpose") with the spec file path
- If Issues Found: fix the issues in the spec, re-dispatch. Repeat until Approved.
- Max 3 iterations. If still failing after 3 rounds, surface remaining issues to the user for guidance.
- If Approved: proceed to user review (step 9)
The reviewer has fresh context — no accumulated assumptions from the brainstorming conversation. This is the whole point: blind spots you've normalized get caught.
Key Principles
- One question at a time — don't overwhelm
- YAGNI ruthlessly — remove speculative features
- Pattern audit before new abstractions — search before inventing
- Incremental validation — present design, get approval, then proceed
- Scope decomposition first — if it's too large for one spec, break it up before diving in
- Design for isolation — every unit should be independently understandable and testable
- Context budget — if past 5 questions and still unclear, summarize what you know and ask "what am I missing?"
Gotchas
- "Too simple to need a design": Every project goes through this process. "Simple" projects are where unexamined assumptions cause the most wasted work.
- Over-engineering abstractions: Before proposing a context/provider/service, search the codebase for existing patterns. The simpler pattern usually exists already.
- Reviewer disagreement loops: If the reviewer keeps flagging the same section after your fix, the spec likely has a genuine ambiguity. Surface it to the user — don't keep iterating in a loop.
- Tag drift: Complexity tags can be wrong —
/ctx-execute should re-classify mid-flight.
- Question marathon: If you're past 5 questions and still unclear, stop asking and summarize what you know. Ask "what am I missing?" instead of question #6.
- Inventing thresholds that already exist: When designing states or edge cases for a component that consumes an existing utility, derive the cases from that utility's thresholds — don't invent new ones. Run
Grep for the source function before proposing breakpoints.
- Proposing new API work when data already flows: Before suggesting backend changes to serve data, trace the data path from where it's consumed: component → hook/query → API endpoint. The endpoint often already returns what you need — you just haven't followed the chain. If you've read a component that has the data, ask "where does this come from?" and trace upstream before proposing new API fields.
- Proposing implementation details without checking conventions: Before recommending specific libraries, patterns, or API styles in the design, check CLAUDE.md for project conventions. The brainstorm output feeds directly into implementation — wrong conventions here propagate downstream.
- Skipping factory for visual content: Architecture diagrams, A/B/C option cards, layout comparisons, and design decisions are visual — use the factory. Text walls with ASCII art are not a substitute. If you're about to present 3+ options with diagrams or spatial content, that's a factory question. The gate at step 3 exists because by the time you're synthesizing, you've already committed to text mode and won't backtrack.
Skill Files
SKILL.md — this file (process, reviewer loop, design principles)${CLAUDE_SKILL_DIR}/references/spec-reviewer-prompt.md — subagent dispatch template- Shared with brainstorm:
${CLAUDE_PLUGIN_ROOT}/skills/ctx-brainstorm/references/complexity-tags.md, ${CLAUDE_PLUGIN_ROOT}/skills/ctx-brainstorm/references/factory-guide.md
- Shared factory server:
${CLAUDE_PLUGIN_ROOT}/skills/ctx-brainstorm/factory/
Handoff
When the spec is approved, reviewed, and tagged, the ONLY next step is /ctx-plan. Do NOT invoke /ctx-execute, /ctx-ship, or any implementation skill directly from brainstorm.
/ctx-brainstorm-ss → /ctx-plan (ONLY valid next skill)
The complexity tags you set here drive the agent budget in /ctx-execute.