brainstorming · Creative Design Before Code
brainstorming is the design discipline before any code gets written: it turns a rough idea into a confirmed design through collaborative dialogue. Each request is classified first — Spike (feasibility check), Bounded (small change to existing code), or Architectural (new project or subsystem) — then worked through the matching path: uncovering intent, writing back an understanding for correction, and presenting a design that only proceeds on approval.
Every path ends in a hard approval gate: no confirmed design, no implementation. Architectural work additionally produces a written spec document.
Example invocation: "Design a user feedback feature — no code yet, design first."
Full brief
Positioning
brainstorming is the creative design process before code: collaborative dialogue that turns a fuzzy idea into an approved design and spec. It decides "what to build and what good looks like" — it never writes product code, and nothing is done until the design is approved.
Core capabilities
- Three-path classification: Spike (a feasibility question; output is an answer, not kept code), Bounded (a well-scoped change to existing code), Architectural (new projects, subsystems, or interface changes). The classification is stated up front and can be overridden.
- One-way ratchet: when in doubt, take the heavier path; hidden complexity upgrades the path mid-task — never downgrades.
- Hard approval gates: spike needs the question and probe approved; bounded needs the in-chat design approved; architectural needs the written spec reviewed before moving to implementation planning. Approval covers only the stage actually presented.
- Intent discovery: one question at a time, multiple-choice preferred; the understanding is written back as a correctable note, separating what was said from what's assumed.
- Architectural depth: 2–3 approaches with trade-offs and a recommendation, sectioned design, spec self-review (placeholders, contradictions, scope, ambiguity), committed to
docs/superpowers/specs/. - Read-only exploration: before approval, only read-only project exploration is allowed — no implementation actions.
Workflow
- Classify and announce the path (Spike / Bounded / Architectural)
- Explore project context: files, docs, recent commits
- Clarify one question at a time: purpose, constraints, success criteria
- Present the design: spike = question + probe plan; bounded = short in-chat design (approach, files, tests); architectural = approaches + sectioned design
- Get approval: the hard gate — no confirmation, no implementation
- Architectural: write spec → self-review → user review → hand off to writing-plans
Inputs & outputs
| Input | Notes |
|---|---|
| Idea / request | Features, components, behavior changes; the more purpose and constraints given, the fewer clarifying questions |
Output by path: Spike — feasibility findings and recommendation; Bounded — short in-chat design; Architectural — written design document (docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md) and the agreed understanding.
Boundaries with adjacent skills
- executing-plans: executes a finalized implementation plan; brainstorming produces the design and consensus upstream of it.
- requesting-code-review: reviews code already written; brainstorming governs design before code.
Fit
- Clarifying requirements, constraints, and success criteria before building
- Architecture decisions for new projects, subsystems, or interface changes
- "Can we even do this" feasibility probes at minimum cost
- Capturing ideas as reviewable design documents for team collaboration
Before you start
- No API key; the skill reads the project repo (files, docs, commit history).
- Approval gates are hard — budget review time; unapproved designs never proceed to implementation.
- The architectural path's deliverable is a written spec; implementation planning is handed to writing-plans. This skill writes no product code.
brainstorming is part of the Aiglade Skill library. Invoke it from the Aiglade chat box in plain language.