close-plan

关闭计划

你正在为用户完成一项小功能的收尾工作。PLAN.final.md 已获批准并完成实现，而 docs/<feature>/（项目的规划文件夹，除非项目另有安排） 现在存放着促成该功能落地的修订版本、笔记和执行产物。如果放任不管，这个文件夹就会成为 下一个 Agent 最先阅读、也最信任的内容，而其中大部分已经不再属实。

评判你的标准是：一个全新的 Agent 只阅读文件树，能否以最少的跳转了解该功能的真实情况； 以及计划承诺的每个阶段能否找到明确去向：已落地、延续、延期，或根据用户决定取消。

绝不能擅自放弃工作。 最终文档承诺的阶段就是产品承诺。如果尚未落地，就应延续，除非用户另有决定；如果用户另有决定，就应连同原因记录到项目的延期工作记录中。

绝不能在记录决定时自行作出决定。 记录已经作出的决定是你的工作；作出新决定不是。

这是哪种技能

• 本技能 — 只有一份 PLAN.final.md、少量阶段，以及涉及几个领域的功能。大部分已落地内容都属于已有页面。
• close-roadmap — 路线图包含多个里程碑，功能规模大到需要独立的文档文件夹，README 是导航目录，并且 V2 路线图会重新进入路线图评审周期。

分界点不在于阶段数量，而在于该功能是否值得拥有自己的永久文档。如果关闭这份计划会新增文件夹 README、架构页面和三份决策记录，那你是在关闭路线图——请改用对应技能。如果只需在现有领域页面中添加一节，并补充一份决策记录，那就使用本技能。

输入

功能名称来自参数（例如 /close-plan spell-check）。 阅读整个 docs/<feature>/，然后：

1. PLAN.final.md（如果有 TECHNICAL.final.md，也要阅读）。如果只有修订版本，就停止：没有内容获批，因此无需关闭。
2. 执行记录 — EXECUTION.md、问题日志（项目存放开放问题的位置）、ACCEPTANCE.md、HANDOFF.md，以及任何未测试事项清单。记录的是声明，不是事实。
3. 代码和历史记录。 查看分支的 git log 和 EXECUTION.md 引用的提交，然后检查文档标记为已完成的每个阶段对应的代码。只有代码实现了验证步骤要求的行为，该阶段才算落地；文档声称已完成，并不能证明它已落地。
4. 该功能涉及的页面 — 根据项目的文档地图（例如 AGENTS.md 或 CONTRIBUTING.md 中的表格），确认每类内容应放在哪里。先阅读这些页面，再着手修改，确保新增内容与相关内容放在一起，而不是重复一份。

像相邻技能那样，对照主集成分支检查（运行 git fetch，然后执行 git log --oneline <branch>..<main>，其中 <main> 例如是 main 或 dev）；如果代码树后来已有变更，仍基于旧代码树关闭计划，就会记录一个已不复存在的状态。

验收评审

严格按照 close-roadmap 的说明逐项检查 ACCEPTANCE.md：每项都必须是通过（引用证据）、失败（该阶段尚未落地）或未运行（提出询问——在得到答复之前，该阶段不算落地）。未运行的检查意味着工作尚未验证；它之所以列在清单中，就是因为仅凭阅读代码无法确定，因此现在也不能只靠阅读代码来确定。

分类——动任何文件之前，先复述给用户

计划中的每个阶段、问题记录中的每条问题，以及任何未测试列表中的每个条目，都要按照 close-roadmap 表格中的同一规则，归入四种状态之一——已完成、待处理、延期、放弃；其中只有用户可以指定最后两种状态。将结果整理成表格（阶段、标题、状态、证据），标出需要回答的问题，并且**删除任何内容之前，先等待用户确认。**这份记录要写进提交消息；这是唯一无法从代码树中还原的输出。

由于内容较少，这份记录通常足够简短，可以直接放在报告中，而不必另写文档。

仍需完成的工作

• 一组连贯的剩余工作 → docs/<feature>/<STEM>-V2.rev1.md，文件名沿用最终文档使用的主干名称——PLAN.final.md 收尾后变为 PLAN-V2.rev1.md——按照 build-feature 编写 rev1 的方式撰写，并在 execute-plan 实施之前，重新进入 review-doc 审查流程。以“从这里继续”为开篇，复制最终文档中的长期要求和不变量并沿用（绝不要链接到即将删除的文件），并为每个待处理阶段重新编写输入、输出和验证步骤，使其符合当前代码的实际情况。
• 一两个未解决事项 → 项目的技术债务记录或待办列表，或者区域页面中“新工作从哪里开始”的说明。rev1 只包含一项遗留工作，却会被视为路线图，这纯属形式主义；不要为此创建 rev1。
• 记录中尚未回答的问题应成为 rev1 中的待解决产品问题，并附上记录中的选项和建议。已回答的问题属于决策；如果项目保留决策记录，就将其写入其中。

已完成的工作——整合进去，不要另起一摊

按照项目的文档地图，将每项内容写入相应位置，并遵循 close-roadmap 对各类目标文档的规则（决策写入决策记录，模型写入数据模型页面，用户操作写入用户指南，当前可用功能写入产品状态页面——如实说明已完成与部分完成的状态；阶段虽已验收但未经验证的，仍标为部分完成）。使用文档生成器，不要手动编辑生成的文件。

**规模较小时，默认做法就不同。**计划中已完成的工作应成为现有页面中的一段文字，而不是新页面——每个小功能都新建一个文件，会让文档树逐渐臃肿，也会让每位未来的读者都多走一步。只有当内容仅涉及此功能，且篇幅过长、无法纳入共享页面时，才创建 docs/<feature>/ 文件。

**不需要文件夹的功能，不应保留文件夹。**如果所有已完成的内容都已纳入共享页面，也没有剩余工作，就彻底删除 docs/<feature>/（只有在 notes/ 中包含值得保留的思考内容时才保留它，并标注为历史记录），让共享页面成为记录。在分类记录中说明这一点，让用户知道文件夹将被删除。

如果保留该文件夹，就需要一个 README.md——用一句话说明此功能，提供简短的导航表，并注明新工作应放在哪里。不必使用完整的 close-roadmap README；只有一份计划的文件夹不需要四个章节。

删除树中不再需要的内容

用户批准台账并完成文档编写后：删除 PLAN.final.md、所有 .revN.md 和 .revN.notes.md、EXECUTION.md、 该功能的问题日志、ACCEPTANCE.md、HANDOFF.md 以及任何未测试 清单——先将仍值得重新运行的验收检查移入该功能当前的测试计划。每轮结束时，这些文件都已提交，因此 Git 中保留了历史记录；工作树中的副本会被 Agent 误认为是当前版本。不要创建 archive/ 文件夹——那只是换了更长路径的删除操作。提交说明中应列出每个被删除的文件及其内容的去向。

修复所有指向这些文件的链接。 在文档、Agent 导览文件、README 和源代码树中搜索每个已删除或重命名的路径——源文件有时也会按名称引用文档。如果没有链接检查器，grep 就是链接检查，因此应在最后一次重命名后执行。

收尾

• 将收尾工作作为一项变更提交，遵循 commit-changes：记录台账、内容写到了哪里、删除了什么以及其内容的去向。除非用户要求，否则绝不推送。
• 用产品语言向用户汇报：该功能现在的作用、仍有哪些待办事项、用户在收尾期间作出了哪些决定，以及——如果有任何阶段是依据某个人的确认而非测试套件全绿才完成的——具体是哪些阶段。