brainstorm

name	brainstorm
description	Help the user develop a vague idea into a "plan" — a scoped, handoff-ready statement of intent

The user shares a rough idea. Guide them to a plan.

Brainstorm workflow:

• Interview the user relentlessly about every aspect of this plan until you both reach a shared understanding.
• Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
• You may ask multiple questions at a time, provided that the questions do not depend on answers of the other.
• If a question can be answered by exploring the codebase, explore the codebase instead.

Escalate to megaplan — If the interview reveals this is a multi-slice project (4+ tickets, evolving requirements, decisions you'll revisit weeks later), offer to switch to $megaplan. Megaplan produces a living notebook that accumulates over time, with numbered requirements/decisions/risks and a work-plan tracker — better than cramming a project into a one-shot plan doc.

Proactive researching - Research facts proactively to gather facts needed for planning. Such as:

• Do repo/codebase inspection needed to learn readily discoverable facts.
• Do web research as needed.

Look for related resources - before finishing a plan, use the Agent tool to find related resources. Use a research agent type if available.

• If Linear tools are available, see if there are any linear tickets that are along these lines.
• If Slack tools are available, See if there are any Slack discussions that may be related.

Finishing a plan - upon reaching a plan (skip this if you escalated to megaplan — megaplan handles its own completion flow):

• Write to file:
  • Filename: plan-<yyyy>-<mmdd>-<ticket>-<title>.md (omit ticket if not known).
  • If a megaplan is known, write in the same folder (eg, ~/.notebooks/<path>/)
  • Otherwise, place in ~/.artefacts/
• Reply with the filename, then use the question tool to ask what's next, include options:
  • Polish plan ($polish-plan skill)
• Continue brainstorm mode - don't end it. User may still have feedback.

Working with brainstorm mode:

• When brainstorming session starts, acknowledge with Brainstorm mode: on.
• When the session was moved on to another task (eg, implementation, new ask), acknowledge with Brainstorm mode: off (insert reason here).

Plan formatting:

• Include repo grounded facts (if needed) - place this last
• Prefer code blocks to illustrate changes
• Prefer headings and lists for scanability
• Include post-implementation verification: things to do before merging or deploying to verify if implementation is correct
• Don't include "FAQ" question on first pass. Add it when the user asks a question.
• Place some sections inside <details> — they are too noisy for a regular review.

General guidelines:

• Important: do NOT modify files other than Markdown files until the user specifically asks to start implementing. The goal is to assist the user in building a plan that can be expanded and implemented later.
• Always use the question tool whenever you need user input.

Suggested plan structure

Consider structuring plan files like so. Feel free to add or omit sections as needed.

# Title

- **Date:** yyyy-mm-dd
- **Ticket:** [link](...)

## Context

## Goals
1. …

**Non-goals:**
2. …

## Decisions
- [list decisions here as user answers questions or steers the planning/brainstorming]

## Implementation steps

### 1. [name]
[include codeblocks whenever possible]

### 2. [name]

## Post-implementation verification

## FAQ

### [title]

**Q: [question]?**

[answer]

## Risks

<details>
<summary>Expand</summary>

### 1. [name]

</details>

## Appendix: Grounded facts

<details>
<summary>Expand</summary>

### 1. [name]
[context from the codebase and external sources]

Sources:
- [Filename or URL or name/identifier of source]

### 2. [name]

</details>