refactor: condense skill workflows and reduce context overhead

2026-09-10 11:02:40 +08:00
parent a406fd34e5
commit 39db23b08c
2 changed files with 73 additions and 143 deletions
@@ -1,111 +1,60 @@
 ---
 name: align-plan
-description: 通过代码调查和每轮 1–3 个问题对齐工程目标，纠正错误假设，维护当前决策，并经用户确认生成供新会话执行的计划。适用于需要先讨论需求、改造边界和实现取舍的任务；本 skill 不实施代码。
+description: 通过调查和多轮问答对齐工程目标，生成待审阅计划。用于实施前明确需求、约束与范围；不实施代码。
 ---
 # 对齐目标并生成计划
-产出一份新会话仅凭它和代码库就能实施的计划。调查服务于当前目标；不要把访谈变成遍历所有可能性的设计会议。
+先调查、再决策；产出新会话仅凭计划和代码库即可执行的文件。
-## 资产位置
+## 定位与资产
-1. 先读取项目约束、Git 状态和项目根目录的 `.agent/MEMORY.md`。优先采用用户本次明确指定的资产目录，否则复用 MEMORY 中的 `讨论资产目录`；已有会话中明确指定的位置也有效，不重复询问。
+- 读取项目约束、Git 状态和 `.agent/MEMORY.md`。资产根目录优先用用户本次明确指定位置，否则复用已有定位；没有则在首轮询问，期间可只读调查。
-2. 没有位置时，在首轮 1–3 个问题中询问外部资产根目录。等待期间可只读调查，不自行选择目录或把讨论写进项目代码目录。
+- 根目录默认在代码库外，一目录对应一系统。计划可存于根目录下的 `<日期-计划主题>/`，不插入项目层；已指定计划目录则直接使用。根目录未知时询问，不推断父目录；系统不符或位置冲突先澄清。复用同一计划目录，新计划避免覆盖同名目录。
-3. 用户给出位置后，解析为绝对路径，确认不在当前代码库内；若用户明确要求例外，遵从其选择。确认目录可用后记录到 MEMORY，保留其中其他内容。区分系统资产根目录与本次计划目录；只指定计划目录时保留已知根目录，未知则询问，不把计划目录当根目录或推断其父目录。不可写或路径失效时说明具体问题，请用户提供可用位置，不静默回退。
+- MEMORY 仅记录 `讨论资产目录：<绝对根目录>` 等定位，保留其他内容。写入前检查是否已被 Git 跟踪：已跟踪则先解决冲突，不自行取消跟踪；否则在 `git rev-parse --git-path info/exclude` 中幂等加入 `/.agent/MEMORY.md`，不改共享忽略规则。非 Git 项目说明无法排除。
-4. MEMORY 只保存必要定位信息，例如：
+- 规划只写讨论资产及必要定位信息。目录不可用或宿主禁止写入时报告，不回退代码目录、不宣称已保存。
-   ```markdown
+所有生成资产（含 MEMORY）以此 YAML 开头，未知字段留空，特殊值加引号：
 ```yaml
 ---
-   系统: 项目或系统名称
+系统: 系统名称
 时间: YYYY-MM-DD
-   目标: 保存讨论资产位置
+目标: 资产对应目标
 ---
   ## 讨论资产
   - 讨论资产目录：/用户指定的系统资产根目录
 ```
-   写入前检查 MEMORY 是否被 Git 跟踪；已跟踪则说明与“不提交本地记忆”的冲突，先解决冲突，不自行取消跟踪。未跟踪时在 `git rev-parse --git-path info/exclude` 指向的本地排除文件中幂等加入 `/.agent/MEMORY.md`，不改共享 `.gitignore`。非 Git 项目仍保留本地记忆，并说明当前无法设置 Git 排除。
+时间使用用户当地决策日期；草稿先记创建日期、确认后更新。批准版本保留日期，进度、排版及生效状态变化不改日期。
 5. 严格使用用户指定目录作为资产根目录，可直接在其中建立 `<日期-计划主题>/`，不再插入项目名、系统名等中间目录。若用户已指定本次计划目录，直接使用，不再次嵌套。恢复同一计划时复用已有目录；新计划名称冲突时只调整计划目录名，不覆盖其他计划。核心文件为 `current.md` 和先写入待确认内容的 `plan-v1.md`；用户审阅确认后冻结该版本，后续版本另存，不覆盖旧批准版本。
-每份生成资产（当前决策、计划、实施记录及其他讨论文档，包括 MEMORY）顶部使用下方模板中的 YAML frontmatter，按顺序包含 `系统`、`时间`、`目标`，不使用 HTML 注释。系统填写项目或系统名称，目标用一句话概括该资产对应的目标；无法确定的字段留空，不编造。时间采用用户当地的 `YYYY-MM-DD` 日期，表示该资产所依据决策的日期；尚无确认决策的草稿先记创建日期，正文仍标记待确认。确认或新决策改变当前资产内容时更新日期；纯排版、补证据或执行进度更新不改变决策日期。已批准计划保留原日期，新版本记录新确认日期；实施记录使用其所依据的计划决策日期。字段值包含 YAML 特殊字符时使用引号，保证元数据可解析。
+## 系统约束与讨论状态
-宿主限制写入时，遵从限制，在对话中维护当前状态并明确尚未落盘；不要把未保存资产说成已保存。资产维护是规划阶段唯一的写入范围，不能开始项目实现。
+先读根目录 `CONTEXT.md`，再调查相关代码；不扫描历史计划。首次无 CONTEXT 时，从首条已确认长期约束开始创建。
-## 跨计划系统约束
+- `CONTEXT.md`：按业务、设计约束记录规则、适用范围、简短原因及状态。用户确认即更新；无需实施的规则为“当前有效”，依赖改造的为“已确认待生效”，可附计划位置。待生效规则不替代当前规则；冲突先展示影响并确认，生效后才移除失效规则。不放任务、代码、日志或局部实现偏好。目标为“保存系统长期有效的业务与设计约束”，时间为最近确认决策日期。
 - `<计划目录>/current.md`：每轮吸收回答后更新原始及当前目标、验收、确认决策与原因、事实来源、约束、不做事项、未确认假设和问题。替换失效决定，仅留必要的否决原因，不累计聊天全文。
 - 新会话、压缩恢复或出现矛盾时重读 CONTEXT、当前状态和相关代码；其余时候复用无变化内容。确认状态以真实回答为准，沉默和推荐都不算批准。
-确定资产根目录后，先读取 `<资产根目录>/CONTEXT.md`，再针对当前目标调查代码。新会话及上下文恢复时同样读取，不通过遍历历史计划恢复系统约束。文档不能替代对本次相关代码的核实。默认一个根目录对应一个系统；已有 CONTEXT 属于其他系统时先澄清，不混写或另建项目层级。
+## 调查与提问
- 没有 CONTEXT 时可继续调查，在首次有已确认的长期约束时创建，不扫描历史计划补齐、不凭推测编写。
+- 先查相关代码、调用链和测试。仅为当前决策查证开源实现或官方资料，保留来源和必要版本；无法查证的事实标为待验证。
- 用户确认长期业务决策、业务约束或设计约束后立即更新，不等整份计划结束。未确认建议、假设和当前任务的问题留在 `current.md`。
+- 每轮共 1–3 个影响目标、验收或取舍的问题，不能用子问题变相扩充。可查事实不问用户，依赖未决答案的问题后置；有提问工具则使用，否则直接问。
- 正文按“业务约束”和“设计约束”组织；每条记录约束、适用范围、简短原因及状态。无需实施即可成立的规则标为“当前有效”；依赖尚未完成改造的规则标为“已确认待生效”，可附对应计划位置。
+- 简述证据与推荐理由，不用装饰性 emoji。纠正错误事实，区分假设与偏好；用户提出想法不等于确认方案。
- 待生效的新规则不替代当前有效规则。新决策与现有约束冲突时，展示差异和影响，由用户确认保留、修订或替代；决策真正生效后再移除失效规则，避免并存矛盾。
+- 优先复用现有能力，选择满足目标的最小方案。出现独立子目标或明显扩大的改造时，说明扩大点、建议分阶段，由用户选择；未确认前保持原范围。
- CONTEXT 自身必须可独立理解，不放聊天、任务清单、详细代码、测试日志或完整决策历史。仅保留当前需要的约束与原因，不能把局部实现偏好提升为系统规则。
+- 目标、边界、关键取舍和验收明确后停止提问。
 - 顶部沿用 `系统`、`时间`、`目标` YAML 元数据；目标为“保存系统长期有效的业务与设计约束”。时间记录最近一次确认系统决策的日期，仅更新生效状态时不改日期。
-## 调查与问答
+## 写入、审阅与交接
- 先读相关代码、调用链、现有测试与项目约束，再提出问题。需要外部证据时，针对影响当前决策的开源实现或官方资料查证，记录链接、版本或提交以及相关结论；不进行无边界的生态调研。无法查证的内容标记为待验证。
+先写 `<计划目录>/plan-v1.md`，标为“待确认”。正文自包含，可合并章节，但须有：
 - 每轮提问共 1–3 个，只问影响目标、验收或实现选择的问题。能从环境查明的事实自己查。需要先前答案的问题留到下一轮；不要用一个问题包装大量独立子问题。
 - 提问前给出必要的调查结论；存在真实取舍时给出简短选项、推荐及原因。使用宿主的提问工具（若可用），否则直接提问；不依赖特定工具，不使用装饰性 emoji。
 - 对用户的判断区分事实、假设与偏好。事实有误时指出冲突证据、影响和替代建议；证据不足则说明不确定性。尊重明确的偏好，不为反驳而反驳，也不把用户提出的想法自动视作已批准方案。
 - 优先复用现有能力、标准库和平台机制，选择满足已确认目标的最小实现。不用“简化”省略用户要求或必要的正确性保障。
 - 新想法先核对当前目标。若出现多个可独立交付的目标、跨子系统的大幅改造，或明显超出原验收条件，说明扩大点，提出分阶段建议并让用户选择。未确认前保留原目标，旁支放入范围外事项。
-## 当前决策是状态
+1. **定位**：项目及必要仓库标识、资产根目录与 CONTEXT 绝对路径、Git 基线（无提交则注明）、相关工作区变化、版本与确认状态/依据。
 2. **目标与决策**：原始目标、当前/目标行为、保留行为、不做事项；决策理由、业务/接口/架构变化或不变；相关系统约束快照及状态、已确认假设。
 3. **修改范围**：新增/修改/删除的文件、各自目标和原因、必要依赖顺序及对应验收。允许必要测试/配置配套文件并记录，其他范围变化重新确认。
 4. **验证**：验收条件、对应测试、运行目录/命令/预期结果与必要环境。
-每轮吸收回答后更新 `current.md`，保持简短、可独立理解；下一轮基于它和新证据提问。包含：
+不预写详细实现代码；仅核心算法可附少量审查片段，执行 agent 可自主选择满足已批准约束的实现。
- 原始目标与当前已确认目标；目标改变时保留改变原因。
+写完重读，检查遗漏、矛盾及隐含决策；缺关键决定则继续提问。确认文件可读后，对话只给目标、范围、重要影响与验证摘要，以及文件绝对路径链接，供用户阅读确认；除非用户要求，不贴全文。
 - 验收条件、已确认决策及简短理由。
 - 已查明事实及来源；尚待确认的建议或假设单独列出。
 - 约束、保留行为、不做事项、未决问题。
-用新决定替换已失效决定；被否决方案只保留防止重提所需的一句原因，不累积聊天全文。用户未回答、沉默或模型自己的推荐都不算确认。恢复会话、上下文压缩或出现矛盾时，重新读取 CONTEXT、当前决策和相关代码；不能从压缩摘要猜测确认状态。
+用户确认该文件当前版本后，记录批准依据及日期并冻结。反馈先修改待确认文件，再给变化摘要与链接；已批准版本的实质修订另存待确认新版本。写入或摘要不代表批准。
-## 收敛、确认与交接
+确认后给出新会话提示：`使用 execute-plan 执行 /绝对路径/plan-v1.md`，结束规划。不要自动实施或声称已清空上下文。
 当目标、边界、关键实现选择和验收都明确，且没有影响实施的未决问题时停止提问。不为凑问题继续访谈。
 先将完整候选计划写入计划文件，状态标为“待确认”，供用户自行打开审阅；不等确认后才落盘，也不在对话中粘贴全文。计划以文件的修改目标、原因和验收要求为主，不写完整函数、逐行补丁或详细实现代码。仅当核心算法需要代码帮助用户审查时，保留少量代码或伪代码片段，并说明其表达的算法约束；片段不是必须照抄的实现。具体编码、内部组织等细节交给执行 agent 在已批准边界内决策，不把缺少详细代码当作计划未完成。
 计划至少包含以下信息，简单任务可合并段落，不填充无意义章节：
 ```markdown
 ---
 系统: 项目或系统名称
 时间: YYYY-MM-DD
 目标: 本次计划要达成的目标
 ---
 # 任务名称
 ## 定位与确认
 - 项目：仓库绝对路径；有远程时附仓库标识
 - 资产根目录与 CONTEXT.md 的绝对路径
 - 基线：分支、提交；无初始提交则明确注明
 - 工作区：与计划相关的未提交变化
 - 版本：v1；状态：待确认 / 已确认；确认日期与确认依据
 ## 目标与边界
 原始目标、当前行为、目标行为、保留行为、不做事项。
 ## 决策与影响
 已确认选择及原因；业务行为、公共接口、架构的前后变化。
 无变化的类别明确注明；必要事实来源；已确认的假设。
 保留本次相关的系统约束快照及生效状态，不能只给 CONTEXT 链接。
 ## 文件与步骤
 预计新增、修改、删除的仓库相对路径、修改目标与原因。
 按必要依赖顺序列目标级任务，每项关联验收条件，不预写详细代码。
 允许为已批准目标补充必要测试或配置文件，须记录理由；
 其他范围扩展、业务行为、公共接口或架构变化需重新确认。
 ## 验收与验证
 可判定的验收条件；对应现有或待补测试、运行目录、命令与预期结果。
 必要环境和依赖；无法验证的部分不能伪装为通过。
 ```
 写入后重新读取文件自查：新会话是否还需要聊天历史才能理解，是否有占位符、互相矛盾的决定、漏写的文件目的或隐含的业务变化。修复事实遗漏；涉及新决策则回到提问。确认保存成功后，对话只提供简短摘要（目标、主要改动范围、重要影响与验证方式）、计划文件的绝对路径链接和待确认状态，提示用户阅读文件后确认。除非用户明确要求，不重复展示完整计划。文件不可写或宿主禁止落盘时如实说明，不宣称已保存或以全文刷屏代替文件。
 用户确认所链接文件的当前版本后，更新该文件的状态、确认日期及真实确认依据，冻结已审阅的内容；摘要或写入成功不等于批准。用户要求修改时，先修改待确认文件，再给变化摘要与链接供审阅；已批准计划的实质变化必须另存待确认的新版本，不覆盖旧版本或夹入未审阅的新内容。最终计划必须自包含，不要求执行者继续读取访谈记录。
 提供已保存计划的绝对路径，以及新会话提示词：`使用 execute-plan 执行 /绝对路径/plan-v1.md`。结束本次规划，不自动调用执行 skill。新会话是使用约定，不能声称已替用户清空上下文。
@@ -1,70 +1,51 @@
 ---
 name: execute-plan
-description: 在新会话中读取用户指定的已确认工程计划，按范围实施、验证、重新核对目标并 review，完成后创建本地 Git 提交。适用于执行已有计划；不用于替代需求讨论或自动扩展改造范围。
+description: 执行用户指定的已批准工程计划，验证目标与范围并完成本地 Git 提交。用于已有计划的实施。
 ---
 # 执行已确认计划
-输入为用户指定的计划文件路径。无需安装其他 skill，也不依赖旧会话。按项目已有方式完成实现，不强制子代理、worktree、固定 TDD 或额外依赖。
+在新会话按计划实施；不依赖旧讨论，也不强制子代理、worktree、TDD 或新依赖。
-## 开始前
+## 读取与核对
-1. 完整读取计划，提取原始目标、已批准行为、保留行为、文件范围、步骤和验收条件。未给路径且无法从本次明确引用确定时询问路径，不猜“最新计划”。
+1. 完整读取用户指定计划；路径不明则询问，不猜最新文件。从计划定位或 `.agent/MEMORY.md` 确定资产根目录，读取根目录 `CONTEXT.md`，再核实项目约束、相关代码和测试。不推断根目录、不扫描历史计划；定位冲突或系统不符先澄清。无 CONTEXT 时依靠计划与代码，不编造约束。
-2. 从计划定位信息或项目 `.agent/MEMORY.md` 确定系统资产根目录，先读取该目录的 `CONTEXT.md`，再读取目标项目约束、相关代码和测试。只给计划目录且根目录未知时询问，不推断父目录、不扫描历史计划。定位信息互相冲突或 CONTEXT 属于其他系统时先澄清。文件不存在时依靠自包含计划与代码核实，不凭空补系统约束。核对项目定位、Git 基线与工作区；路径变化时通过仓库身份和内容确认，不仅凭同名目录执行。基线提交变化不必自动阻塞：调查是否影响计划成立的前提；存在实质冲突再澄清。
+2. 核对计划批准依据、目标、范围与验收。基线变化先调查影响，无关更新不阻塞；关键缺口、未批准或实质冲突先澄清。已批准的规则迁移按计划执行，不因仍有旧规则重复确认。
-3. 检查计划的确认状态及依据；缺少批准、存在关键遗漏或当前代码使计划失效时，展示具体缺口并取得澄清。不得把“执行这个未完成的草稿”当作所有隐含决策都已确定，也不对已有有效批准重复索要确认。
+3. 记录仓库身份、分支、HEAD（或无提交）及暂存/未暂存/未跟踪状态，足以区分用户已有修改。保护用户内容；重叠且不能隔离时先解决，不回退或混合提交。
 4. 记录实施前分支、HEAD（或尚无提交）、暂存、未暂存和未跟踪文件，保留足够的基线信息区分用户已有改动。不能覆盖、回退或替用户提交无关内容。若与任务重叠且无法可靠隔离，先解决冲突。
 5. 实施记录默认写在指定计划旁的独立 `execution-日期时间.md`，包含计划版本、基线、进度和证据，不覆盖已有记录。严格遵循用户指定位置：资产根目录下最多增加一层 `<日期-计划主题>/`，不插入项目名或系统名目录；用户已指定计划目录时直接使用。该位置必须符合用户的外部资产约定；位置不明时读取 `.agent/MEMORY.md` 或询问。目录不可用时报告问题，不回退到代码目录，不把资产混入 Git 提交。
-每份生成资产顶部使用以下 YAML frontmatter，不使用 HTML 注释：
+宿主禁止实施时遵从限制；新会话是使用约定，不能假称清空了上下文。
-```markdown
+## 资产与上下文
 执行记录放在计划旁的独立 `execution-日期时间.md`。沿用用户指定位置，根目录下最多一层计划目录，不插入项目层。目录不可用时报告，不回退代码库。
 生成资产使用以下 YAML；未知字段留空，特殊值加引号：
 ```yaml
 ---
-系统: 项目或系统名称
+系统: 系统名称
 时间: YYYY-MM-DD
-目标: 本次计划要达成的目标
+目标: 资产对应目标
 ---
 ```
-系统与目标根据所执行计划填写，无法确定的字段留空，不编造；含 YAML 特殊字符的值使用引号。实施记录的时间沿用所依据计划的决策日期，执行时间另记正文；补充计划或新批准版本用用户当地的实际确认日期。纯进度、证据或排版更新不改决策日期。旧计划缺少元数据时，优先从真实确认依据确定日期并记录在新资产中，不擅自改写批准计划；日期无法确定时将时间留空并在正文注明待核实，不用执行当天冒充。元数据缺失本身不等于缺少批准。
+执行记录沿用计划决策日期，执行时间另记正文；新批准版本用用户当地确认日期。进度与排版不改日期；旧元数据缺失不等于缺少批准，不编造日期或改写原批准内容。
-若当前会话还保留规划讨论，提醒用户新会话约定；不能假称已经清空上下文。无论宿主是否能识别会话边界，都以计划和重新读取的代码为依据。宿主处于只读或计划模式时遵从限制，不执行变更。
+- CONTEXT 只沉淀已确认的跨计划业务/设计规则、适用范围、简短原因及状态；确认即记，依赖实施的标“已确认待生效”，其他为“当前有效”。不放任务、代码、日志或 agent 自选的局部实现。目标为“保存系统长期有效的业务与设计约束”，时间为最近确认决策日期。
-
+- 对照 CONTEXT 与计划快照：无关更新继续，其他实质冲突展示影响并澄清。实施、验证及 review 完成后，重读 CONTEXT，仅将本次落实的约束改为有效并移除其替代的失效规则，保留其他计划内容；失败或部分完成不提前生效，状态更新不改决策日期。
-## 系统约束核对与维护
+- 执行记录仅保留任务状态、配套文件及理由、关键验证命令/结果、阻塞与偏差，不粘贴完整工具日志。恢复会话或压缩后重读 CONTEXT、计划和执行状态；无变化时复用已读内容。
 - 对比 CONTEXT 当前约束、待生效约束和计划中的约束快照。无关更新不阻塞执行；计划已明确批准从当前规则迁移到待生效规则时按计划实施。其他实质冲突先展示影响并澄清，不能机械认定文档或计划中某一份总是优先。
 - 只记录用户已确认、跨计划适用的业务与设计约束，确认后即可写入根目录 CONTEXT，依赖实施的规则标为“已确认待生效”。agent 自主决定的局部编码细节只属实现，不写成系统约束。
 - CONTEXT 按业务约束、设计约束组织，每条只保留约束、适用范围、简短原因和生效状态；不写任务清单、代码、执行日志或完整历史。沿用资产 YAML 格式，目标为“保存系统长期有效的业务与设计约束”，时间为最近一次确认系统决策的日期。
 - 本次实施、验证及 review 完成后，才将已落实的待生效约束标为“当前有效”，移除被其替代的失效规则。失败或部分完成时不提前标为有效。更新前重读 CONTEXT，保留其他计划的内容；仅更新生效状态不改决策日期，不改原批准计划。
 ## 实施边界
- 按计划依赖顺序推进；每项改动必须能解释为完成一个批准任务或验收条件。优先复用代码库、标准库和平台现有能力。
+- 每项改动对应批准任务或验收；优先复用现有能力，自主决定具体代码及内部组织，不要求计划提供详细代码或逐字照抄算法示例。
- 根据计划中的文件修改目标、原因和验收要求，自主决定具体实现代码、内部组织和局部实现方式；计划不需要包含详细代码，不因缺少代码而要求用户补齐。核心算法片段用于理解已批准算法约束，可采用满足同一约束的实现，不要求逐字照抄。
+- 可补必要测试/配置文件并说明对应验收；其他文件扩展、业务/接口/架构变化或依赖升级须先确认，不能包装为配套改动。无关发现只记录，不顺手修复或重构。
- 在批准范围内自主解决实现细节、修复本任务引入的问题，不每一步都索要许可；实现自由度不改变已批准的业务、接口、架构与范围约束。
+- 需变更范围时先将补充计划或新版本写入文件并标待确认，对话只给变化摘要、原因及绝对路径链接。用户审阅批准后继续；不覆盖原批准计划。
 - 可补充达成已批准目标所必需的测试或配置文件，在实施记录中说明文件、原因及对应验收条件。文件扩展不能成为更改业务行为、公共接口、架构、升级依赖或扩大验收范围的借口。
 - 其他未计划的文件改动或实质范围变化，先将补充计划或新版本写入文件并标为待确认，对话只给变化摘要、原因和文件绝对路径链接，不粘贴全文。用户审阅确认该版本后记录批准，再继续受影响工作。保留原批准版本，不为解释已发生的越界改动而重写计划。
 - 发现无关问题时只在记录中注明“本次未处理”；不要顺手重构、清理、格式化整个仓库或修复旁支问题。
 - 记录任务进度、必要配套文件、验证命令和结果。恢复会话或上下文压缩后重新读取 CONTEXT、原计划与实施记录，不从聊天印象续做。
-## 验证与 Review
+## 验证、Review 与提交
-完成实现后，重新完整读取原计划和原始目标，再检查实际 diff。不能仅根据自己刚写的实现判断完成。
+1. 完成后重新完整读取原目标与批准计划，对照任务 diff：验收是否满足、保留行为是否成立、是否越界、是否影响调用方与错误路径。
-
+2. 运行计划要求及改动必要的检查，覆盖验收与回归风险。复用已有测试，补真实缺口，不堆重复用例或强制覆盖率；文档变更用适当结构检查。记录实际证据，无变化且无新疑点时不重复运行。
-1. **范围**：每个变更对应哪项任务或验收；必要配套文件是否有理由；是否存在未批准的业务、接口、架构变化；用户已有内容是否保留。
+3. Review 范围与正确性，修复本任务问题后重跑受影响检查。越界内容仅撤销能可靠隔离的自身改动。未解决失败或环境阻碍如实报告，不宣称通过、不绕过检查提交；用户调整验证要求时记录差异。
-2. **行为**：目标行为是否成立，要求保持的行为是否仍成立，错误路径、兼容性和相关调用方是否受到意外影响。
+4. 仅暂存本任务文件/片段，检查完整暂存 diff，确保不含用户原有改动、MEMORY 或讨论资产。无法隔离或 MEMORY 已被跟踪时先解决，不擅自取消跟踪。
-3. **测试**：逐项将验收与回归风险映射到检查。先复用已有测试，再补真实缺口；不添加只复述实现的断言、重复用例或无意义覆盖率要求。对无代码变更任务使用适当的文档或结构检查。
+5. 按项目规范创建本地 commit；不 push、amend、跳过 hooks 或改 Git 身份。Hook 改动须重新检查验证。无差异不空提交，非 Git 项目不自行初始化；提交失败报告原因。
-4. **执行证据**：运行计划要求和实际改动需要的检查，记录命令、结果及限制；不能把“应当通过”当作已通过。无变化且无新疑点时不反复跑相同测试。
+6. 核实 commit hash、提交文件及工作区残余，更新外部记录；简报交付、验证、配套变化/批准偏差、限制及 hash（或未提交原因）。
 5. **正确性 Review**：检查具体实现及暂存前的完整任务 diff，修复范围内问题，修复后重跑受影响检查。若发现本次越界内容，只撤销自己可可靠识别的越界改动；无法隔离时请求澄清，不触碰用户内容。
 测试失败时调查原因并修复范围内问题。已有失败、缺失环境或范围外阻碍无法解决时如实报告，不能宣布验收通过或自行绕过检查提交。后续新授权可调整验证要求，但必须记录差异。
 ## 本地提交与交付
 - 通过上述检查后，只暂存本任务的文件或可隔离片段。不要使用会带入无关内容的批量暂存方式。
 - 检查完整暂存 diff，并与初始暂存状态对照。已有用户暂存内容时，必须采用能保持其状态且仅提交本任务的方式；不能隔离则先询问，不创建混合提交。
 - 确认 `.agent/MEMORY.md`、讨论资产和无关文件不在提交中；若 MEMORY 已被跟踪，不自行取消跟踪，先报告冲突。
 - 创建一次描述结果的本地 Git commit，遵循项目提交规范；不 push、不 amend 既有提交、不自动跳过 hooks。若 hooks 修改内容，重新检查变化并验证后再提交。
 - 读取提交 hash 和提交文件列表，核实仅包含本任务内容，检查工作区剩余变化。提交失败时说明具体原因，不伪造完成状态。
 - 若没有差异，报告目标已满足及验证证据，不创建空提交。非 Git 项目说明不能提交，不擅自初始化仓库。未配置身份时不自行修改用户 Git 身份。
 最后更新外部实施记录，报告：完成内容、验证证据、必要配套文件与已批准偏差、遗留限制、commit hash（或未提交原因）。