Pm Brainstorm

---
name: pm-brainstorm
description: >-
  Analyze and decompose a product topic into a text-only proposal for the repository's .pm board. Use when the user wants to pressure-test scope, size milestones, identify dependencies, or prepare exact PM board commands without writing board files.

allowed-tools: Read, Bash(ls:*), Bash(find:*), Bash(cat:*), Bash(git fetch:*), Bash(git pull:*), Bash(git status:*)
---

# Task: Propose milestones and tasks

`/pm-brainstorm` is the **divergent** half of the pair: it thinks a topic through, **proposes** work, and hands orchestration and materialization to `/pm`. It writes **nothing** — the output is a text proposal. `$ARGUMENTS` is the topic/goal.

The board conventions — hierarchy, sizing rule, milestone quality gate, standing closing tasks, templates — live **canonically** in [`.claude/skills/pm/SKILL.md`](../pm/SKILL.md). Read that file and apply its rules; do not restate or diverge from them here.

## Steps

1. **Load the canon and the anti-goals.** Read `.claude/skills/pm/SKILL.md` (conventions), `.pm/DO_NOT_DO.md` (hard constraint), and the repository `AGENTS.md` (keep-it-simple, no speculative defenses, public CLI surface discipline). If a proposed item conflicts with an anti-goal, reject it explicitly and explain why.
2. **Sync with remote main.** Before analyzing anything, run `git fetch origin main` then `git status` to check whether the local branch is behind. If it is and the working tree is clean, `git pull` (fast-forward) so the `.pm` board state you read next reflects the latest remote. If the working tree is dirty or the branch has diverged, report this to the user and ask how to proceed rather than pulling over local work.
3. **Load context.** Read the relevant `.pm` board state (workstream `README.md`s, open milestones, inbox notes — `find .pm -name README.md`, plus loose notes) so proposals fit the existing roadmap and reuse its numbering/naming. Choose any existing `wN` using available capacity, dependency locality, and collision avoidance; every worker is general-purpose, and prior milestone topics do not create a specialty or ownership claim. Propose a new `wN` only when more independent queue capacity is useful. Also check `wN/done/` and any nested `done/` folders (`find .pm -type d -name done`) for milestones that already shipped the same capability — read their titles/READMEs before proposing, and drop or reshape any candidate that duplicates completed work instead of proposing it fresh.
4. **Discuss & decompose.** Talk the topic through with the user: pressure-test scope, surface dependencies and risks, and break it into candidate tasks, each with a rough estimate and `depends_on` links.
5. **Size and gate** each cluster of work using `/pm`'s sizing rule and milestone quality gate. Undersized work → propose an inbox note instead of a milestone, and say so. Work that fails the quality gate → mark it **not meaningful**, do not propose it as a milestone, and suggest a better-scoped alternative.
6. **Emit the proposal as text only.** Give the full detail first: the target workstream, each proposed milestone (task table + definition of done + source + goal linkage + expected outcome + why-now rationale) and/or inbox note, numbered in proposed priority order. Propose **implementation tasks only**: `/pm` appends the standing closing tasks (Surface parity when the milestone is feature dev/a fix touching the public CLI/SDK surface, then Simplify, then Test coverage, then Closeout) itself when it materializes, so do not include them — but do flag in the proposal whether you expect Surface parity to apply, so `/pm` and the user aren't guessing. Close with a **"Summary (priority order)"** section: a numbered list of every candidate (milestones and inbox notes together) using the same numbers as above — one line each: `N. <title> (wN, ~size) — one-line outcome` — so the user can scan and pick by number without rereading the detail. Do **not** write files.
7. **Hand off to `/pm`.** End by giving the exact `/pm` command(s) to materialize the proposal, e.g.:
   - `/pm new milestone w1 <title>` (then the tasks), or
   - `/pm add w1 <idea>` for sub-hour work, or
   - `/pm promote w1/NNN` to promote an existing inbox note.

## Topic

$ARGUMENTS