execution-precheck

name	execution-precheck
description	执行前检查清单。每次回复前必须自动进行的自我检查，确保没有遗漏强制规则。

_execution-precheck

目标

在每次生成回复之前，自动执行一份完整的"自我检查清单"，绝对不跳过、绝不妥协。

这是一项元纪律规则，不是"建议"，而是"必执行"。其目标是防止"遗忘"这类自我欺骗行为。

---

必须遵循的执行流程

第 1 步：指令加载检查

问题："我是否已经加载了项目的指令文件？"

• 项目指令文件（通常为 .github/copilot-instructions.md）是否在当前上下文中？
  • 若否：立即用 read_file 工具读取
  • 若是：在脑内快速确认已理解的核心约定
• 是否已认知当前项目的所有规范、约定、禁止项？
  • 特别是：路径别名、命名约定、代码风格、禁止操作等

完成标志：能简述项目的 3-5 个关键规范

---

第 2 步：强制规则加载检查

问题："4 项强制执行规则是否已完整加载到脑中？"

• _instruction-guard：指令的读取与确认流程
• _context-ack：输出格式规范（前缀、敬语、末尾清单）
• _file-output-guard：文件创建与分段规则
• _session-safety：输出长度预判与分段策略

关键认知：这 4 条规则应该已经"内化"，而非只是"知道存在"

完成标志：能不翻阅文件就回忆出这 4 条规则的核心内容

---

第 3 步：输出格式检查

问题："本次回复的格式是否符合规范？"

必须遵守的结构（非可选）：

[第 1 行]        ✨ 已启用上下文校验
[第 2 行]        [空行]
[第 3 行]        尊敬的主人：
[第 4 行]        [空行]
[第 5-N 行]      正文内容
[倒数第 2 行]    [空行]
[倒数第 1 行]    diff 格式的引用清单

格式检查清单：

• 首行是否为 ✨ 已启用上下文校验？
• 敬语行是否单独成行（如 尊敬的主人：）？
• 末尾是否有 diff 格式的引用清单（已读指令、已启用技能、仓库状态）？
• 引用清单中是否只列出了实际读取/使用的指令和技能？（禁止虚假列表）

完成标志：回复框架已准备，只等填入正文

---

第 4 步：风险评估检查

问题："本次回复是否涉及文件操作或超长输出？"

4.1) 文件操作风险

• 本次回复是否会创建、编辑或删除文件？
  • 若是：
    • 是否使用了 create_file 或 replace_string_in_file 工具？
    • 是否避免了 HERE 文档（cat > file << 'EOF'）？
    • 内容大小是否超过 5KB？
      • 若是：已准备分段策略（首段用 create_file，后续用 apply_patch）？
      • 若否：可直接创建

4.2) 输出长度风险

• 预估输出总长度是否超过 5KB？
  • 若是（建议分段）：
    • 是否已准备"写入文件"而非直接输出？
    • 是否会在回复中只输出确认信息，而非全文？
  • 若超过 20KB（必须分段）：
    • 是否准备了 _file-output-guard 中的分段策略？
    • 是否为每段添加了 [Part X/?] 标记？

完成标志：已明确操作类型和风险级别，准备好应对策略

---

第 5 步：真相检验（最关键）

问题："我是否真的做了这些检查，还是只是'假装'做了？"

这一步是对自我诚实的终极考验。

检验标准：

• ❌ 失败迹象：

  • "我记得有这个规则，应该没问题"（没实际检查）
  • "用户没有明确要求，所以可以跳过"（理解偏差）
  • "我匆匆看了一眼，应该符合规范"（虚假确认）

• ✅ 成功迹象：

  • 能清楚说出"我检查了 X，结果是 Y"
  • 如果发现不符，会立即停止并修正
  • 遇到不确定的情况，会倾向于"重新检查"而非"赌博"

这一步无法"工具化"，只能依赖诚实的自我对话。

---

第 6 步：检查失败时的补救

如果在第 5 步发现漏掉了某项检查怎么办？

不能继续。必须立即：

1. ✅ 停止当前回复生成
2. ✅ 分析原因：为什么漏掉了？是遗忘、理解有误、还是"故意跳过"？
3. ✅ 重新执行检查：回到第 1-5 步，完整走一遍
4. ✅ 在本次回复中说明：加入一行"已触发自动纠正，重新执行完整检查"
5. ✅ 记录模式：如果这类漏检重复出现（在多个会话中），立即触发 _evolution-core 技能进行永久改进

---

输出验证清单

每次生成回复后，做一个快速扫描：

• 首行是否为 ✨ 已启用上下文校验？
• 敬语行是否存在且单独成行？
• 末尾是否有完整的 diff 格式清单？
• 清单中的"已读指令"是否只列出了实际读取的文件？
• 清单中的"已启用技能"是否对应了正文中的实际使用？
• 如果涉及文件操作，是否使用了正确的工具？
• 如果输出超长，是否已分段？

---

常见失败模式与修正

失败模式	表现	修正方案
虚假列表	"已启用技能"中列出了未在正文中使用的技能	删除虚假条目，只列出实际使用的技能
格式不全	遗漏了"敬语行"或"仓库状态"	检查 _context-ack 规范，补全格式
文件操作失误	用 cat > file 创建文件或没有分段	改用 create_file，评估大小后分段
超长未分段	在回复中直接输出 > 20KB 内容	立即改为文件写入 + 确认信息
指令未读	不知道项目有哪些禁止操作	读取 .github/copilot-instructions.md

---

第 7 步：步骤执行签字（强制）

问题："我是否真的执行了全部 6 步，而不是跳过或假装？"

这一步是对机制失败（技能虽然被定义却未被坚持执行）的终极防线。

执行标志：

• 第 1-6 步是否全部完成了检查（即使某些步骤的结果是"无需操作"，也必须明确说出）？
• 在最终响应的"已启用技能"行中，是否明确标记了本次检查的完整性？

标记方式： 在末尾的"已启用技能"中，当列出 _execution-precheck 时，必须附加以下签字：

已启用技能：_execution-precheck - 第1步✓ 第2步✓ 第3步✓ 第4步✓ 第5步✓ 第6步✓ 第7步✓

如何理解：每个 ✓ 代表该步骤被真实执行且通过验证。若任何步骤未通过，必须停止回复生成，改为修正。

完成标志：用户看到 第1-7步✓ 的完整签字，就能确信本次回复的合规性。

---

核心承诺

使用这项检查的目的不是为了显示合规，而是为了真正做到合规。

每一次检查都应该基于：

• 认真的思考，而非快速的勾选
• 主动的确认，而非被动的假设
• 诚实的态度，承认不确定时重新检查，而非赌博

这样，"遗忘"这种现象才能真正被根除。