1. Get clear

/brainstorm

Talk the idea through, one question at a time.

Install this skill Read the skill and templates

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

Agent“Tell me about the idea: what do you want to build and why?”
Youtalk it through, out loud
Agent“Who is it for? What must v1 do, and what won’t it do?”
Youanswer one question at a time
Agent“So what I’m hearing is… Is that v1 or v2?”
Agent“Did I miss anything?”

brainstorm_<name>.md

Core: all a small task needs

What are you building?
MVP features
Verification: Success and Proof

Optional: only what you already know

Future features / ideas
Out of scope
Design and style
Tech stack
Other engineering requirements
Existing context
What agents should ask you
Open questions and next step

1 Open
“Tell me about the idea: what do you want to build and why?”
2 One question per turn
Who it’s for, v1 must and won’t, how you’ll know it works, constraints, what exists, what to check with you.
3 Reflect back
Every few turns: “So what I’m hearing is…” Scope growing? “Is that v1 or v2?”
4 Stop when clear
Goal, v1 scope and success are clear. Loose ends become open questions.
5 Read it back
Spoken summary, then “did I miss anything?”
6 Write the doc
brainstorm_<name>.md, then one next step.

What you get

brainstorm_<name>.md: the full template for a project or large feature, or a task brief with only the core sections for a small feature or task.

Next step

When it’s done, /brainstorm recommends one of these:

Build it now · small and clear enough for one session
/create-spec · real product or engineering decisions
Stop here · the doc alone is a complete outcome

Install /brainstorm

One prompt installs just this skill and its template. Want the whole system? Install all five from the Planning System page.

Then paste it into a conversation with your agent.

Works with

Claude Code
Codex
Grok Bot

Download brainstorm.zip Unzip into your agent’s skills folder.

Read the installation prompt

Install the brainstorm skill from this manifest for use in the agent I am using now:
https://ainativebuilder.com/plan/resources/brainstorm/manifest.json

Identify this agent and use its supported personal/global skill installation or saved-skill mechanism, so the skill is reusable beyond the current project or conversation. If the correct mechanism is unclear, check this agent's official instructions before proceeding.

Fetch the manifest and download every listed file from the same origin. Preserve the exact contents and relative references of all 2 Markdown files, keeping each skill in its own folder named after the skill. Stage the complete bundle and verify its SHA-256 hashes before installation. If a download or hash check fails, stop and report it without changing existing skills. Back up any existing same-name skills before replacing them; keep filesystem backups outside skill-discovery directories. Install independent copies, not symlinks.

Verify that the skill is saved and discoverable and that every referenced template is accessible. If this host cannot preserve the complete bundle, explain the limitation instead of claiming successful installation. Report any enablement or refresh step still needed.

Confirm what was installed and where, then stop. Do not invoke the skill, start an interview, plan a project, or implement anything.

Install all five skills instead

Full instructions & templates

Read each complete file below. Copy or download the original Markdown to use with your agent.

Brainstorm skill

brainstorm/SKILL.md

Select and copy the complete source below.

---
name: brainstorm
description: Voice-friendly interview that turns a new project, feature, or task idea into a brainstorm doc or task brief, then recommends the next step (build it now or spec it first). Use when the user says "brainstorm", "I have an idea", or wants to talk an idea through before building it.
---

# 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

1. **Open:** "Tell me about the idea — what do you want to build and why?" Skip this if they already explained it.
2. **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). If they may want you to build it, ask what you should check with them about first.
3. **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?"
4. **Stop interviewing when the goal, v1 scope, and success criteria are clear.** Record unresolved technical choices and unchecked assumptions as open questions rather than prolonging the interview.

## Output

Write `brainstorm_<name>.md`, picking the contents by size:

- **Project or large feature** → a brainstorm doc using [references/brainstorm-template.md](references/brainstorm-template.md).
- **Small feature or task** → a task brief: only the template's core sections.

Save it where the user says. Otherwise use the project's existing planning folder (`plans/`, `specs/`, or `docs/specs/`), or create `plans/` at the project root. Don't overwrite an existing brainstorm; choose a distinct name.

Before saving, read back a short spoken-style summary, ask "did I miss anything?", and recommend the next step. Fold in their reply.

## Next Step

Recommend one next step by size, and continue only when the user says so or asked for it up front:

- **Small and clear enough to build in one session** → offer to build it now.
- **Real product or engineering decisions** (a data model, a stack, several user flows, or other people who need to review it) → recommend writing a spec first, with `create-spec` if available.

Stopping at the doc is a complete outcome.

If you build, keep going until success is verified against the artifact's success criteria. 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

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). If they may want you to build it, ask what you should check with them about first.
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 and unchecked assumptions as open questions rather than prolonging the interview.

Output

Write brainstorm_<name>.md, picking the contents by size:

Project or large feature → a brainstorm doc using references/brainstorm-template.md.
Small feature or task → a task brief: only the template’s core sections.

Save it where the user says. Otherwise use the project’s existing planning folder (plans/, specs/, or docs/specs/), or create plans/ at the project root. Don’t overwrite an existing brainstorm; choose a distinct name.

Before saving, read back a short spoken-style summary, ask “did I miss anything?”, and recommend the next step. Fold in their reply.

Next Step

Recommend one next step by size, and continue only when the user says so or asked for it up front:

Small and clear enough to build in one session → offer to build it now.
Real product or engineering decisions (a data model, a stack, several user flows, or other people who need to review it) → recommend writing a spec first, with create-spec if available.

Stopping at the doc is a complete outcome.

If you build, keep going until success is verified against the artifact’s success criteria. 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

brainstorm/references/brainstorm-template.md

Select and copy the complete source below.

# Brainstorm: [Name]

**Date:** [YYYY-MM-DD]

**How to use this:**
Use this at the start of a project, feature, or task.
You can fill it out on your own or have your agent interview you.

Fill in the three core sections first; for a small task, they're all you need. Add optional sections only when you already know the answer, and leave gaps as open questions.

---

## Core

### 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
_The minimum it must do to be useful the first time._

- [Must-have feature]
- [Must-have feature]

### Verification: Success and Proof
_How will you know the first version works? Pro-tip: Describe something you can see or check, not "it works."_

- **Success looks like:** [What the user can accomplish]
- **How to verify:** [A concrete demo, test, metric, or review]

---

## Optional Questions

### Future Features / Ideas (for v2, v3 etc)
_Things you might want later, but not in the first version._

- [Future idea]

### Out of Scope
_What you're explicitly not building this time._

- [Explicit exclusion]

### Design & Style
_Apps you want it to look or feel like, with links and what you like about them._

- [Reference or preference]

### Tech Stack
_Preferences or tools you already use. Write "undecided" for anything you'd like recommended._

- Language:
- Framework:
- Database:
- Hosting:
- Auth:
- Already set up: [Accounts, services, or integrations]

### Other Engineering Requirements
_Architecture constraints, integrations, privacy needs, deadlines, or budget limits you already know about._

- [Constraint or requirement]

### Existing Context
_Code, docs, assets, prior attempts, or research worth reading or reusing._

- [Path or link + why it matters]

### What Agents Should Ask You
_When your agent builds this, what should it check with you about?_

- **Check with me first:** [e.g., new paid services, anything public-facing, deleting data]

### Open Questions and Next Step
_Anything still unresolved, and what should happen once this brainstorm is done._

- **Open questions:** [Unresolved questions or assumptions to check, or "None"]
- **Next step:** [Write a spec / Build it now / Stop here / Or custom stopping point eg) "Research the API options, then discuss with me"]

Show the brainstorm document template

Brainstorm: [Name]

Date: [YYYY-MM-DD]

How to use this: Use this at the start of a project, feature, or task. You can fill it out on your own or have your agent interview you.

Fill in the three core sections first; for a small task, they’re all you need. Add optional sections only when you already know the answer, and leave gaps as open questions.

Core

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

The minimum it must do to be useful the first time.

[Must-have feature]
[Must-have feature]

Verification: Success and Proof

How will you know the first version works? Pro-tip: Describe something you can see or check, not “it works.”

Success looks like: [What the user can accomplish]
How to verify: [A concrete demo, test, metric, or review]

Optional Questions

Future Features / Ideas (for v2, v3 etc)

Things you might want later, but not in the first version.

[Future idea]

Out of Scope

What you’re explicitly not building this time.

[Explicit exclusion]

Design & Style

Apps you want it to look or feel like, with links and what you like about them.

[Reference or preference]

Tech Stack

Preferences or tools you already use. Write “undecided” for anything you’d like recommended.

Language:
Framework:
Database:
Hosting:
Auth:
Already set up: [Accounts, services, or integrations]

Other Engineering Requirements

Architecture constraints, integrations, privacy needs, deadlines, or budget limits you already know about.

[Constraint or requirement]

Existing Context

Code, docs, assets, prior attempts, or research worth reading or reusing.

[Path or link + why it matters]

What Agents Should Ask You

When your agent builds this, what should it check with you about?

Check with me first: [e.g., new paid services, anything public-facing, deleting data]

Open Questions and Next Step

Anything still unresolved, and what should happen once this brainstorm is done.

Open questions: [Unresolved questions or assumptions to check, or “None”]
Next step: [Write a spec / Build it now / Stop here / Or custom stopping point eg) “Research the API options, then discuss with me”]