版本化执行计划

问题在哪

大模型对话里，上下文窗口一换，聊天记录就没了；真正能跨会话留下来的，往往是仓库里的文件。复杂重构、多 agent 接力、或者中途失败要回溯「上一轮试过什么、为什么放弃」时，如果计划只写在聊天里，后续执行者只能猜。

Execution Plans 把「计划」当成和代码同级的一等产物：版本化、可审查、可归档，而不是用完就扔的草稿。

技能如何工作

技能区分两类计划：

• 轻量计划：单次会话能做完的小改动，在对话里列几步即可，不必落盘。
• 执行计划（exec-plan）：跨窗口/跨会话、可能被打断或需要接力的任务，写到 docs/exec-plans/active/*.md，用 Git 追踪。

一份 exec-plan 通常包含：

• Status：draft / active / blocked / completed
• Goal：一句话描述「做完后世界长什么样」，可验证，不写过程口号
• Scope / Non-goals：明确不做什么，抑制执行期范围膨胀
• Steps：- [ ] 粒度，每步能在单次 PR 或单次工具调用里独立完成并自验
• Decision log：只在有取舍时记录，例如「选 A 因为 X，放弃 B 因为 Y」
• Acceptance criteria：必须能靠命令、测试或截图机械判定，「看起来不错」不算
• Risks：标出已知未知与外部依赖

典型流程：评估是否需要 exec-plan → 创建模板文件并写清目标与步骤骨架 → 拆解到可独立验证的粒度 → 执行中持续勾选步骤、追加决策（不要事后一次性补） → 验收后把文件移动到 completed/（移动而非删除，保留决策史）。多 agent 协作时，同一 exec-plan 文件同一时间只由一个 agent 编辑，交接前先 commit；active/ 目录充当共享协调账本。

与上下游技能的关系：harness-orchestration 识别大任务后触发落盘；步骤执行可对接 harness-verification-loop；收尾可走 harness-commit-gate。

适用边界

• 不必用：单次会话能完成的 typo、纯文档/配置微调；用户明确说「不用写计划」「直接做」；一次性读文件/跑命令。
• 必须用：用户说「先做个计划」「改动比较大」「跨多个会话/多窗口接力」；任务有合理概率被打断或需要多人/多 agent 接力。
• 硬约束：验收标准必须可机械验证；步骤不能写成「实现整个模块」这种无法单 PR 自验的粒度；并发改同一 exec-plan 会导致未保存编辑被丢弃。

计划阶段只产出结构化计划文件，不预写大块实现代码；卡住时标 blocked 并写阻塞原因， abandoned 的中间态不要无声烂在 active/ 里。