| name | plan |
| description | 在 ohmyflight 仓库内编写和执行单文件 plan.md。适用于中大型开发、跨模块重构、生产级验收、工具下线、测试结构整理、架构硬化、恢复演练、评测闭环,以及任何不能靠一次小补丁完成的任务;要求把 plan.md 写成需求、事实、失败测试、目标、设计、任务、验证和收口合一的执行合同。 |
Plan
plan.md 是本仓库中大型任务的单文件执行合同。
它不是草稿,不是聊天纪要,不是只给 agent 自己看的 todo。它同时承担需求文档、当前事实、失败测试、目标、设计、实施任务、验证计划和收口记录。
触发后先做
- 先读根目录
AGENTS.md。
- 涉及代码、测试、spec、构建时,同时读
.agents/skills/ohmyflight-dev/SKILL.md。
- 如果根目录已有
plan.md,先判断它是否属于当前任务;属于则更新,不属于则询问或明确覆盖理由。
- 如果没有
plan.md,以根目录 plan.example.md 为模板创建。
- 写完或更新
plan.md 后再做大改;执行中事实推翻计划时,先更新 plan.md 再继续。
必须保持的边界
- 一个任务只维护一个根目录
plan.md,除非 owner 明确要求多文档。
- 用户输入是线索,不直接写成结论;当前代码、spec、测试、命令输出和用户明确事实才是依据。
- 明确区分已确认事实、用户提供事实、未验证推测、计划事项、已完成并验证事项。
- 文档只写当前事实,不写历史过程、未来计划或未经验证的猜测。
- 不做旧兼容、假过渡、历史残留说明,除非当前任务明确要求。
- checklist 必须随进度更新,不能到最后一次性全勾。
plan.md 标准结构
必须按下面顺序写:
# [任务名] Plan
## 1. 需求文档
## 2. 当前事实
## 3. 失败测试
## 4. 目标
## 5. 不做范围
## 6. 设计
## 7. 实施任务
## 8. 验证计划
## 9. 收口
各章节要求
需求文档 写给 owner 看,说明要解决的实际问题、使用者、体验、范围和业务完成标准;不写实现细节。
当前事实 只写已核实内容,覆盖代码、测试、文档、配置、命令输出、已有能力、缺口和未知点。
失败测试 写清什么会失败,优先自动测试;不能自动化时写静态检查或手动验证路径。
目标 写可观察、可验证、可判定完成或失败的结果。
不做范围 服务边界清晰,不作为逃避交付的借口。
设计 写输入、判断、状态、执行、输出、记录的主链路;模块边界;文件职责;状态归属;数据或事件流;错误、恢复、中断、重试边界;测试和文档影响。
实施任务 是可执行 checklist,每项必须能判断完成或未完成。
验证计划 必须包含相关局部测试、完整验证命令、构建或安装检查、页面/工具入口检查、文档同步检查、未验证内容和剩余风险。
收口 只在任务完成时更新,写目标是否完成、失败测试是否变绿、改了什么、跑了什么验证、未验证内容、剩余风险、是否 commit/push。
完成标准
plan.md 能让 owner 读懂需求和边界。
- 开发者能按设计和任务继续执行。
- 验证者能按验证计划判断完成。
- 收口记录真实反映已完成和已验证事项。
plan.example.md 只作为模板,不替代当前任务的 plan.md。