coding-skills/skills/execute-plan/SKILL.md

name, description

name	description
execute-plan	在新会话中读取用户指定的已确认工程计划，按范围实施、验证、重新核对目标并 review，完成后创建本地 Git 提交。适用于执行已有计划；不用于替代需求讨论或自动扩展改造范围。

执行已确认计划

输入为用户指定的计划文件路径。无需安装其他 skill，也不依赖旧会话。按项目已有方式完成实现，不强制子代理、worktree、固定 TDD 或额外依赖。

开始前

1. 完整读取计划，提取原始目标、已批准行为、保留行为、文件范围、步骤和验收条件。未给路径且无法从本次明确引用确定时询问路径，不猜“最新计划”。
2. 读取目标项目约束、相关代码和测试，核对项目定位、Git 基线与工作区。路径变化时通过仓库身份和内容确认，不仅凭同名目录执行。基线提交变化不必自动阻塞：调查是否影响计划成立的前提；存在实质冲突再澄清。
3. 检查计划的确认状态及依据；缺少批准、存在关键遗漏或当前代码使计划失效时，展示具体缺口并取得澄清。不得把“执行这个未完成的草稿”当作所有隐含决策都已确定，也不对已有有效批准重复索要确认。
4. 记录实施前分支、HEAD（或尚无提交）、暂存、未暂存和未跟踪文件，保留足够的基线信息区分用户已有改动。不能覆盖、回退或替用户提交无关内容。若与任务重叠且无法可靠隔离，先解决冲突。
5. 实施记录默认写在指定计划旁的独立 execution-日期时间.md，包含计划版本、基线、进度和证据，不覆盖已有记录。严格遵循用户指定位置：资产根目录下最多增加一层 <日期-计划主题>/，不插入项目名或系统名目录；用户已指定计划目录时直接使用。该位置必须符合用户的外部资产约定；位置不明时读取 .agent/MEMORY.md 或询问。目录不可用时报告问题，不回退到代码目录，不把资产混入 Git 提交。

每份生成资产顶部使用以下 YAML frontmatter，不使用 HTML 注释：

---
系统: 项目或系统名称
时间: YYYY-MM-DD
目标: 本次计划要达成的目标
---

系统与目标根据所执行计划填写，无法确定的字段留空，不编造；含 YAML 特殊字符的值使用引号。实施记录的时间沿用所依据计划的决策日期，执行时间另记正文；补充计划或新批准版本用用户当地的实际确认日期。纯进度、证据或排版更新不改决策日期。旧计划缺少元数据时，优先从真实确认依据确定日期并记录在新资产中，不擅自改写批准计划；日期无法确定时将时间留空并在正文注明待核实，不用执行当天冒充。元数据缺失本身不等于缺少批准。

若当前会话还保留规划讨论，提醒用户新会话约定；不能假称已经清空上下文。无论宿主是否能识别会话边界，都以计划和重新读取的代码为依据。宿主处于只读或计划模式时遵从限制，不执行变更。

实施边界

• 按计划依赖顺序推进；每项改动必须能解释为完成一个批准任务或验收条件。优先复用代码库、标准库和平台现有能力。
• 根据计划中的文件修改目标、原因和验收要求，自主决定具体实现代码、内部组织和局部实现方式；计划不需要包含详细代码，不因缺少代码而要求用户补齐。核心算法片段用于理解已批准算法约束，可采用满足同一约束的实现，不要求逐字照抄。
• 在批准范围内自主解决实现细节、修复本任务引入的问题，不每一步都索要许可；实现自由度不改变已批准的业务、接口、架构与范围约束。
• 可补充达成已批准目标所必需的测试或配置文件，在实施记录中说明文件、原因及对应验收条件。文件扩展不能成为更改业务行为、公共接口、架构、升级依赖或扩大验收范围的借口。
• 其他未计划的文件改动或实质范围变化，先展示所需变化与原因，取得确认后保存补充计划或新版本，再继续受影响工作。保留原批准版本，不为解释已发生的越界改动而重写计划。
• 发现无关问题时只在记录中注明“本次未处理”；不要顺手重构、清理、格式化整个仓库或修复旁支问题。
• 记录任务进度、必要配套文件、验证命令和结果。恢复会话或上下文压缩后重新读取原计划与实施记录，不从聊天印象续做。

验证与 Review

完成实现后，重新完整读取原计划和原始目标，再检查实际 diff。不能仅根据自己刚写的实现判断完成。

1. 范围：每个变更对应哪项任务或验收；必要配套文件是否有理由；是否存在未批准的业务、接口、架构变化；用户已有内容是否保留。
2. 行为：目标行为是否成立，要求保持的行为是否仍成立，错误路径、兼容性和相关调用方是否受到意外影响。
3. 测试：逐项将验收与回归风险映射到检查。先复用已有测试，再补真实缺口；不添加只复述实现的断言、重复用例或无意义覆盖率要求。对无代码变更任务使用适当的文档或结构检查。
4. 执行证据：运行计划要求和实际改动需要的检查，记录命令、结果及限制；不能把“应当通过”当作已通过。无变化且无新疑点时不反复跑相同测试。
5. 正确性 Review：检查具体实现及暂存前的完整任务 diff，修复范围内问题，修复后重跑受影响检查。若发现本次越界内容，只撤销自己可可靠识别的越界改动；无法隔离时请求澄清，不触碰用户内容。

测试失败时调查原因并修复范围内问题。已有失败、缺失环境或范围外阻碍无法解决时如实报告，不能宣布验收通过或自行绕过检查提交。后续新授权可调整验证要求，但必须记录差异。

本地提交与交付

• 通过上述检查后，只暂存本任务的文件或可隔离片段。不要使用会带入无关内容的批量暂存方式。
• 检查完整暂存 diff，并与初始暂存状态对照。已有用户暂存内容时，必须采用能保持其状态且仅提交本任务的方式；不能隔离则先询问，不创建混合提交。
• 确认 .agent/MEMORY.md、讨论资产和无关文件不在提交中；若 MEMORY 已被跟踪，不自行取消跟踪，先报告冲突。
• 创建一次描述结果的本地 Git commit，遵循项目提交规范；不 push、不 amend 既有提交、不自动跳过 hooks。若 hooks 修改内容，重新检查变化并验证后再提交。
• 读取提交 hash 和提交文件列表，核实仅包含本任务内容，检查工作区剩余变化。提交失败时说明具体原因，不伪造完成状态。
• 若没有差异，报告目标已满足及验证证据，不创建空提交。非 Git 项目说明不能提交，不擅自初始化仓库。未配置身份时不自行修改用户 Git 身份。

最后更新外部实施记录，报告：完成内容、验证证据、必要配套文件与已批准偏差、遗留限制、commit hash（或未提交原因）。