Brainstorming
Run structured dialogue before coding so features, components, and behavior changes ship with agreed purpose, constraints, and a reviewed design—not improvised prompts.
Overview
brainstorming is a journey-wide agent skill that turns rough ideas into reviewed designs and specs through staged questions and sectional design review—usable whenever a solo builder needs to clarify intent before commit
Install
npx skills add https://github.com/davila7/claude-code-templates --skill brainstormingWhat is this skill?
- Hard requirement: use before any creative work—features, components, new functionality, or behavior changes
- Inspects current project state (files, docs, recent commits) before asking clarifying questions
- One question per message with preference for multiple-choice when it speeds decisions
- Presents 2–3 approaches with trade-offs, leading with a recommended option and reasoning
- Design delivery in 200–300 word sections with confirmation after each section (architecture, components, data)
- Design sections presented in 200–300 word chunks with check-ins after each
- Explores 2–3 implementation approaches with explicit trade-offs
Adoption & trust: 514 installs on skills.sh; 27.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to ask an agent to build or change something, but requirements, constraints, and success criteria are still fuzzy in chat.
Who is it for?
Solo builders starting features, refactors, or UX changes who want incremental design sign-off instead of a single giant spec dump.
Skip if: Work where an approved written spec or ticket already covers architecture, components, and acceptance criteria with no open design questions.
When should I use this skill?
You MUST use this before any creative work—creating features, building components, adding functionality, or modifying behavior.
What do I get? / Deliverables
You leave with a section-reviewed design covering architecture and components that you can approve before any implementation pass.
- Refined requirements and success criteria from dialogue
- Recommended approach among 2–3 options with trade-offs
- Section-reviewed design covering architecture, components, and data
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Clarify whether a calendar feature is iCal sync, embedded widget, or manual blocks before picking libraries.
Narrow MVP scope for onboarding with multiple-choice questions on success metrics and constraints.
Compare webhook versus polling approaches for a Stripe integration before writing handlers.
Align on rollout flags and user-visible behavior before a release branch.
Design an email drip change with sectional review before copy and code land together.
How it compares
Structured pre-implementation design ritual, not a code generator or a passive code-review checklist.
Common Questions / FAQ
Who is brainstorming for?
Solo and indie builders using Claude Code-style agents who want a mandatory pause to explore intent and design before creative implementation work.
When should I use brainstorming?
In Idea when framing a new capability, in Validate when scoping MVP boundaries, in Build before new components or behavior changes, in Ship when launch prep needs clarified acceptance criteria, and in Grow when funnels or flows need design before experiments.
Is brainstorming safe to install?
It is process-only dialogue; review the Security Audits panel on this Prism page before installing the template repo skill.
SKILL.md
READMESKILL.md - 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 - 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 - Break it into sections of 200-300 words - 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 ## 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:using-git-worktrees to create isolated workspace - Use superpowers:writing-plans to create detailed implementation plan ## Key Principles - **One question at a time** - Don't overwhelm with multiple questions - **Multiple choice preferred** - Easier to answer than open-ended when possible - **YAGNI ruthlessly** - Remove unnecessary features from all designs - **Explore alternatives** - Always propose 2-3 approaches before settling - **Incremental validation** - Present design in sections, validate each - **Be flexible** - Go back and clarify when something doesn't make sense