brainstorming

Files (7)

• SKILL.md
• frame-template.html · scripts/
• helper.js · scripts/
• server.cjs · scripts/
• start-server.sh · scripts/
• stop-server.sh · scripts/
• visual-companion.md

SKILL.md (first lines)

# Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and PRDs through natural collaborative dialogue.

Start by understanding the intended outcome and the existing code, then choose
the amount of planning the task needs. Reflect the outcome and constraints back
briefly; ask only for information the request and code do not supply.

## Choose the Path

State the path and why it fits:

- **Spike:** a feasibility question whose deliverable is an answer. Define the
  question and a small probe, investigate, and report evidence and limitations.
  Label any prototype throwaway; keeping it as production code needs a design.
- **Bounded:** a change to an existing flow with clear scope and interfaces.
  Inspect that flow, present a short design in chat with the behavioral checks,
  and use the existing approval if that exact design was already accepted.
  After approval, implement with `dmi-superpowers:test-driven-development`,
  verify with `dmi-superpowers:verification-before-completion`, and review the
  change. No separate PRD, TSP, or grilling ceremony is required.
- **Architectural:** a new subsystem, new project, or change to shared
  interfaces or component boundaries. Follow the architectural checklist below.

Classify by the work, not the deadline or requested line count. If a bounded
change exposes a new shared contract or unresolved architectural decision,
reclassify it before implementing the expanded scope. A concrete dependency or
behavior question needs an answer; a previously approved design does not need
another approval just because the session resumed.

<HARD-GATE>
For production implementation, present a design and obtain approval for that
design before writing code or scaffolding. Existing approval of the same design
counts. A spike authorizes only its agreed investigation, not production work.
Architectural work also follows the written-PRD review below. Read-only
exploration can proceed while a necessary decision is unresolved.
</HARD-GATE>

## Anti-Pattern: "This Is Too Simple To Need A Design"

Every production change needs an understood design. For bounded work, a few
sentences in chat and concrete checks are enough. New projects follow the
architectural path even when their first implementation looks small.

## Architectural Checklist

For architectural work, create a task for each item and complete them in order.
Bounded work and spikes finish through their paths above.

1. **Explore project context** — check files, docs, recent commits
2. **Offer the visual companion just-in-time** — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.
3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
4. **Propose 2-3 approaches** — with trade-offs and your recommendation
5. **Present design** — in sections scaled to their complexity, get user approval after each section
6. **Write PRD** — save to `docs/PRDs/MM-DD-YYYY-<topic>.md` and commit
7. **PRD self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
8. **User reviews written PRD** — ask user to review the PRD file before proceeding
9. **Harden PRD** — invoke `dmi-superpowers:grill-with-docs` to stress-test the PRD against the domain model
10. **Transition to implementation** — invoke `dmi-superpowers:writing-plans` to create TSP

## Architectural Process Flow

```dot
digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write PRD" [shape=box];
    "PRD self-review\n(fix inline)" [shape=box];
    "User reviews PRD?" [shape=diamond];
    "Invoke grill-with-docs\n(harden PRD)" [shape=doublecircle];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write PRD" [label="yes"];
    "Write PRD" -> "PRD self-review\n(fix inline)";
    "PRD self-review\n(fix inline)" -> "User reviews PRD?";
    "User reviews PRD?" -> "Write PRD" [label="changes requested"];
    "User reviews PRD?" -> "Invoke grill-with-docs\n(harden PRD)" [label="approved"];
    "Invoke grill-with-docs\n(harden PRD)" -> "Invoke writing-plans skill";
}
```

**The architectural path ends by invoking grill-with-docs, then writing-plans.**
After the user approves the PRD, invoke `dmi-superpowers:grill-with-docs` to harden
it against the domain model, then `dmi-superpowers:writing-plans` to create the TSP.

## The Process

**Understanding the idea:**

- Check out the current project state first (files, docs, recent commits)
- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
- If the project is too large for a single PRD, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own PRD → TSP → implementation cycle.
- For appropriately-scoped projects, ask questions one at a time to refine the idea
- Prefer multiple choice questions when possible, but open-ended is fine too
- Only one question per message - if a topic needs more exploration, break it into multiple questions
- Focus on understanding: purpose, constraints, success criteria

**Exploring approaches:**

- Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why

**Presenting the design:**

- Once you believe you understand what you're building, present the design
- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense

From HundredBillion/dmi_superpowers, MIT.

More from HundredBillion/dmi_superpowers