implementation-checklisted

# implementation-check 在 Engineer 完成实现后、进入 QA 验收前，对任务范围、实现 diff、验证结��和已知风险做自检；它是 QA 前门禁，不替代 QA 的独立验收结论。 ## 用法 `/implementation-check <任务定义、PRD 或 pending diff>` ## 目标 - 确认实现是否匹配 task-spec、PRD 或架构约束 - 检查变更文件是否落在声明范围内 - 汇总定向验证证据和未覆盖项 - 检查长任务字段完整性和上下文恢复性 - 给出“建议进入 QA / 不建议进入 QA”的明确结论 ## 适用场景 - 实现已完成，准备提交 QA 前 - 需要核对 pending diff 是否偏离任务范围 - 需要整理验证证据和已知限制 - 多文件改动需要先做实现侧自检 ## 不适用场景 - 替代 `/acceptance-check` 的 QA 验收 - 在实现前生成任务或需求 - 直接修改代码 - 掩盖测试失败或未完成实现 ## 检查清单 每次自检必须逐项记录状态、证据和结论： 1. **范围一致性**：实现是否只覆盖任务定义、PRD 或架构约束声明的范围；偏离范围时列出文件和原因。 2. **文件变更**：列出新增、修改、删除文件，说明每个文件与任务输出的关系。 3. **测试证据**：记录已运行的定向命令、文档检查或人工检查路径，以及关键结果。 4. **任务字段完整性**：检查任务 ID、`depends_on`、`read_before_start`、`execution`、`evidence`、`handoff` 是否存在；缺失时必须说明原因和影响。 5. **上下文恢复性**：判断新会话是否能只依赖任务文件、依赖产物、pending diff、`evidence` 和 `handoff` 恢复任务状态。 6. **已知限制**：说明未覆盖场景、外部依赖、无法验证项或需要人工复查的内容。 7. **风险项**：评估兼容性、数据、权限、性能、安全和发布风险；无风险时写“未发现”。 8. **QA 进入结论**：只能输出 `建议进入 QA` 或 `不建议进入 QA`，并给出一句理由。 ## 执行规则 1. 先定位任务定义、验收标准、架构���束和 pending diff 来源。 2. 每个检查项必须给出证据：文件路径、命令或 diff 范围。 3. 若实现偏离任务范围，结论必须是“不建议进入 QA”。 4. 若长任务字段缺失且没有说明原因，不得给出“建议进入 QA”。 5. 若关键验证缺失或失败，不得给出“建议进入 QA”。 6. 若任务无法在清空聊天上下文后由文件和产物恢复，不得给出“建议进入 QA”。 7. 发现问题时输出退回 Engineer 的具体修正项。 ## 示例 - `/implementation-check tasks-p8.md 中 token-report skill 变更，核对 pending diff 是否只包含 SKILL.md 和任务勾选` - `/implementation-check bugfix 提交涉及 unrelated README 改动，判断是否偏离任务范围` ## 输出骨架 ``` [示例：实现符合任务] [自检对象] ... [范围一致性] 通过（证据：...） [文件变更检查] - path: 与任务输出的关系 / 是否在范围内 [任务字段完整性] - 任务 ID / depends_on