变更（存量系统）是做什么的？

对现有规格说明书和代码库添加一个有界、可审查的变更，无需编写新的 PRD。一次变更生成一个提案和恰好一个四文档任务包；QA 通过后，确认的差异会被写回规格说明书，并将提案归档。本技能以提示为先：每一步都有手动回退方式，附带的脚本仅为可选的辅助工具。

管道位置：spec-generator -> change -> task-decomposition -> plan-linter (Gate 1) -> review (Gate 2) -> dev -> qa -> converge -> 归档。

existing spec + bounded change
  -> .specs/change-context/standards.md        (standards_extract.py; 隐式约束)
  -> .specs/changes/<change-id>/proposal.md    (生命周期: proposed -> applied -> archived)
  -> tasks/<change-id>/01..04                  (一个合约，一个任务包)
  -> Gate 1 plan-linter -> Gate 2 review -> dev <-> qa -> converge -> archived proposal

适用场景

现有规格说明书或已发布代码库需要增量变更：例如修复缺陷、添加小功能、调整行为、有界的非功能需求(NFR)调整。
变更可以复用现有的 #sec-* 锚点，并且符合微/标准差异预算。
你希望执行提案 -> 应用 -> 归档循环，同时保持此仓库的四文档任务协议和每个文件单一所有者的角色。

不适用场景

工作是新项目，或没有上游规格说明书存在：请使用 prd-generator，然后 spec-generator，最后 task-decomposition。
变更需要新的架构决策、新的组件边界、新的跨切面不变量或全新的规格说明书章节（新的 #sec-* 锚点）：应升级到 spec-generator，而不是将其偷偷塞入变更中。
你只需要将已批准的规格说明书切分任务：使用 task-decomposition。
你只需要审核现有的任务包或提案：使用 plan-linter。
任务已经规划好，等待实现/验证：使用 dev / qa。

输入

基础规格说明书：默认为 .specs/02-tech-spec.md（及其模块化部分）。
有界变更的需求，由请求者用自然语言书写。
步骤 1 中生成的仓库约定报告。
可选：变更所基于的现有任务包，以及相关的 ADR。

输出

产物	脚手架创建后的负责人	用途
`.specs/change-context/standards.md`	工具链	确定性的仓库标准和隐式约束（自动生成，绝不手动编辑）。
`.specs/changes/<change-id>/proposal.md`	规划者	有界变更提案：动机、增量差异、影响范围、不变量/NFR、回滚、验证。
`.specs/changes/<change-id>/convergence.md`	收敛工具链	QA 通过后编写；记录被折叠回规格说明书的内容。
`tasks/<change-id>/01-contract.md` ... `04-process.md`	规划者/开发者/QA/工具链	恰好一个四文档任务包，复用 task-decomposition 模板。

提案不是 PRD，也不是替代规格说明书。它是一个差异描述，指明它修改的现有锚点。完整生命周期和规模规则：references/brownfield-protocol.md。

工作流

提取仓库标准（每次配置变更执行一次）：
```
python .agents/skills/change/scripts/standards_extract.py --repo-root . --json
python .agents/skills/change/scripts/standards_extract.py --repo-root . --check
```
在规划前阅读 .specs/change-context/standards.md。其“隐式约束”部分具有约束力：只能使用它明示的命令，遵守声明的测试布局、运行时下限和现有锚点。--check 退出码 1 表示报告已过时；规划前需重新生成。切勿手动编辑该报告。
脚手架创建提案和一个任务包（唯一步骤会写文件）：
```
python .agents/skills/change/scripts/scaffold_change.py \
  --change-id CHG-001-rate-limit \
  --title "Rate limit login attempts" \
  --anchor "#sec-auth-tokens" \
  --kind modify \
  --size-class micro --estimated-lines 40 \
  --touch-files "modify:src/auth/rate_limit.py" \
  --repo-root .
```
脚手架程序会根据基础规格说明书验证锚点，计算 base_spec_sha256，并委托给 task-decomposition（scaffold_task.py）或在没有该工具时生成最小的内联任务包。使用 --dry-run 预览，使用 --force 覆盖可丢弃的运次。
规划者填写提案和合约。 替换提案中的指南（motivation，[CHG-<n>] 代码块，路径，不变量/NFR，回滚，验证）和合约中的占位符（module，adherence_adrs，dod，边界情况，不变量说明）。不要发明路径或锚点。保持 02/03 为空白角色表单；保持提案 status: proposed。

Gate 1，然后 Gate 2。 运行确定性的 Gate 1，然后进行独立的语义审查：

# 从仓库根目录运行。Gate 1 辅助工具要求安装 plan-linter 技能。
python .agents/skills/plan-linter/scripts/plan_linter.py --tasks-dir ./tasks --repo-root . --spec .specs/02-tech-spec.md --changes-dir .specs/changes
python .agents/skills/change/scripts/lint_change.py --change-id CHG-001-rate-limit --repo-root .

Gate 1 必须在实现之前通过；Gate 2 必须不报告 BLOCKED 或 REQUEST CHANGES。

实现并验证。 运行 dev（仅限声明的 touch_files，填写 02，移交）和 qa（tests/acceptance/ 下的独立测试，填写 03，一个结论）。一旦实现和验证通过，提案移至 applied。
收敛并归档。 QA_PASSED 后，运行 converge 将确认的偏差追加到 .specs/02-tech-spec.md，写入 convergence.md，将任务包移至 tasks/archive/，并将提案 status 设为 archived。如果没有 converge，手动执行相同的追加写回操作。

手动回退方式（无 Python）

手动构建标准列表：仓库根目录配置、测试/源代码树、运行时、#sec-* 锚点。
复制 assets/templates/proposal.template.md 到 .specs/changes/<change-id>/proposal.md，填写每个 token（{{...}}），并计算 base_spec_sha256。
使用 task-decomposition 模板或 references/brownfield-protocol.md 中的回退方式创建 tasks/<change-id>/ 四文档任务包。
手动运行 Gate 1 / Gate 2 检查清单；在任务包中记录证据。
使用相同的产物执行工作流步骤 5-6。

质量门检查清单

标准报告已生成且最新（standards_extract.py --check 退出码 0）。
提案前置元数据完整，status: proposed，kind 正确，base_spec_sha256 最新。
每个 [CHG-<n>] 代码块都命名了一个基础规格说明书中真实存在的 #sec-* 锚点。
恰好存在一个任务包；change_id 等于提案 ID，且 origin_spec_anchor 是提案 impact_anchors 之一。
差异预算得到遵守：微变更使用 1 个触及文件（默认 10-49 行）；标准变更使用 1-3 个文件（默认 50-250 行）。数字可在 plan-linter 配置中调整。
Gate 1 在填写后的合约上通过，并且提案为开放状态（proposed/applied）。
Gate 2 审查没有阻塞性发现；审查者独立且只读。
开发者仅实现了 touch_files；QA 发布了唯一的结论并附有证据。
收敛将差异追加到了规格说明书，且提案已 archived。

反幻觉规则

切勿凭空编造文件路径。 每个 touch_files 条目必须是一个要 modify 的现有文件，或者是现有目录中要 create 的新文件（仓库相对路径，使用正斜杠）。
每个差异代码块必须引用一个真实锚点。 复用现有的 #sec-* 锚点；脚手架程序和 linter 会拒绝缺失或漂移的锚点。
切勿发明命令或约定。 只有声明的配置（标准报告）所明示的命令才能出现在合约的完成定义(DoD)中。
结构变更应升级。 如果变更需要新的规格说明书章节/锚点、新的组件、新的 ADR 或不变量的变化，请停止并使用 spec-generator。
不要夸大网关的作用。 Gate 1 是确定性的簿记检查，Gate 2 是提示式审查；git 和 CI 仍然具有权威性。

辅助脚本

scripts/standards_extract.py — 确定性的标准提取器；写入 .specs/change-context/standards.md（支持 --json，--check，--dry-run，--version）。
scripts/scaffold_change.py — 创建提案和一个任务包（支持 --dry-run，--force，--json，--version）。
scripts/lint_change.py — 提案/任务包一致性和基础规格说明书漂移检查（支持 --json，--version）。

所有辅助脚本仅依赖标准库，自行解析目录，并退出码 0（成功）、1（门检查失败）、2（用法错误）、3（意外错误）。

失败处理

缺少基础规格说明书：停止。存量变更需要基础规格说明书；脚手架程序退出码 2。
未知锚点：停止并复用现有锚点，或升级到 spec-generator。
过时报告或规格说明书漂移（退出码 1）：重新生成报告，重置提案基础，重新运行 Gate 1；切勿手动编辑 base_spec_sha256。
变更目录已存在：仅在可丢弃时使用 --force 重新运行；否则编辑现有提案。
脚本不可用：遵循手动回退方式；工作流以提示为先。

诚实限制

标准报告描述的是声明的配置，不一定是实际执行的实践；它是给规划者的提示，而非合规的证明。
base_spec_sha256 检测基础规格说明书的任何字节变化；收敛后，已归档的提案不受漂移检查的影响。
可选脚本可以绕过；CI 和仓库权限仍然是权威的。

变更（存量系统）