When to use
- •任务开始前：当你需要了解当前项目的进度、上下文或具体需求时。
- •任务完成后：当你需要记录工作进度、更新任务状态、补充技术细节或调整后续计划时。
- •发现新问题时：当你发现原有计划有误，需要修改架构设计或添加新的待办事项时。
When NOT to use
- •不要用于简单的代码注释更新（那是代码维护）。
- •不要用于非
plans/目录下的文档（除非是迁移文档）。
核心原则 (Core Principles)
- •执行前必读：在开始写代码之前，必须先读取相关的 plan 文档，确保你完全理解上下文。
- •执行后必记：工作结束后，必须更新文档。不仅仅是打钩，更要记录“做了什么”、“遇到了什么问题”、“改变了什么设计”。
- •灵活更新：不要只局限于打钩。你可以重构文档结构、添加新的章节、修改错误的描述、重新排序任务优先级。
- •保持真实：文档必须反映项目的真实状态。如果代码和文档冲突，更新文档以匹配代码（或反之，取决于任务目标）。
工作流 (Workflow)
1. 定位与读取 (Identify & Read)
首先找到与当前任务相关的文档。如果你不确定，先列出目录。
bash
ls plans/
然后读取文件内容：
javascript
read_file("plans/xxxx.md")
2. 执行任务 (Execute)
根据文档中的指示进行代码编写、重构或调试。
3. 更新文档 (Update)
任务完成后，使用 apply_diff (推荐) 或 write_to_file 更新文档。
更新内容建议：
- •任务状态：将
- [ ]更新为- [x]。 - •进度日志：在文档底部（或专门的日志区域）添加更新记录。
- •格式参考：
*文档更新时间: YYYY-MM-DD - [简要描述]*
- •格式参考：
- •新增发现：如果在执行中发现了新问题，直接在“待完成”或“问题记录”章节添加新的
- [ ] Item。 - •架构调整：如果修改了核心逻辑，同步更新文档中的 Mermaid 图表或文字说明。
示例 (Examples)
场景 1：完成了一个小任务
你读取了 plans/feature-x.md，发现任务 - [ ] Fix login bug。
修复 bug 后，你使用 apply_diff：
- •将
[ ]改为[x]。 - •在文件末尾添加：
*文档更新时间: 2024-03-20 - 修复了登录页面的空指针异常，更新了验证逻辑。*
场景 2：发现原计划不可行
你读取了 plans/migration.md，原计划是用 A 方案，但你发现 A 方案在当前架构下行不通，必须用 B 方案。
你使用 apply_diff 或 write_to_file：
- •修改 文档中的“技术方案”章节，将
A改为B，并简述原因。 - •更新 待办列表，替换相关的任务项。
- •记录 日志：
*文档更新时间: 2024-03-20 - 废弃方案 A，改用方案 B，因为 A 方案会导致循环依赖。*