implementation-self-review — 实现自我评审

实现自我审查目的 在第一次实现通过后、在最终交付之前或当用户对代码组织、必要性、命名、防御性检查、迭代范围或重复返工提出疑问时运行此技能。将其视为紧凑的工程自我审查，而不是广泛的重写命令。

审查工作流程 识别更改的行为和受影响的文件。将更改与存储库的活动架构和协作规则进行比较。使用以下门槛审查实现。首先报告具体的发现；如果没有问题，请明确说明并列出残余风险。仅当用户请求实现或当前任务已经是实现任务时才解决问题。

门槛 放置门槛 问：在当前文件中添加此代码是否会使文件的职责不明确？将其分割到新文件中是否会使功能更难以审查、跟踪或删除？行为是否可以从本地结构中读取，而无需跳转到许多薄文件？更喜欢现有的本地模式和紧凑的组织。仅当它阐明了真正的职责边界或避免了有意义的拥挤时才添加新文件。

必要性门槛 对于每个新类型、字段、接口、配置、抽象、帮助器和状态值，问：它是否被当前接受的契约所需？它是否只是一个面向未来的占位符？它是否可以被删除、合并或用现有的名称或字段来表示？显式标记过度设计。更喜欢删除未使用的结构而不是记录为什么它可能在以后有用。

边界和防御门槛 对于每个 nil、空、默认、回退或防御性分支，问：这是一个真实的边界，哪里不受信任或可选的输入进入？这是掩盖了应该严格的构造函数或调用者契约吗？在设置时快速失败是否会使不变量更清晰？将防御措施保持在入口/配置边界。避免内部防御性检查，这些检查会使所有权不明确。

命名门槛 对于长名称或重复的术语，问：周围的类型/文件是否已经提供了部分含义？名称是否描述的是实现机制而不是域意图？术语是否可以在不失去审查清晰度的情况下缩短？更喜欢干净的域名而不是堆叠的限定符。

同类扫描门槛 当用户指出一个问题时，在编辑之前扫描同一类：类似的冗余字段或概念。类似的过度防御性分支。类似的命名或术语漂移。类似的文档/测试/原型不一致性。告诉用户进行了什么同类扫描，然后进行一次连贯的传递。

迭代范围门槛 在添加新功能迭代文档之前，问：当前迭代是否已经提交或稳定？更改是否改变了已定的能力边界、职责边界、默认行为或配置契约？这是对当前未提交迭代的更正吗？如果当前迭代仍在进行中，则将大多数契约措辞或规则更改视为对该迭代的调整，而不是创建新迭代。不要让被拒绝的临时设计污染当前设计.md。

返工停止门槛 如果同一个问题已经被修订五次或更多次，暂停并告诉用户：此点已经被修订至少五次。契约仍然看起来不稳定；我建议在进行更多编辑之前暂停实现并重新对齐职责边界、必要性和接受标准。不要继续推进通过发明更多的实现更改。

输出形状 使用此顺序：按严重程度的发现，审查代码时带有文件引用。同类扫描结果。所需的修复或提议的简化。检查的规范。已经运行或仍需要的验证。保持报告简洁。除非用户请求审查，否则不要将此技能转变为完整的代码审查。