refactor: condense skill workflows and reduce context overhead

skills/execute-plan/SKILL.md

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