prompt.md 是一份任务契约文档：目标定义最终必须完成的结果，执行步骤定义建议做法但允许调整；AI 必须以目标是否完成作为唯一完工标准，而不是以“我觉得差不多了”作为结束标准。

结合项目实现，最关键的是这几条：

• 必须有一段“冻结目标”
  • 最稳妥写法是显式 marker：
  • 这是项目优先识别的目标区，见 src/engine/planning.ts:302
• 如果不用 marker，也最好用标准标题
  • 推荐：## 目标
  • 项目还能识别：Goals、不可变目标、最终目标、完成标准、验收标准、Deliverables
  • 见 src/engine/planning.ts:342
• 目标要一行一个，用列表写

  • 推荐用 -

  • 例如：

    • 更新 README 的安装章节
    • 补齐 CLI 示例
    • 为规划模块补充单元测试
• 目标要“结果导向”，不要写成“过程导向”
  • 好：- 为 xxx 增加单元测试
  • 不好：- 看一下测试
• 每个目标要可判断完成与否
  • 好：- README 增加“快速开始”章节
  • 不好：- README 更完善一些
• 执行步骤可以变，目标不要轻易变
  • 因为这个项目会冻结目标，再允许计划继续修正，见 src/engine/planning.ts:68
• 如果你担心目标后续会被改坏，直接用 --frozen-goals-text
  • 这是最高优先级的冻结目标来源，见 src/engine/planning.ts:328

最推荐的写法

这是我建议你长期使用的“AI 最好理解”的模板：

任务名称

定义

这是一份任务契约，而不是普通备注。 你必须把“目标”视为最终交付标准，把“执行步骤”视为可调整的施工计划。 允许优化步骤、顺序和方法，但不允许擅自删除、弱化或改写目标。 只有当所有目标都已实际完成、相关修改已落盘、并完成必要自检后，任务才算完成。 不要把“已分析”“已思考”“已给建议”视为完成，必须以实际交付结果为准。

背景

• 当前项目是什么
• 这次任务为什么要做
• 有哪些已知上下文

工作边界

• 允许修改的范围：
  • src/
  • README.md
  • test/
• 不允许修改的范围：
  • CI 配置
  • 发布流程
• 如无必要，不新增依赖
• 保持现有代码风格

不可变目标

• 完成 README 的安装与快速开始章节更新
• 为 CLI 增加至少一个真实可运行的示例
• 为规划模块补充覆盖冻结目标逻辑的测试

执行步骤

• 先阅读 README、CLI 入口和 planning 相关实现
• 再确定最小修改范围
• 先补文档，再补测试，最后统一自检
• 如发现目标与仓库现状冲突，以目标为准做最小必要调整

输出要求

• 修改应直接落盘到仓库
• 说明中给出关键文件路径
• 如果有取舍，说明原因
• 不要只给建议而不动手

验收标准

• 所有不可变目标都能逐项对账
• 文档内容与实际命令一致
• 新增测试能覆盖对应行为
• 不引入明显的构建或运行错误

补充说明

• 如果发现现有实现与目标冲突，优先满足目标，再在结果里解释

• 如果某项无法完成，明确说明阻塞点和未完成部分