john-walks-slow workflow-implement-review
作为主工程师完成修改的实施与交付。 保证开发质量，对最终用户体验和长期开发者体验负责。
遵守以下工作流程：
1. Implement
仔细阅读提供的计划或问题诊断，实施代码修改。遵循最佳编码实践————代码的可读、可维护 与功能实现同样重要。
当你完成全部计划中的全部实施内容后才进入下一步。
2. Test
检查 IDE 是否报错，确保项目编译正常。 若项目具有测试规范，按照惯例运行和编写测试。
当通过静态验证和测试用例验证后才进入下一步。
3. Review
特别地：在你的修改少于 50 行，且改动风险极为可控时，可跳过此步骤。
使用 /spawn-reviewer 检视代码（而不是使用 bugbot 子代理），指定检视报告输出位置：
- 需求开发：
/docs/features/yymmdd-{feature_name}/yymmdd-{feature_name}.review.md - 问题修复：
/docs/issues/yymmdd-{issue_name}/yymmdd-{issue_name}.review.md
若检视发现阻塞问题、合理的建议和值得优化的非阻塞问题，则进行修改和优化。 若前次检视结果低于条件准入，则在修改后再次将本次实施的全部代码提交检视。 直到拥有准入或条件准入结论后才进入下一步。
4. Validate
使用 /update-validation-requirements 创建或更新用户验证要求文档。只记录最重要的核心场景，以及自动化测试无法可靠覆盖、必须实机验证的场景；没有符合条件的验证项时直接说明无需额外用户验证。
向用户简述本次实现，请用户按照验证文档完成验证并填写实际结果、状态和备注/证据。
当用户书面确认功能正常后才进入下一步。
若实际现象与你的预期明显不符，请撤销无效的、可疑的修改，使用 /workflow-troubleshoot 重新定位问题。 如果你连续多次修改都未达预期，意味着当前思路不可靠或缺乏关键线索，继续试错只会引入更多不确定性。请清空既有思路从零梳理，不要在错误的路径上反复打转。
5. Documentation
记录本次工作的背景与结果：
- 需求开发：
/docs/features/yymmdd-{feature_name}/yymmdd-{feature_name}.summary.md - 问题修复：
/docs/issues/yymmdd-{issue_name}/yymmdd-{issue_name}.summary.md
遵循规范按需更新模块级和项目级 AGENTS.md。当且仅当有对后续开发有明确收益的通用经验时，记录到模块 pitfalls 部分。
6. Commit
最后，提交本次修改的文档和文件。遵循项目提交规范。如果你在 worktree 中工作，将提交合并回主工作树。
备注:
当用户书面要求时，你可以调整工作流。如：跳过用户 validation 步骤；并行 spawn 多个 reviewer；commit 前需确认等。