实现过程中可直接改写已批准的产品和技术规格
原文依据:4 处该 Skill 指示代理在认为预期行为或设计“应该改变”时更新已签入的 PRODUCT.md 或 TECH.md,但没有要求先取得用户或原批准者对实质性变更的再次批准。把规格与代码放在同一个 PR 中有助于审查,却不能保证审查者会把规格变化识别为新的产品决定。
实现困难或代理判断可能被转化为新的需求、用户体验、架构或成功标准;随后代码会以修改后的规格为准,从而偏离用户最初批准的范围。
该 Skill 仅要求规格在开始实现前已获批准;实现中一旦认为行为或设计“应该改变”,便指示更新已签入的 PRODUCT.md/TECH.md,并将修改与代码放进同一 PR。虽然 PR 可供审查,但文本没有要求在实质性产品、UX、架构或验证策略变更后暂停并取得用户或原批准者的再次授权。因此,代理可能把实施判断转化为规格决定,影响用户预期和后续审批。用户可要求作者增加“实质性规格变更须明确重新批准”的门槛,并限制代理在批准前仅提出变更建议。
### 4. Update specs as the implementation evolvesIf implementation reveals that the intended behavior or design should change, update the checked-in specs rather than letting them go stale.In particular:- update `PRODUCT.md` when user-facing behavior, UX, edge cases, or success criteria change- update `TECH.md` when architecture, sequencing, module boundaries, or validation strategy change- keep those updates in the same PR as the corresponding code changesThe PR should describe the feature that actually ships, not just the initial draft of the specs.查看另外 3 个位置
Before considering the work complete, verify that the code matches the current specs.- confirm that `PRODUCT.md` exists- confirm that `TECH.md` exists when the feature warranted one- confirm that the relevant specs have been reviewed and approved enough to start implementation- update `PRODUCT.md` when user-facing behavior, UX, edge cases, or success criteria change- update `TECH.md` when architecture, sequencing, module boundaries, or validation strategy change- keep those updates in the same PR as the corresponding code changes