brainstorm

/deep-researcher:brainstorm — Explore Before You Research

Trigger

Invoked with /deep-researcher:brainstorm followed by a topic, idea, or open-ended question.

/deep-researcher:brainstorm <topic-or-idea>

Purpose

A lightweight, conversational exploration that happens before /deep-researcher:deep-research. Use this when you have a topic in mind but aren't sure how to scope it, which dimensions matter, or whether research is even the right next step. Brainstorm helps clarify intent, surface hidden assumptions, and narrow the scope before investing in a full research run.

Produces a Research Brief at the end — a structured block that maps directly to /deep-researcher:deep-research Phase 1 inputs so the orientation dialog can be skipped or pre-filled.

Workflow

1. Ground in Context (conditional)

If the topic involves the current project's codebase (integration research, architecture decisions, understanding an existing system), do a quick read of the project's stack and conventions to ground the conversation in reality. Check for package.json, README.md, or a manifest file at the working directory root.

Skip this step entirely for external topics (market research, technology landscape, competitive analysis) — reading the codebase adds no value.

2. Probe the Topic

Ask questions to understand intent — one question at a time:

• What are you trying to decide or learn?
• Who will use or act on these findings?
• What constraints exist — timeline, technology, audience depth?
• What do you already know or believe about this? What would change your mind?
• Is there a specific action or output this research should feed into?

Do not ask all questions at once. Ask one, wait for the answer, then ask the next. Let the user's answers steer the direction. Stop probing when the intent is clear enough to propose scope.

3. Explore Scope Framings

Once intent is clear, propose 2-3 distinct ways to frame the research scope:

• For each framing: one paragraph describing the angle, what it would illuminate, and where it falls short.
• Recommend one with a clear reason why.
• Explicitly state what each framing sacrifices — no framing captures everything.

4. Refine

Based on user feedback, narrow down or combine framings. Iterate until the user is satisfied with the direction. This is a conversation, not a presentation.

5. Conclude — Research Brief

When the user is ready to proceed, produce a Research Brief summary followed by a structured handoff block:

---

Problem / goal: one sentence.

Chosen scope: one paragraph — what this research will and will not cover.

Key trade-offs accepted: bullet list of what the chosen scope sacrifices.

Open questions: anything that should be addressed as a dedicated dimension in the research run.

Then the handoff block, formatted as a fenced code block the user can pass directly to /deep-researcher:deep-research:

Research Brief (for /deep-researcher:deep-research)

topic:        "<the research topic>"
scope:        "<what is in scope>"
out_of_scope: "<what is explicitly excluded>"
audience:     "<technical experts | executives | general audience>"
depth:        quick | standard | deep
time_range:   "<e.g. last 2 years | all time | 2020-present>"
notes:        "<any additional context for the researcher>"

Close with: "Run /deep-researcher:deep-research \"<topic>\" — Phase 1 will be fast since the brief is ready."

Optionally save the full brainstorm summary to ${CLAUDE_PLUGIN_DATA}/brainstorms/<ISO_DATE>-<slug>.md if the user wants to preserve it.

Constraints

• One question per message. Do not front-load a list of questions.
• Always propose at least 2 scope framings. Never present a single framing as the only option.
• YAGNI. Do not propose dimensions or angles that solve problems the user hasn't described.
• Do not write research, create tickets, or produce reports. This skill is for scoping only.
• If the scope is already clear, say so and go straight to the Research Brief — skip the probing steps.
• Ground codebase proposals in what exists. Do not recommend technologies or patterns that conflict with established conventions without explicitly calling out the deviation.

Related Skills

• /deep-researcher:deep-research — run after brainstorm when the research brief is ready.
• /deep-researcher:deep-research-visualize — generate an HTML report from the research output.