--- name: execute-plan description: 在新会话中读取用户指定的已确认工程计划，按范围实施、验证、重新核对目标并 review，完成后创建本地 Git 提交。适用于执行已有计划；不用于替代需求讨论或自动扩展改造范围。 --- # 执行已确认计划 输入为用户指定的计划文件路径。无需安装其他 skill，也不依赖旧会话。按项目已有方式完成实现，不强制子代理、worktree、固定 TDD 或额外依赖。 ## 开始前 1. 完整读取计划，提取原始目标、已批准行为、保留行为、文件范围、步骤和验收条件。未给路径且无法从本次明确引用确定时询问路径，不猜“最新计划”。 2. 从计划定位信息或项目 `.agent/MEMORY.md` 确定系统资产根目录，先读取该目录的 `CONTEXT.md`，再读取目标项目约束、相关代码和测试。只给计划目录且根目录未知时询问，不推断父目录、不扫描历史计划。定位信息互相冲突或 CONTEXT 属于其他系统时先澄清。文件不存在时依靠自包含计划与代码核实，不凭空补系统约束。核对项目定位、Git 基线与工作区；路径变化时通过仓库身份和内容确认，不仅凭同名目录执行。基线提交变化不必自动阻塞：调查是否影响计划成立的前提；存在实质冲突再澄清。 3. 检查计划的确认状态及依据；缺少批准、存在关键遗漏或当前代码使计划失效时，展示具体缺口并取得澄清。不得把“执行这个未完成的草稿”当作所有隐含决策都已确定，也不对已有有效批准重复索要确认。 4. 记录实施前分支、HEAD（或尚无提交）、暂存、未暂存和未跟踪文件，保留足够的基线信息区分用户已有改动。不能覆盖、回退或替用户提交无关内容。若与任务重叠且无法可靠隔离，先解决冲突。 5. 实施记录默认写在指定计划旁的独立 `execution-日期时间.md`，包含计划版本、基线、进度和证据，不覆盖已有记录。严格遵循用户指定位置：资产根目录下最多增加一层 `<日期-计划主题>/`，不插入项目名或系统名目录；用户已指定计划目录时直接使用。该位置必须符合用户的外部资产约定；位置不明时读取 `.agent/MEMORY.md` 或询问。目录不可用时报告问题，不回退到代码目录，不把资产混入 Git 提交。 每份生成资产顶部使用以下 YAML frontmatter，不使用 HTML 注释： ```markdown --- 系统: 项目或系统名称 时间: YYYY-MM-DD 目标: 本次计划要达成的目标 --- ``` 系统与目标根据所执行计划填写，无法确定的字段留空，不编造；含 YAML 特殊字符的值使用引号。实施记录的时间沿用所依据计划的决策日期，执行时间另记正文；补充计划或新批准版本用用户当地的实际确认日期。纯进度、证据或排版更新不改决策日期。旧计划缺少元数据时，优先从真实确认依据确定日期并记录在新资产中，不擅自改写批准计划；日期无法确定时将时间留空并在正文注明待核实，不用执行当天冒充。元数据缺失本身不等于缺少批准。 若当前会话还保留规划讨论，提醒用户新会话约定；不能假称已经清空上下文。无论宿主是否能识别会话边界，都以计划和重新读取的代码为依据。宿主处于只读或计划模式时遵从限制，不执行变更。 ## 系统约束核对与维护 - 对比 CONTEXT 当前约束、待生效约束和计划中的约束快照。无关更新不阻塞执行；计划已明确批准从当前规则迁移到待生效规则时按计划实施。其他实质冲突先展示影响并澄清，不能机械认定文档或计划中某一份总是优先。 - 只记录用户已确认、跨计划适用的业务与设计约束，确认后即可写入根目录 CONTEXT，依赖实施的规则标为“已确认待生效”。agent 自主决定的局部编码细节只属实现，不写成系统约束。 - CONTEXT 按业务约束、设计约束组织，每条只保留约束、适用范围、简短原因和生效状态；不写任务清单、代码、执行日志或完整历史。沿用资产 YAML 格式，目标为“保存系统长期有效的业务与设计约束”，时间为最近一次确认系统决策的日期。 - 本次实施、验证及 review 完成后，才将已落实的待生效约束标为“当前有效”，移除被其替代的失效规则。失败或部分完成时不提前标为有效。更新前重读 CONTEXT，保留其他计划的内容；仅更新生效状态不改决策日期，不改原批准计划。 ## 实施边界 - 按计划依赖顺序推进；每项改动必须能解释为完成一个批准任务或验收条件。优先复用代码库、标准库和平台现有能力。 - 根据计划中的文件修改目标、原因和验收要求，自主决定具体实现代码、内部组织和局部实现方式；计划不需要包含详细代码，不因缺少代码而要求用户补齐。核心算法片段用于理解已批准算法约束，可采用满足同一约束的实现，不要求逐字照抄。 - 在批准范围内自主解决实现细节、修复本任务引入的问题，不每一步都索要许可；实现自由度不改变已批准的业务、接口、架构与范围约束。 - 可补充达成已批准目标所必需的测试或配置文件，在实施记录中说明文件、原因及对应验收条件。文件扩展不能成为更改业务行为、公共接口、架构、升级依赖或扩大验收范围的借口。 - 其他未计划的文件改动或实质范围变化，先将补充计划或新版本写入文件并标为待确认，对话只给变化摘要、原因和文件绝对路径链接，不粘贴全文。用户审阅确认该版本后记录批准，再继续受影响工作。保留原批准版本，不为解释已发生的越界改动而重写计划。 - 发现无关问题时只在记录中注明“本次未处理”；不要顺手重构、清理、格式化整个仓库或修复旁支问题。 - 记录任务进度、必要配套文件、验证命令和结果。恢复会话或上下文压缩后重新读取 CONTEXT、原计划与实施记录，不从聊天印象续做。 ## 验证与 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（或未提交原因）。