bex: Skill for Claude Code

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. Read that file and apply its rules; do not restate or diverge from them here.

Proposal count

Propose five distinct, meaningful items per run unless the user explicitly requests a different count. An item is a milestone or an inbox note, not an implementation task or a standing closing task. Each item must have concrete evidence, project-goal linkage, an observable outcome, and a why-now rationale.

Do not stop after restating the target workstream's existing inbox. Research enough candidates to select five that survive the anti-goal, deduplication, and quality gates. For a workstream-only request such as w4, look across the project for work that can be scheduled there; for a specific topic, stay within that topic. Existing board work may be reused or reshaped with explicit references, but must not be presented as a new discovery or filed twice.

Do not pad the count by splitting one outcome into artificial items, inflating sub-hour fixes into milestones, inventing gaps, or reopening deferred decisions. If substantive research still yields fewer than five eligible items, explain the specific evidence or scope constraints and the candidates rejected; never count rejected or speculative filler as meaningful proposals.

Steps

1. Load the canon and the anti-goals. Read .claude/skills/pm/SKILL.md (conventions) and .pm/DO_NOT_DO.md (hard constraint). If a proposed item conflicts with an anti-goal, reject it explicitly and explain why.
2. Sync autonomously and keep going. Run git fetch origin main and git status. On local main, run git pull --ff-only origin main when behind; a dirty tree or untracked files alone are not a reason to stop — Git will refuse a fast-forward that would overwrite them. Preserve local work: do not reset, clean, stash, commit, or rebase to make brainstorming possible. If the pull is refused, the branch has diverged, or another branch is checked out, read the latest fetched origin/main board and source with git show origin/main:<path> and git ls-tree, comparing relevant local changes with git diff as needed. If fetching fails, use the available checkout and state that freshness could not be verified. Resolve routine issues yourself, briefly report the source revision and any fallback, and always continue to the proposal without asking the user how to proceed.
3. Load context. Read the relevant .pm board state (workstream README.mds, 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. For any Render-parity topic, also read docs/ADR018-render-parity.md — the parity ledger already maps each REST/GraphQL/MCP/UI gap to ✅/◐/✖/— and to an owning milestone/inbox note; reuse its assessment and cross-references (don't re-derive them), cite the matrix row a proposal closes, and don't propose work for a cell it marks — (deliberate non-goal) without re-opening that decision.
4. Analyze & decompose without pausing. Infer scope from the request and current board, pressure-test it, surface dependencies and risks, and break it into candidate tasks, each with a rough estimate and depends_on links. State reasonable assumptions in the proposal instead of asking clarifying questions. Where a product decision is unresolved, recommend an option or give conditional alternatives; do not treat brainstorming as authorization to implement them. Always deliver the text proposal in the same run.
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 (Render parity when the milestone is feature dev/a fix touching REST/GraphQL/MCP/UI, 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 Render 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.