scope

输出风格（用语朴素，不使用破折号或连字符）

这个技能生成的所有内容，包括文件和消息，都要使用简单直白的语言。用 you 称呼读者，语气温和直接，就像与同事交谈一样。把每个步骤都写成建议，让读者自行决定执行或跳过，绝不要写成命令。保留确有意义的技术术语，并用简单的话解释。绝不要用破折号或连字符充当标点：不要使用 em dash、en dash，也不要使用带连字符的复合词。写 read only，不要写 read-only。尽量用简单的词，或改写句子。代码、文件路径、命令标志和其他技能会匹配的值要保留其中的连字符。使用短句、逗号或括号。清晰胜过巧妙。

这个技能的作用

把一个想法转化为有序、粗略且持续更新的计划，并在产品发布过程中确保计划符合实际。回答要做什么、按什么顺序做、工作量多大、哪些事项需要先做决定，而不是说明如何构建某一项（那是 /architect 和 /develop 的职责）。

范围的形式：粗略且精简，包括一张简明的概览表（# · Feature · Phase · Status）以及按阶段分组的功能章节（参见 scope-template.md）。每个章节包含：标题 ### N. Name，只在确有必要时添加简短标签（needs a decision、方法覆盖项，或类似 · GA 的工作流层级覆盖项）；1 到 2 行意图说明；一行 Done when:（验收标准的初步内容，也就是要做什么）；复选框步骤。

功能生命周期形式：尚未设计时只保留一个方框，写明进入该功能的命令。记录规格后，/architect 会补全已准备好构建的内容：勾选 Design it (spec)，链接规格，添加 Build it: /develop <feature>，并根据规格中的 ## Build plan 汇总出 2 到 5 个里程碑子项，然后添加 Verify it: /check verify <feature> 和 Test it: /test <feature>。原子级构建任务留在规格的 ## Build plan 中，绝不放在这里；每个方框都必须对应一条命令或一个受追踪的里程碑。在表格中和标题旁标明状态；规格和代码有指向时，再添加相应链接。

一条命令，根据意图判断（/scope [what]，绝不使用子命令）：

• plan（默认）：尚无范围，且收到的是产品规模的想法，或者用户在询问下一项工作。完整流程：提问 → 拆分为粗略的功能章节 → 排序并分阶段 → 写入计划。
• replan：已有范围且没有参数。先用简短说明概述当前情况（Git 分支及其相对远程分支的领先或落后情况、各状态的功能数量，以及每个进行中功能的恢复位置），让单独运行的 /scope 同时发挥“进度到哪了，哪些内容可以放心接手”的指引作用。然后核对已发布的内容，找出计划与实际的差异（代码或规格中有内容但范围里没有对应行），纳入构建过程中发现的需求，重新排序，并安排下一项工作。这是常规的持续更新节奏，不是偶尔才做：再次单独运行 /scope。
• add：已有范围，且参数指向某一个功能。添加一条粗略条目（意图、顺序、层级和 Needs spec），不重新规划：/scope <a feature>。

提问与执行

像资深产品工程师一样工作。遵循与 /architect 相同的判断、提问和建议原则：推断想法中明确说明的内容（类别、显而易见的能力）；对无法从业务、产品或市场推广方面推断的内容进行提问，并分批提问（每轮最多 4 个问题；参见 Decision panels）；建议构建方法、构建顺序和工作流层级（项目默认值及各功能的覆盖项），并判断哪些事项需要规格（专家判断：提出建议，并允许工程师覆盖）。

绝不选择工具：不要选择或指定任何提供商、库、ORM、主机或 BaaS；这些是 /architect 在各项功能的规格中负责的工作。凡是涉及工具选择的功能，都应明确标为 Needs spec: yes。保持范围不依赖具体工具，避免计划过时。

决策面板（所有面向用户的选择）

每项选择都应是选项面板，而非中立菜单：提供 2 到 4 个符合本产品实际情况的具体选项；恰好一个标记为 (recommended)，并附上一行推荐理由（直接做出判断，同时允许用户覆盖）。切勿自行添加「其他」选项；选择器会自动追加自由文本「其他」。只有在纯文本备用方案中（不使用选择器），才自行提供自由文本输入。优先使用能力：使用 Agent 的选择器（Claude Code 中为 AskUserQuestion）；否则以纯文本提供相同选项；分批提问时遵循同一规则，每轮最多 4 项。

工件归属

docs/scope/ 是本技能负责的功能范围；/architect 负责 docs/specs/。其他技能通过扫描 docs/scope/ 查找功能所在行。持续维护的文档：plan、replan、add 都在原处编辑（协调并追加，绝不新建带日期的文件）。不写入其他内容：不写规格、代码或 AGENTS.md。docs/scope/ 仅存放范围文件；清单、分析和研究文档与规格一同存放在 rationale.md 中（由 /architect 负责）。

文件结构：

• 小型产品：一个文件，docs/scope/scope.md（概览表 + 按阶段分组的章节 + 图例）。
• 大型产品：按 Epic 拆分：docs/scope/index.md（跨 Epic 的概览表 + 每个 Epic 一行状态汇总，各自链接到对应的 Epic 文件）+ 每个 Epic 一个文件，按领域命名（docs/scope/auth.md、……）。
• 按需拆分：先使用单个文件；当 scope.md 增长到不便于快速浏览时（大约跨越多个明显不同领域的十多个功能），将其重命名为 index.md（保留表格和每个 Epic 的汇总），并将各领域的章节移至各自的 <epic>.md 文件。切勿过早拆分。名称应具有语义（scope.md / index.md / <epic>.md），绝不编号。
• 每个文件都应保持粗粒度且简短；较长的 Epic 文件需要拆分为更细的功能并明确意图，而不是罗列构建任务。

状态生命周期（/scope 设置初始状态；工作流推进状态）：

• 新功能以 planned 开始。对于已有项目，也要登记现有功能：已完成的标为 existing，部分完成的标为 in-progress；这是 /scope 写入的仅有其他状态。
• /develop 推进工作流构建的功能状态（planned → in-progress → done）；/sync 根据差异进行协调。基于假定决策构建的功能（其管辖规格为 Assumed，即工程师在决策尚未确定前选择先行构建，并由 /develop 记录）会保留 assumed decision (spec NNNN) 注记，直至 /architect 批准该决策；该注记不会阻止状态变为 done，它属于决策债务，在批准前会一直显示。
• done ≠ existing：done = 由此工作流构建并验证；existing = 在工作流开始前已存在；/develop 和 /sync 永远不会修改 existing 行。
• replan 可以将已从范围中移除的功能设为 dropped，但绝不删除行；dropped 会保留历史记录，不计入活动统计，也不参与工作；/develop 和 /sync 会跳过它。

工作流层级（每项功能一个严格度档位，Prototype · Alpha · Beta · GA）：规定功能需要多严格的流程。整个项目设置一个默认档位（在 plan 步骤 5b 中推荐一次，并记录在范围文件头部的 **Workflow:** 行中），每项功能也可单独覆盖（当功能与默认值不同时，在标题旁添加标签，例如 · GA；无标签 = 继承默认值）。档位的作用：

• 设计阶段：档位越高，越可能需要 Needs spec: yes，并运行规格的跨模型决策评审器（在 GA/Beta 时自动运行）。Prototype/Alpha 功能通常 Needs spec: no。
• /develop 之后（验证收尾流程）：Prototype = 无（依靠 /develop 自带的构建时自检）；Alpha = /check verify；Beta = /check verify + /test；GA = 另外执行一次全新的模型 /check review + /document。
• 完成 done 的条件（最后一个必需阶段将其标记为 done）：Prototype → /develop（构建 + 自检）；Alpha → /check verify；Beta/GA → /test。Assumed 规格绝不会阻止状态变为 done；任何档位下，它都会继续标记为尚待 /architect 批准。 /scope 会根据功能组合的风险和规模，推荐项目默认级别（第 5b 步）；/architect 和 /develop 读取的也是这些信号。/develop 会读取生效级别（功能覆盖级别，否则使用项目默认级别，否则推断），据此调整其推荐后续步骤的规模，避免要求 Prototype 项目运行 verify，也避免要求 Alpha 项目执行完整审核流程。

产物基目录：默认是 docs/；如果检测到 docs/ 是已发布的文档站点（docusaurus.config.*、.vitepress/、mkdocs.yml、Astro Starlight 或 Nextra），则使用 .workflow/（.workflow/scope/…）。始终遵循已有的基目录（此处路径均假设为 docs/）。

并发：跨会话和团队成员共享。写入前立即重新读取；仅进行精准修改（按顺序追加行，协调已更改的单元格，绝不重写文件）；遇到意外状态时标记出来，而不是覆盖；追加时使用下一个可用编号，避免添加者之间发生冲突。

参考文件

• scope-template.md：格式规则、At a glance 表格、每个功能的章节（标题 + 意图 + 完成条件 + 复选框任务 + 指针行）、存量项目纳入和史诗拆分格式，以及 ## /scope complete 报告块。编写范围和报告时请阅读。

可移植性（适用于任何操作系统和 Agent）

适用于 macOS、Linux、Windows 上的任何 Agent Skills 客户端。检测代码片段是 POSIX 参考；请使用 Agent 的跨平台文件工具。规划直接内联运行；以下两个子 Agent（第 1 步的存量代码扫描、第 6b 步的信息收集）均为可选，优先考虑能力；如果能力不足，则改为内联执行。不要使用交互式选择器：以纯文本形式询问每个选项，并提供相同的选项。

执行

第 0 步：推断意图并检查想法

无子命令。首先检查 docs/scope/ 下是否存在范围（如果产物基目录是 .workflow/，则检查 .workflow/scope/），然后推断：

• 存在范围且无参数（或再次运行，描述为“协调 / 接下来做什么”）→ 重新规划行为（modes/replan.md）。
• 存在范围且参数指向单个功能 → 添加行为（modes/add.md）。
• 尚无范围，且给出产品规模的想法，或要规划下一个部分（包括存量项目）→ 规划行为，见下文。

意图不明确（新增一个部分还是单个功能）：根据范围推断最可能的含义，并在报告中说明选择了哪种行为；确实不清楚时 → 提出一行澄清问题。

规划行为中，如果未给出想法（无参数，且没有可扩展的范围），则停止并先询问：

“你要构建什么？请描述你想规划的产品或其中的部分（用一两句话说明它的功能和目标用户）。”

等待回答，并将其作为产品想法。

第 1 步：加载推断出的行为

第 0 步推断出行为后，读取且只读取一个模式文件，并遵循其中的说明：

• 规划行为（新范围、产品规模的想法或规划下一个部分）读取 modes/plan.md。
• 重新规划行为（已存在范围且无参数）读取 modes/replan.md。
• 添加行为（已存在范围且参数指向一个功能）读取 modes/add.md。

除非推断出的行为发生变化，否则不要读取其他模式文件。上述所有通用规则仍然适用；任何写入或报告的格式参考仍为 scope-template.md。