ccoalm Requirement Scope
方向已定之后，把它界定成变更边界：本轮改哪些、不改哪些、影响谁、依赖什么、切几版、愿意花多少。哪些对象受影响、哪些先不做时进入本技能。
硬约束（先读，全程适用）
- P0 核心 in/out 由
human-decision关闭。 agent 不得自行决定，也不得决定产品目标、核心路径、成本级别或验收承诺。 - as-is 证据不裁决 should-be 范围。 代码、数据、架构等描述性证据不能自行决定本轮改不改。
- 边界要可审查。 in/out 写成行为边界，不用「优化体验」这类不可判定的模糊标签。
- 先判 appetite 是否适用，再记录投入与取舍。 Shape Up 的 appetite 用于在固定投入下调整范围；它不是每张影响范围表的必填前提。
- 任务要求投入决策，或已有适用的投入上限时，记录已确认上限和超出时可调整的范围。取舍未定就保留已知上限，把未知子项标
open，继续交付其余字段；不得自行砍掉核心范围、降低既有验收要求或承诺按期完成。 - 人工兜底只在业务连续性、降级或已批准决策确实需要时填写；不需要时写明依据，不为填表虚构人工接管。
- 仅做影响范围盘点、未涉及投入决策时，可按任务边界记
not-applicable。用户要求省略展示细节时遵从该要求，已确认约束和未决事项保留在关闭表中；省略展示不等于撤销既有约束或关闭未决承诺。
- 任务要求投入决策，或已有适用的投入上限时，记录已确认上限和超出时可调整的范围。取舍未定就保留已知上限，把未知子项标
- 关闭表只补自己那部分。 唯一 canonical 是
requirement-doc-writer/references/requirement-closure-contract.md。本技能按复合字段子项补版本、范围、appetite、依赖和验收，逐项记录推导、决策权和决策证据；只能自动填写单个低风险、可逆的非核心展示/表达细节（decision_authority 记bounded-agent-policy，且须有可引用的已批准 policy），任一适用子项 open 时复合字段和整行保持 open/blocked。 - 「非目标」在这里是变更级——本轮明确不改、延后、保持兼容、无需迁移的对象。意图级的「本轮不追求什么目标」属
requirement-intent。同理「验收」在这里是每个切片的验收边界与不验收项，不是功能点 pass/fail。
安全 4 问（命中即阻断）
范围涉及身份、计费、配额、租户/用户隔离、权限、删除、覆盖时，范围表必须逐项记录安全 4 问的答案（无命中则显式记"无安全敏感输入"），负向用例写入验收范围。命中上述任一项时，必须先读取 requirement-doc-writer/references/security-four-questions.md（问题本体 canonical，含本技能的落点细则）再作答，并在产物中写明所依据的 canonical 文件名 security-four-questions.md（实测：要求一段固定字样的旧写法命中率仅 20.5%，而逐项作答与写明来源文件分别可达 82% / 59%——本仓无法机械校验运行时产物，故只要求可核的实质，不要求不可核的字面戳）；凭记忆或转述作答、未写明来源、或命中后仍记"无命中"，均为违规。读取不可得时（本会话无文件读取工具 / 文件缺失 / 读取失败）走这条路径，不得声称已读：改写 依据: 不可得(<原因>)；按常驻反射尽力作答、本节标 interim 并写出解除方式，缺口连同风险标签交 feature-risk-router，由风险 owner 决定是否接受推迟——接受的是推迟、不是关闭：本节转正式关闭仍须真实读取 canonical 后逐项重答；agent 与需求提出方均不得自行判为已关闭。always-on 常驻反射见 agent-context/session-start.md「设计期安全 4 问」；本节只定义产物落点与交接。
命中后先让 feature-risk-router 定级并选择 gate；进入交付计划时回 product-rd-workflow。
产出
| 模块 | 内容 |
|---|---|
| In scope | 本轮必须改变的用户、对象、流程、规则、界面/API/数据结果 |
| Out of scope（变更级非目标） | 明确不改、延后、保持兼容、无需迁移的部分 |
| 受影响对象 | 角色、页面、入口、API、数据、运营规则、通知、报表、权限、文档 |
| 版本切片 | MVP、后续版本、迁移/兼容切片、回滚/降级边界 |
| Appetite / timebox | 适用性与依据；适用时记录已确认投入上限、超限取舍和必要的兜底 |
| 依赖 | 上游决策、外部系统、数据准备、设计、法务/运营/支持动作 |
| 风险点 | 权限、隔离、计费/配额、删除/覆盖、数据迁移、发布复杂度 |
| 验收范围 | 每个切片的可观察验收边界和不验收项 |
| 需求点关闭表 | 按共享契约补版本、范围、appetite、依赖和验收边界 |
Workflow
- 锁定目标与输入：引用已澄清需求或盘点事实。缺某条 as-is 事实不自动回
requirement-baseline——标为未确认、写明缺口和取得方式，继续交付范围表；只有用户点名要现状清单、或缺口大到范围表无法成立时才交回，后者是决策不是 agent 的判断题。 - 列受影响对象：用户、流程、界面/API、数据、权限、运营、文档逐项过一遍。
- 写 in/out scope：按硬约束 2、3。
- 切版本：P0、后续、迁移、兼容、回滚/降级分别列清；按硬约束 4 判断并填写 appetite。
- 标依赖和风险：把安全 4 问命中项、跨团队/系统依赖、数据风险拉出来。
- 更新
需求点关闭表（按硬约束 5）。 - 写验收范围：每个切片对应 pass/fail 条件，明确不验收项；安全命中项的负向用例写进验收范围。
- 路由下一步：风险 gate、PRD、研发计划、测试策略或 TC。
不用本技能，改用谁
- 方向还没定、实质不清 →
requirement-intent。 - 要现状清单（现在怎么运作、有什么能力）→
requirement-baseline。 - 风险定级、灰度、review/gate 选择 →
feature-risk-router。 - 实现计划、发布计划、跨阶段生命周期 →
product-rd-workflow。 - 测试层选择、测试矩阵、CI gate →
testing-strategy；结构化 TC / Feishu Bitable →test-artifact-management。 - 完整 PRD 起草 →
requirement-doc-writer（且须 lifecycle 已判PRD Ready）。
完成标准
逐条可核，缺一条即为 interim 而非完成：
- in/out 每一项都是可审查的行为边界，没有模糊标签。
- 受影响对象十类（角色/页面/入口/API/数据/运营规则/通知/报表/权限/文档）逐类过了一遍，不适用的显式写「无」。
- 每个切片都有可观察的验收边界和不验收项。
- appetite 按硬约束 4 判定适用性；适用子项有决定或明确的未决状态，不适用有依据。未知项不被抹掉，也不阻断其余范围材料。
- P0 核心 in/out 标了
human-decision，没有被 agent 自行关闭。 - 关闭表里任一适用子项 open 时，复合字段和整行保持 open/blocked。
- 安全 4 问：记了「无命中」，或四项逐条答案 + 写明所依据的 canonical 文件名；命中项的负向用例已在验收范围里。
输出模板
改动范围图
- 目标：
- In scope：
- Out of scope（变更级非目标）：
- 受影响对象：
- 版本切片：
- Appetite / timebox（适用性与依据；适用时写投入、取舍与必要兜底）：
- 依赖：
- 风险点：
- 验收范围（含不验收项）：
- 需求点关闭表：
- 安全 4 问：无命中 / <逐项作答四项>
- 依据来源：<读到了写 `security-four-questions.md`；没读到写 `不可得(<原因>)` 并把本节标 interim。不得留空>
- 下一步 owner：