Brainstorm
Turn a rough idea into a clear direction.
View skill & templatesUse Avthar's Skills and templates in your next project
Use the /brainstorm and /create-spec skill to plan your next AI coding project
Then paste it into a conversation with your agent.
Install both skills for your personal Claude Code projects.
The prompt installs and confirms. It won’t start a planning session.
Read the installation prompt
When to use it
- You have a project idea and want to talk it through before building.
- A feature keeps growing and you need to decide what belongs in the first version.
- You know the problem, but need a clearer picture of a useful result.
How it works
Describe the idea
Explain what you want to build and why. Share any existing notes, code, or examples; a rough starting point is enough.
Answer one question at a time
Your agent asks conversational questions, reflects back what it understands, and helps separate the first version from later possibilities. You can talk or type.
Capture a useful brief
Once the goal, scope, and success criteria are clear, your agent summarizes and saves them. Decisions, assumptions, and unresolved questions stay distinct.
What you get
A brainstorm document for a project or large feature, or a short task brief for smaller work. Both capture the goal, scope, and observable success criteria.
You’re ready to move on when…
- The intended user and the problem are clear.
- The first version is distinct from future ideas and out-of-scope work.
- Success describes something you can observe and check.
Full instructions & templates
Read each complete file below. Copy or download the original Markdown to use with your agent.
Brainstorm skill
SKILL.md
Brainstorm
Interview the user about a new project, feature, or task, then turn the conversation into an actionable artifact. Voice-compatible: ask one open-ended question at a time in plain conversational prose — no structured question tools, option lists, or bullet walls the user would have to read.
How to Interview
- Open: “Tell me about the idea — what do you want to build and why?” Skip this if they already explained it.
- One question per turn. Cover, in whatever order the conversation flows: who it’s for and the problem it solves, what the v1 must do (and explicitly won’t), how they’ll know it works, technical constraints or stack preferences, and anything already existing (code, docs, prior attempts).
- Reflect back every few turns: “So what I’m hearing is…” — let them correct you. Push back gently when scope balloons: “Is that v1 or v2?”
- Stop interviewing when the goal, v1 scope, and success criteria are clear. Record unresolved technical choices as open questions rather than prolonging the interview. Distinguish user decisions from assumptions.
Output
Pick the artifact by size:
- Project or large feature → draft a brainstorm doc using references/brainstorm-template.md.
- Small feature or task → write a task brief: goal, requirements, acceptance criteria, out of scope, and any user-specified stopping point.
Read back a 3–4 sentence summary and ask “did I miss anything?”, then save to the path they gave or a descriptively named file in the project’s usual docs/specs location.
Continue to the Outcome
Default next step: Build the MVP/v1 and keep working until success is verified against the artifact’s success criteria. Create a spec or do focused research as needed to support the build; use create-spec or research if available.
The user can override this default with a different next step or stopping point, such as “brainstorm only”, “only create the spec”, or “research the options, then discuss with me”. Respect that boundary.
Resolve open questions by making a call when there is enough context and the decision falls within the agent’s autonomy boundary, researching factual unknowns, or asking the user when their input is needed. Record the resolution and settle blocking questions before dependent implementation. Follow repository instructions and tool permissions; if verification is blocked, explain what remains unverified and what is needed to continue.
Guidelines
- Conversational and short — your turns should be shorter than the user’s.
- Capture their words; don’t translate everything into jargon.
- One idea per session. If a second idea emerges, note it and offer a separate round.
Any text supplied with the invocation is starting context.
Brainstorm document template
references/brainstorm-template.md
Brainstorm: [Project Name]
Use this at the start of a project or substantial feature. Fill it out directly or through an interview with an agent. Keep it lightweight: capture what you know, mark assumptions, and leave unresolved decisions as open questions. Omit sections that don’t apply.
What are you building?
One or two sentences: what is it, who is it for, what problem does it solve, and why are you building it?
Project type: [customer-facing product / personal project / internal tool / MVP / learning project / other]
MVP Features
What are the absolute minimum features needed for a useful first version?
- [Must-have feature]
- [Must-have feature]
Future Ideas (v2, v3)
Features you might want later, but NOT in the first version. These are possibilities, not commitments.
- [Future idea]
Out of Scope
What are you explicitly NOT building as part of this project or feature?
- [Explicit exclusion]
Success and Proof
What would make this first version successful, and how will you check? Use an observable result rather than “it works.”
- Success looks like: [What the user can accomplish]
- How to verify: [A concrete demo, test, metric, or review]
Design & Style
Any apps you want it to look or feel like? Include links and explain what you like about them. Note any accessibility or usability needs you already know.
- [Reference or preference]
Tech Stack
Optional: list preferences or existing tools. Write “Agent to recommend” if undecided. You don’t need to choose a stack to finish the brainstorm; create-spec and focused research can resolve it.
- Language: [Preference / undecided]
- Framework: [Preference / undecided]
- Database: [Preference / not needed / undecided]
- Hosting: [Preference / undecided]
- Auth: [Preference / not needed / undecided]
- Already set up: [Accounts, services, or integrations — never paste secret keys]
Other Engineering Requirements
Any architecture constraints, deployment preferences, integrations, privacy needs, or technical considerations already known? Include relevant deadlines or budget limits.
- [Constraint or requirement]
Existing Context
What should the agent read or reuse? Link relevant code, docs, assets, prior attempts, or research.
- [Path or link + why it matters]
Decisions and Assumptions
Separate choices you’ve made from beliefs that still need checking. Keep this short; don’t repeat every requirement.
- Decided: [Choice and brief reason]
- Assumption to validate: [Assumption and how it could affect the plan]
Agent Autonomy Boundary
What can the agent decide on your behalf, and what should it bring back to you? These preferences remain subject to repository instructions and tool permissions.
Default: Keep working until success is verified.
- Agent can decide: [Decisions it may make independently]
- Discuss with me first: [Decisions requiring your input]
Open Questions and Next Step
Optional: capture anything still unresolved. The agent should make a call when it has enough context and the decision falls within its autonomy boundary, research factual unknowns, or ask the user when their input is needed. Record the resolution so it carries through into implementation.
- Open questions: [Unresolved questions, or “None”]
Default next step: Build the MVP/v1 and keep working until success is verified against the Success and Proof section. Resolve blocking questions first; create a spec or do focused research as needed to support the build.
User override (optional): [A different next step or stopping point, such as “Only create the spec” or “Research the API options, then discuss with me”]