需要把产品想法变成 docs/scope…

一句话适用场景：把产品想法或下一个 slice 整理成 docs/scope/ 中粗粒度、持续更新、可随交付对账的功能范围计划。

适用场景

解决思路

1. 用 `/scope [what]` 单命令，不用子命令，按上下文推断意图。
2. 输出统一用简单平实语言，用 `you` 称呼读者，像同事一样温暖直接。
3. 每个步骤都写成建议，读者可运行或跳过，不要命令式。
4. 保留有实际意义的技术术语，并用平实的话解释。
5. 不要用破折号或连字符作标点，不用 em dash、en dash、连字符复合词；写 `read only` 不写 `read-only`；代码、文件路径、命令 flag、其他 skill 匹配的值保留连字符。
6. 用短句、逗号或括号，清晰优先于聪明。
7. 把想法转成有序、粗粒度、持续更新的计划，放在 `docs/scope/`，并随产品交付保持真实。
8. 只回答做什么、按什么顺序、多重、哪些需要先决策，不回答如何构建单个功能，后者交给 `/architect` 和 `/develop`。
9. 范围保持粗而小：一个精简 At a glance 表 `# · Feature · Phase · Status`，加按 phase 分组的 feature 段落，参考 `scope-template.md`。
10. 每个 feature 段落格式：标题 `### N. Name`，只在重要时加短标签，如 `needs a decision`、approach override、workflow tier override 如 `· GA`；1 到 2 行 intent；一行 `Done when:`；checkbox 步骤。
11. feature 生命周期：未设计时只放一个 box，写入口命令。
12. 捕获 spec 后，由 `/architect` 填入 built ready 形状：勾选 `Design it (spec)`，链接 spec，`Build it: /develop <feature>` 带 2 到 5 个从 spec `## Build plan` 汇总的 milestone 子项，然后 `Verify it: /check verify <feature>` 和 `Test it: /test <feature>`。
13. 原子构建任务留在 spec 的 `## Build plan`，不放进 scope；scope 中每个 box 要么是命令，要么是可跟踪 milestone。
14. Status 同时写在 At a glance 表和标题旁；一旦存在就写 spec 和代码指针。
15. plan 默认行为：无 scope 且有产品规模想法，或要求规划下一个 slice；完整流程：询问、分解成粗 feature 段落、排序并分 phase、写入。
16. replan 行为：scope 已存在且无参数；先简短读出现状，包括 git branch 与 remote ahead/behind、按状态统计 feature 数、每个 in-progress feature 的 resume point，让裸 `/scope` 兼作“我在哪、安全接什么”的定位。
17. replan 随后核对已交付内容，暴露 plan 与现实的漂移（有代码或 spec 但没有 scope 行），登记构建中浮现的需求，重新排序，并排队下一个 slice；这是常规节奏，可反复运行裸 `/scope`。
18. add 行为：scope 已存在且参数命名单个 feature；只登记一行粗粒度条目（intent、order、tier、Needs spec），不重新规划：`/scope <a feature>`。
19. 像资深产品工程师一样工作，遵循 infer/ask/recommend 纪律。
20. INFER 想法中已声明的信息，如 category 和 obvious capabilities。
21. ASK 无法推断的商业、产品、go to market 信息，分批提问，每轮最多 4 个问题，见 Decision panels。
22. RECOMMEND 构建方法、构建顺序、workflow tier（项目默认与每 feature override）、哪些需要 spec；专家判断要展示出来，让工程师 override。
23. 绝不在 scope 中选择工具：不选或命名 provider、library、ORM、host、BaaS；那是 `/architect` 在每个 feature 的 spec 中的职责。
24. 一个 feature 暗示了工具选择时，就标 `Needs spec: yes`；保持 scope 工具无关，避免腐烂。
25. 每个用户可见选择都用 options panel，不用中性菜单：2 到 4 个对当前产品真实的具体选项；恰好一个标 `(recommended)` 并给一行理由；做决定，但允许 override。
26. 不要自己加 Other 选项，picker 会自动追加 free text Other；只有在没有 picker 的纯文本 fallback 中才自己提供 free text。
27. Capability first：优先用 agent 的 picker，在 Claude Code 上是 `AskUserQuestion`；否则用纯文本给出同样选项；分批轮次同样规则，每轮最多 4 个。
28. `docs/scope/` 是 feature scope，由本 skill 拥有；`/architect` 拥有 `docs/specs/`。
29. 其他 skill 通过扫描 `docs/scope/` 找 feature 行。
30. 作为 living document：`plan`、`replan`、`add` 都原地编辑，做 reconcile 和 append，绝不新建带日期的文件。
31. 不写其他东西：不写 spec、代码或 `AGENTS.md`。
32. `docs/scope/` 只放 scope 文件；inventories、analyses、research docs 与 spec 一起放在其 `rationale.md`，由 `/architect` 拥有。
33. 小产品：一个文件 `docs/scope/scope.md`，包含 At a glance 表、按 phase 分组段落、legend。
34. 大产品：epic 拆分：`docs/scope/index.md` 包含跨 epic 的 At a glance 表和每个 epic 一行状态汇总，各自链接 epic 文件；每个 epic 一个按 area 命名的文件，如 `docs/scope/auth.md`。
35. 按需提升：先单文件；当 `scope.md` 超出舒适浏览范围（大约十几个以上 feature 横跨明显不同 area），重命名为 `index.md`（保留表与 per epic rollup），把每个 area 段落移入自己的 `<epic>.md`；绝不提前拆分。
36. 文件名用语义名 `scope.md` / `index.md` / `<epic>.md`，绝不用编号。
37. 每个文件保持粗而小；长 epic 文件需要更细的 feature 和更紧的 intent，而不是构建任务堆。
38. Status lifecycle：`/scope` 设初始状态，pipeline 推进。
39. 新 feature 从 `planned` 开始。
40. Brownfield：也登记已存在的 feature 为 `existing`（complete）或 `in-progress`（partial），这是 `/scope` 写的仅有的其他状态。
41. `/develop` 推进 pipeline 构建工作 `planned` → `in-progress` → `done`；`/sync` 对照 diff 做 reconcile。
42. 基于 assumed decision 构建的 feature（其治理 spec 为 `Assumed`，由 `/develop` 在工程师选择先构建后决策时记录）带 `assumed decision (spec NNNN)` 注记，直到 `/architect` 批准该决策；该注记不阻塞 `done`，属于 decision debt，保持可见直到批准。
43. `done` ≠ `existing`：`done` 表示本 pipeline 已构建并验证；`existing` 早于 workflow；`/develop` 和 `/sync` 绝不碰 `existing` 行。
44. `replan` 可把从 scope 中移除的 feature 设为 `dropped`，绝不删除行；`dropped` 保留历史，从 active counts 和工作排除；`/develop` 和 `/sync` 跳过它。
45. Workflow tier：每个 feature 一个 rigor dial，`Prototype` · `Alpha` · `Beta` · `GA`，表示功能需要多少流程。
46. 一个项目默认值，在 plan Step 5b 推荐一次，记录在 scope header 的 `**Workflow:**` 行；每 feature override 用标题旁标签，如 `· GA`，只在 feature 与默认不同时加；无标签即继承。
47. Tier 驱动设计时间：更高 tier 更可能 `Needs spec: yes`，且 spec 的 cross model decision critic 运行（`GA`/`Beta` 自动）；`Prototype`/`Alpha` 常为 `Needs spec: no`。
48. Tier 驱动 `/develop` 后的 verification tail：`Prototype` 无（依赖 `/develop` 自身 build time self check）；`Alpha` = `/check verify`；`Beta` = `/check verify` + `/test`；`GA` = 加 fresh model `/check review` + `/document`。
49. Tier 驱动什么关闭 `done`（最后必需阶段标记）：`Prototype` → `/develop`（build + self check）；`Alpha` → `/check verify`；`Beta`/`GA` → `/test`。`Assumed` spec 在任何 tier 都不阻塞 `done`，但保持标记需要 `/architect` 批准。
50. `/scope` 根据 feature mix 的 risk 和 size 推荐项目默认 tier（Step 5b），与 `/architect` 和 `/develop` 读同样信号。
51. `/develop` 读取 effective tier（feature override，否则项目默认，否则推断）来缩放它推荐的下一步，避免 `Prototype` 项目被要求运行 verify，`Alpha` 项目被要求跑完整 review chain。
52. Artifact base：默认 `docs/`；如果 `docs/` 是已发布 docs site（检测到 `docusaurus.config.*`、`.vitepress/`、`mkdocs.yml`、Astro Starlight 或 Nextra），使用 `.workflow/`，即 `.workflow/scope/…`。始终跟随已存在的 base，本文路径假设 `docs/`。
53. Concurrency：跨 session 和 teammate 共享。写前立刻重新读取；只做 surgical edits，按顺序追加行，reconcile 变更单元格，绝不重写文件；遇到意外状态要 flag 而不是 clobber；用下一个空闲编号追加，避免 adder 冲突。
54. 读 `scope-template.md`：格式规则、At a glance 表、per feature 段落（heading + intent + Done when + checkbox tasks + pointer line）、brownfield enrollment 和 epic split 形状、`## /scope complete` 报告块；写 scope 和报告时读它。
55. Portability：macOS、Linux、Windows 上任何 Agent Skills client 可用；检测片段是 POSIX reference，使用 agent 的跨平台文件工具。
56. Planning 内联运行；两个 subagents（Step 1 brownfield code scan、Step 6b sourcing）可选，capability first，可降级为内联。
57. 没有交互 picker 时，每个 panel 都用纯文本问，选项相同。
58. Step 0 推断意图与 idea 检查：无子命令。先检查 `docs/scope/` 下是否存在 scope（若 artifact base 是 `.workflow/` 则检查 `.workflow/scope/`），然后推断。
59. 若 scope 存在且无参数，或再次运行描述为 reconcile / what's next → replan 行为，读 `modes/replan.md`。
60. 若 scope 存在且参数命名单个 feature → add 行为，读 `modes/add.md`。
61. 若尚无 scope 且有产品规模想法，或规划下一个 slice（包括 brownfield）→ plan 行为。
62. 若模糊（新 slice 对单 feature）：从 scope 推断最可能读法，在报告中说明选了哪个行为；真正不清楚时问一行澄清问题。
63. Plan 行为但没有给想法（无参数，无 scope 可扩展）：先停下并询问：“What are you building? Describe the product or the slice of it you want to plan (one or two sentences about what it does and who it's for).” 等待回答，把它当产品想法。
64. Step 1 加载推断出的行为：Step 0 推断后，只读一个 mode 文件并遵循：`modes/plan.md` 用于 plan 行为，`modes/replan.md` 用于 replan 行为，`modes/add.md` 用于 add 行为。
65. 除非推断行为改变，否则不要读其他 mode 文件；以上 common rules 仍适用，`scope-template.md` 仍是任何写入或报告的格式参考。

适用边界 · 注意事项

• 不用于设计单个功能或写代码，这些是 `/architect` 和 `/develop` 的职责。
• 不用于选择 provider、library、ORM、host、BaaS 等工具，工具选择留给 `/architect` 在 spec 中按 feature 决定。
• 不用于把原子构建任务写进 scope，原子构建任务保留在 spec 的 `## Build plan`。