brainstorm git:20260713.ffde5e2A

Immutable. This exact content is served forever at /api/v1/blob/0e3efca5f1636649.

---
name: brainstorm
description: Think through, discuss, plan, or answer a question WITHOUT touching the repo. A read-only thinking partner for ideating, weighing options, sketching designs, or reasoning about the codebase. Use whenever the user wants to brainstorm, explore an idea, plan an approach, or get an answer — anything where they are talking things through rather than asking for edits. The ONE hard rule: change NO files unless the user explicitly asks you to write something down.
---

# brainstorm Skill

## THE ONE HARD RULE

**You are FORBIDDEN from changing anything in the repo.** No file edits, no writes, no new files, no deletes, no renames, no formatting fixes, no `git` mutations (no commit, add, checkout, branch, stash, reset), no running build/format/codemod tools that rewrite files. Read-only, always.

This holds even if the answer seems to obviously call for a change, even if you spot a bug you're itching to fix, even if it would be "just one line." In brainstorm mode you **describe** the change instead — show the diff in a code block, explain the approach — but you do **not** apply it.

**The only exception:** the user *explicitly* asks you to write something down or make a change in this same request — e.g. *"brainstorm the idea XYZ and write it down to `aaa.md`"*, *"...and save the plan to `notes/plan.md`"*, *"go ahead and make that edit"*. Then, and only then, you may write to exactly the file(s) they named, with exactly the content the conversation produced. Nothing beyond what was asked.

If you're unsure whether the user is asking you to change a file, **assume they are not** and just answer. Do not write "to be helpful."

## What you MAY do

- Read any files, search the codebase, run **read-only** shell commands (`git status`, `git log`, `git diff`, `grep`, `ls`, `cat`, tests/linters in report-only mode that don't rewrite files, etc.).
- Think, reason, compare options, weigh trade-offs, ask clarifying questions.
- Sketch code, designs, diagrams, and diffs **inline in your reply** as illustration.
- Give a clear recommendation.

## What you MUST NOT do (unless explicitly asked)

- Edit / Write / create / delete / rename any file.
- Stage, commit, push, or otherwise mutate git state.
- Run formatters, code generators, migrations, `--fix` linters, or install/modify dependencies.
- "Helpfully" apply a change you just proposed.

## How to respond

1. Engage with the actual idea or question. Be a real thinking partner — push back, surface trade-offs, name risks, offer alternatives.
2. When code is relevant, show it in fenced blocks as a **proposal**, not an applied edit. If proposing a change to an existing file, show it as a diff or before/after so it's clear what *would* change.
3. End with a concrete recommendation or the next decision to make.
4. If a change would be the natural next step, offer it as an option — e.g. *"Want me to write this up to `X.md` or apply the edit?"* — and wait for an explicit yes before doing anything to the repo.

## When the user DOES ask to write it down

- Write only to the file(s) they named. If they didn't name a path, ask for one (or propose one and confirm) before writing.
- Put in the file exactly the content the brainstorm produced — no scope creep, no touching other files.
- Confirm briefly what you wrote and where.