Brainstorming Ideas Into Designs

Turn ideas into fully formed designs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.

Adam-Specific Calibration

Adam's user profile says "action over planning, hates filler." That's true — but he confirmed (2026-04-27) that brainstorming itself does produce better results when used appropriately. So the rule isn't "skip brainstorming," it's "don't pad it":

Use brainstorming when: scope is ambiguous, multiple architecture choices exist, the work touches a system Adam knows better than you, or the design has irreversible consequences
Skip brainstorming when: the task is mechanical (porting a skill, fixing a typo, applying a documented fix), or Adam has already specified the design in his message
Compress aggressively: scale section length to complexity. A trivial spec might be 3 sentences. Don't pad to look thorough.
Adam's Mom Test instinct: he prefers concrete "would you actually use this" framing over abstract requirements. Lean into that.

Hard Gate

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. The design can be short — but it must exist and be approved.

Anti-Pattern: "Too Simple to Need a Design"

Even one-function utilities benefit from a 3-sentence spec. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be tiny — but it must be presented and approved.

Checklist

For each project, complete in order (use todo to track):

Explore project context — search_files, read_file, recent commits, related Obsidian notes
Ask clarifying questions — one at a time via clarify tool when possible (multiple choice preferred over open-ended)
Propose 2-3 approaches — with trade-offs and your recommendation
Present design — sections scaled to complexity, get approval after each
Write design doc — save to ~/obsidian-vault/projects/<project>/specs/YYYY-MM-DD-<topic>.md (Adam's vault location, NOT docs/superpowers/specs/)
Spec self-review — placeholder scan, internal consistency, scope check, ambiguity check
User reviews written spec — only proceed once Adam approves
Transition to implementation — invoke writing-plans skill

Process Flow

Explore project context
  ↓
Ask clarifying questions (one at a time)
  ↓
Propose 2-3 approaches → user picks/refines
  ↓
Present design sections → user approves each
  ↓
Write design doc to vault
  ↓
Spec self-review → fix inline
  ↓
User reviews spec → approves
  ↓
Invoke writing-plans

Terminal state is writing-plans. Do NOT invoke other implementation skills directly from brainstorming.

The Process

Understanding the idea

Check current project state first (files, docs, recent commits, vault notes via obsidian skill)
Before detailed questions, assess scope: if request describes multiple independent subsystems ("build a platform with chat, file storage, billing, analytics"), flag immediately. Don't refine details of a project that needs decomposition first.
For appropriately-scoped projects, ask questions one at a time
Prefer multiple choice (clarify tool with 2-4 choices); open-ended fine when needed
Only one question per message — break topics into multiple questions if they need more exploration
Focus on: purpose, constraints, success criteria

Exploring approaches

Propose 2-3 different approaches with trade-offs
Lead with your recommended option and explain why
Adam responds well to comparison tables — use them when 3+ approaches differ on multiple axes

Presenting 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
Cover: architecture, components, data flow, error handling, testing
Be ready to go back and clarify

Design for isolation and clarity

Break system into smaller units with one clear purpose, well-defined interfaces, independently testable
For each unit, you should be able to answer: what does it do, how do you use it, what does it depend on?
If a file grows large, that's often a signal it's doing too much

Working in existing codebases

Explore current structure before proposing changes. Follow existing patterns.
Where existing code has problems affecting the work (oversized file, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design
Don't propose unrelated refactoring. Stay focused.

After the Design

Documentation

Write validated design to ~/obsidian-vault/projects/<project>/specs/YYYY-MM-DD-<topic>.md
Include frontmatter: tags: [spec, <project>], type: spec, created: YYYY-MM-DD, quality: draft
Update vault index.md and log.md per knowledge-discipline skill
Commit if vault is git-tracked

Spec self-review

After writing, look with fresh eyes:

Placeholder scan: Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
Internal consistency: Do sections contradict each other? Does architecture match feature descriptions?
Scope check: Focused enough for a single implementation plan, or needs decomposition?
Ambiguity check: Could any requirement be interpreted two ways? Pick one and make it explicit.

Fix issues inline. No need to re-review — fix and move on.

User review gate

"Spec written and committed to <path>. Please review and let me know if you want changes before we move to the implementation plan."

Wait for response. If changes requested, make them and re-run spec review. Only proceed once approved.

Implementation

Invoke writing-plans to create the detailed implementation plan. Do NOT invoke other skills.

Key Principles

One question at a time — don't overwhelm
Multiple choice preferred — easier to answer (clarify with choices)
YAGNI ruthlessly — remove unnecessary features
Explore alternatives — propose 2-3 approaches before settling
Incremental validation — present design, get approval before moving on
Be flexible — go back and clarify when needed
Compress for Adam — match section length to actual complexity

When to skip brainstorming entirely

The task is mechanical and well-documented (porting a skill, applying a known fix)
Adam's message already specifies the design ("port these 3 skills to Hermes — copy frontmatter pattern from existing ports")
The task is a one-liner change (config flag, typo fix, version bump)
You're inside an existing skill's documented workflow

In these cases, just execute. Skipping a 3-second brainstorm to deliver a finished result is the right call.

When NOT to skip

New feature (even "small")
Schema/API contract change
Anything touching billing, auth, or production data
Migration or one-way decision
Cross-agent or cross-system coordination
Ambiguous scope ("make it better", "speed it up")

If unsure: brainstorm. The cost of an unwanted question is one message; the cost of an unwanted refactor is hours.

Brainstorming