菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/bex-co/bex --skill pm-brainstorm命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| 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:*) |
/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.
.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.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..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.depends_on links./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./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./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.$ARGUMENTS
Inspect and maintain the repository's .pm workstreams, inbox notes, milestones, and tasks. Use when the user asks for PM board status or requests a supported board mutation such as creating, promoting, adding, or completing work.
Cut a versioned release of a bex component (today: cli) — compute/confirm the version, push the tag, watch the release workflow to green, and verify every distribution channel. Use when the user asks to release, publish, or bump the CLI (or a future component). /ship lands code; /release mints versions.
Autonomously work a `.pm` workstream to completion — pick the next pending milestone, implement every task end to end, /ship it, then move to the next until none remain. Use when the user asks to "loop", drain, or work through a whole workstream's backlog (e.g. `/loop-worker w1`). Sequential, not interval-based; for a timed poll use /loop.
基于 SOC 职业分类
