brainstorming
Brainstorming Ideas Into Designs
Overview
Help turn ideas into fully formed designs and specs 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 in small sections (200-300 words), checking after each section whether it looks right so far.
The Process
Understanding the idea:
- Check out the current project state first (files, docs, recent commits)
- 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
- Focus on understanding: purpose, constraints, success criteria
Exploring approaches:
- Propose 2-3 different approaches with trade-offs
- Lead with your recommended option and explain why
Presenting the design:
- Present once you believe you understand what you're building
- Break into sections of 200-300 words, validate each
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense
After the Design
Documentation:
- Write the validated design to
docs/plans/YYYY-MM-DD-<topic>-design.md - Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git
Implementation (if continuing):
- Ask: "Ready to set up for implementation?"
- Use superpowers-bd:using-git-worktrees to create isolated workspace
- Use superpowers-bd:writing-plans to create detailed implementation plan
Key Principles
- One question at a time; prefer multiple choice
- YAGNI ruthlessly -- remove unnecessary features
- Always propose 2-3 approaches before settling
- Present design in sections, validate each incrementally
More from schlenks/superpowers-bd
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
10writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment
9dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
9epic-verifier
Use when all implementation tasks in an epic are closed, before calling finishing-a-development-branch
8rule-of-five-tests
Use when writing 50+ lines of test code, adding test suites, or before claiming test work complete - apply 5 focused passes (Draft, Coverage, Independence, Speed, Maintainability) to catch issues single-shot generation misses
8systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
8