用途：管理 ExecPlan 的生命周期。ExecPlan 是自包含的持续更新文档，存放于 docs/exec-plans/，格式遵循 docs/PLANS.md 的规范，让全新的智能体会话能据此交付可观察、可运行的行为。它不是待办清单，而是讲述一次变更的故事：为何重要、代码现状、目标状态与如何验证。
适用：多步骤或多文件工作、新功能、重构，或预计超过约一小时的任务为必需；琐碎修复可选，但若对重要任务跳过需说明原因；从上一会话恢复工作时始终使用。
三种模式：
一、CREATE：阅读 docs/PLANS.md 获取模板与要求；在 docs/exec-plans/active/{描述性-kebab-名称}.md 创建计划；填写模板全部章节，必须包含 Purpose / Big Picture、Progress、Surprises & Discoveries、Decision Log、Outcomes & Retrospective、Context and Orientation、Plan of Work、Concrete Steps、Validation and Acceptance、Idempotence and Recovery。文件路径须从仓库根写绝对路径，术语须就地定义，开始实现前先提交计划。
二、CONTINUE：读取 active/ 中的计划文件，找到 Progress 中首个未勾选项；开始前检查此前会话的 Surprises 是否影响本任务；按 Plan of Work 执行里程碑；每完成一个里程碑立即更新计划，带时间戳勾选、补充发现与决策日志，并与代码变更一起提交；运行验证命令确认成功。切勿只声称完成而不更新计划文件。
三、COMPLETE：填写 Outcomes & Retrospective（达成与计划对比、剩余缺口、经验教训、意外收益或成本）；用 git mv docs/exec-plans/active/{name}.md docs/exec-plans/completed/{name}.md 移动文件；以 docs: complete exec-plan {name} 提交。
质量检查：提交前确认 Purpose 描述用户可见行为；Progress 完成项带时间戳；Context 用仓库根全路径命名文件；术语就地定义；Validation 含确切命令与预期输出；Recovery 说明各风险步骤回滚；Surprises 保持最新；Decision Log 记录实现中的选择。
反模式：只有清单没有叙事；关键上下文依赖外部引用而非自包含；忘记更新 Progress（最常见失败）；完成后仍留在 active/；跳过验证（“测试通过”不算验收，需给出可观察证据）。
与其他技能集成：涉及 TCA 代码调用 /pfw-composable-architecture；涉及调试调用 debug 技能；涉及重构调用 refactor 技能；涉及 API 设计调用 rest-api-design 技能；全部里程碑完成后调用 refactor 技能做最终清理。暂未提供收费、价格与平台信息。