--- name: project-retrospective description: 项目级 Skill 批量复盘。在一个项目/任务闭环完成后，主动扫描本次对话中调用过的所有 Skill，逐个判断是否需要新建或更新，批量调用 skill-capture-closure 完成沉淀，最后输出复盘报告。触发词：「项目做完了」「更新一下Skill」「基于刚刚的过程更新规范」「做个项目复盘」「沉淀一下经验」「把这次的经验记下来」。 --- # 项目级 Skill 复盘（project-retrospective） > 单次经验用 `skill-capture-closure`（随时触发）。 > 项目结束后的系统性批量复盘用本 Skill（一次扫描全部）。 > 本 Skill 是外壳，`skill-capture-closure` 是内核——扫描由本 Skill 负责，每个具体更新动作仍走 `skill-capture-closure` 标准流程。 --- ## 知识导航表（执行前必须理解的概念根） > 本 Skill 的步骤设计基于以下文档的核心概念。若不理解这些概念，步骤无法正确执行。 | 层级 | 文档 | 需要理解的概念 | |---|---|---| | **D0 认知根（必读）** | `_内部总控/认知结构/L1_系统性文档/系统架构思维维度/自进化智能体系统形式规范_v1.0.md` | 层1：B/K/S三类对象；层2：间隙（Gap）定义；层5：R/M/G基础设施 + M的批量处理逻辑；层7：D_op = {create, modify, delete, merge, split} | | **D3 规范参考** | `_内部总控/认知结构/L1_系统性文档/系统架构思维维度/Skill体系设计原则_v1.0.md` | §2.5 三型决策树（判断新建 Rule/Agent/Skill）；§2.2/2.3/2.4 各类型本质 | | **D4 运行时数据** | `.cursor/skills/skill-index/PENDING-EXPERIENCES.md` + `CO-BUILD-LOG.md` + `SKILL-INDEX.md` | G缓冲区（待处理Gap）+ 过程决策日志 + B-objects 注册表 | **核心概念速查**： ① B-object（行为对象）= Skill/Rule/Agent，编码「在条件C下执行动作A」 ② K-object（知识对象）= 所有文档，编码「什么是真的」 ③ D_op = modify（修复已有）vs create（沉淀新建）—— 批量复盘需同时处理两类 --- ## 激活后立即执行（顺序不可跳过） ``` Step 1 读取 Skill 总索引，了解所有现有 Skill Read: .cursor/skills/skill-index/SKILL-INDEX.md → 获取全量 Skill 列表，用于后续匹配 Step 2 获取「Skill 相关事件」清单（三路来源合并） 【来源一：读取暂存文件（优先，已由 auto-experience-hook 自动积累）】 Read: .cursor/skills/skill-index/PENDING-EXPERIENCES.md → 提取所有「🔲 待处理」条目 → 捕捉：任务中的踩坑/新发现/步骤偏差（结果层） 【来源二：读取协作建设日志（co-build-log 积累的决策轨迹）】 Read: .cursor/skills/skill-index/CO-BUILD-LOG.md → 提取「待处理日志条目」区域的所有条目 → 捕捉：任务中的推理链/决策轨迹/转折理由（过程层） → 重点关注类型 II（方案）和 III（转折）——这是提炼 Skill 的最高价值来源 → 若文件不存在或无条目，跳过 【来源三：补充扫描本次对话上下文（兜底，捕捉两个文件的遗漏）】 回溯整个对话，识别以下信号（排除已在前两路中的条目，避免重复）： 【A. 调用了某个 Skill 且执行顺利】 → 候选：状态升级为 ✅ 已验证（如果原来是 🔵 待验证） 【B. 调用了某个 Skill 但执行有偏差/需要补充步骤】 → 候选：更新该 Skill 的内容（修复/补充） 【C. 遇到了某个场景，但没有合适的 Skill 覆盖，AI 凭感觉执行】 → 候选：新建 Skill（Level 2） 【D. 某个 Skill 的触发词不准（该触发没触发，或错误触发）】 → 候选：更新 description 字段 【E. 架构级发现（系统层面改进，不只是单个 Skill）】 → 以下情况标为 E 类，不走 skill-updater，走 skill-designer 或规范修改流程： E1. AI 行为规律性不符预期，根因不在某个 Skill 的步骤里，需要新建 Rule → 候选：新建 alwaysApply Rule（.cursor/rules/） E1b. 已有 Rule 存在歧义/覆盖范围错误/需要修订 → 候选：更新已有 Rule（走 skill-rule-修改规范） E2. 某类任务因上下文污染导致质量不稳定，子智能体隔离不够，需要新建 → 候选：新建独立子智能体（.cursor/agents/） E2b. 已有 Agent 有设计缺陷/行为错误/描述不准确 → 候选：更新已有 Agent（走 skill-rule-修改规范 Agent 分支） E3. 两个或多个 Skill/Agent/Rule 协作时有系统性摩擦或冲突 → 候选：Level 3 集成型改造（走 skill-designer + 关卡A/B/C） E4. 需要重构多个组件的交互关系 → 候选：Level 4 系统型调整（走 skill-designer 完整八步） E5. 发现某份规范/参考文档（非 .cursor/ 组件）内容有误、遗漏、需补充 → 候选：更新规范文档（走 project-doc-versioning-guard 四步留痕） 覆盖：开发规范手册 / 项目测试规范 / 技术架构文档 / 任何 _内部总控/开发规范/*.md 等 E6. 【结构性设计问题】——AI 反复失败，但根因不是执行疏忽，而是规范/机制本身设计有缺陷 判断标准（满足任一）： ① 同类失败出现 ≥2 次，且每次复盘结论都是「AI 疏忽」 ② 规范只在 Skill 里（被触发才生效），但该规范需要普遍约束 ③ 重要文档/规范没有进入任何 D0 / alwaysApply Rule，AI 靠记忆才知道 ④ 规范表述是「建议/应该」，实际需要「禁止/必须」级别的强制 ⑤ 某个正确做法需要 AI 主动记住，而不是被机制强制 → 候选：根据具体缺陷类型路由 → 连接缺口 → 补 D0 / 新建 Rule（路径③） → 类型错误（Skill→Rule）→ 新建 alwaysApply Rule（路径③） → 规范质量 → 更新规范文档（路径⑦） → 执行力度 → 修改 Rule/Skill 的约束强度（路径⑥） → 将三路来源合并为一张完整清单，标注每条的类别（A/B/C/D/E） Step 3 输出「待处理清单」，等用户确认 格式： 「本次项目系统复盘扫描结果： 📋 Skill 更新类（A/B/C/D，走 skill-updater 路径）： ① [Skill目录名] — [类型] — [一句话说明] ② ... 🏗️ 架构级改进类（E，按子类走不同路径）： ① [改进名称] — [E1/E1b/E2/E2b/E3/E4/E5] — [一句话说明] ② ... ⓪ 无需处理（执行符合预期）：[列表] 说明： - A/B/C/D 类：直接由 skill-updater 子智能体处理（快，无关卡） - E1/E2（新建Rule/Agent）：走 skill-designer Level 2 流程（含关卡A+C） - E1b/E2b（更新已有Rule/Agent）：走 skill-rule-修改规范（三问+备份+修改） - E3（多组件集成）：走 skill-designer Level 3（含关卡A+B+C） - E4（系统重构）：暂停，用户决策后开专题会话 - E5（规范文档）：走 project-doc-versioning-guard 四步留痕（快，无关卡） - E6（结构性设计问题）：先诊断具体缺陷类型，再按连接缺口→③ / 类型错误→③ / 规范质量→⑦ / 执行力度→⑥ 分流 请确认：[全部处理] [只处理Skill更新类] [只处理架构类] [跳过某项]」 → 等用户确认后继续 Step 4 生成本次复盘的 ClosureCase 快照（13态状态机，显式追踪） 创建文件：.cursor/skills/skill-index/closure-case-YYYYMMDD.yaml 内容（状态机来自 user_global_rules_v1 闭环元模型）： case_id: "project-retrospective-[日期]" goal: "本次复盘的目标" # 13态状态机（NEW→NORMALIZED→CONSTRAINED→PLANNED→RUNNING→ # WAITING_CHILDREN→MERGING→VERIFYING→QA_PENDING→ # DONE / BLOCKED / ESCALATED / ARCHIVED） status: "PLANNED" source_of_truth: ".cursor/skills/skill-index/SKILL-INDEX.md" current_stage: "implementation" # context|model|plan|implementation|verification|delivery active_branches: [每个待处理 Skill 一个 branch_id] closed_branches: [] repair_branches: [] # 验证失败后产生的 repair 分支 artifacts: [] acceptance_criteria: - "所有 🔲 待处理条目已处理" - "SKILL-INDEX 已同步更新" - "PENDING-EXPERIENCES 和 CO-BUILD-LOG 已清理" - "所有 repair_branches 已完成或已升级" - "QA 通过（无活动分支，无未解决冲突）" # 递归保护（来自 agent-io-contract.md） recursion_depth: 0 branch_policy: max_children: 10 # 每次复盘最多10个并发 Skill 更新分支 allowed: true escalation_policy: max_depth: 2 escalate_on_block: true owner: "orchestrator" Step 5 按条目类型路由分发处理（串行，A/B/C/D 与 E 类走不同路径） 【路由规则（每条条目必须先判断类型再执行）】 A/B/D 类（更新已有 Skill）→ 路径①：skill-updater 子智能体 C 类（新建独立 Skill，Level 2）→ 路径②：skill-designer Level 2 流程 E1 类（新建 Rule）→ 路径③：skill-designer Level 2 流程（创建 .cursor/rules/） E2 类（新建 Agent）→ 路径③：skill-designer Level 2 流程（创建 .cursor/agents/） E1b 类（更新已有 Rule）→ 路径⑥：skill-rule-修改规范（三问+备份+修改+变更记录） E2b 类（更新已有 Agent）→ 路径⑥：skill-rule-修改规范 Agent 分支（备份到 agents/history/） E3 类（多组件集成改造，Level 3）→ 路径④：skill-designer Level 3 流程（含关卡A+B+C） E4 类（系统重构，Level 4）→ 路径⑤：暂停，向用户确认规模后再执行 E5 类（规范/参考文档更新）→ 路径⑦：project-doc-versioning-guard 四步（读版本→备份→修改→变更记录） E6 类（结构性设计问题）→ 先在 Step 5 内做二次分类，再按缺陷类型路由： · 连接缺口（缺 D0/Rule）→ 路径③（新建 Rule，skill-designer Level 2） · 类型错误（Skill→Rule）→ 路径③（新建 alwaysApply Rule） · 规范质量（表述歧义/覆盖错误）→ 路径⑦（更新规范文档） · 执行力度（建议→禁止）→ 路径⑥（修改已有 Rule/Skill 约束强度） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【路径①：A/B/D 类 → skill-updater（串行，快速）】 a. 明确宣告：「▶ 正在处理 [N/总数]：[Skill目录名] — [类型]（路径①）」 b. 构造统一任务信封（参见 skill-designer/agent-io-contract.md）： task_id / case_id / branch_id / goal / scope / allowed_write_set / done_criteria / recursion_depth: 0 c. 调用 /skill-updater，等待完成 d. 解析输出：pass → 移入 closed_branches；fail → 创建 repair branch ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【路径②③：C/E1/E2 类 → skill-designer Level 2（含关卡A + 关卡C）】 a. 明确宣告：「▶ 正在处理 [N/总数]：[组件名] — [类型]（路径②/③，走 skill-designer）」 b. 加载 skill-designer Skill，传入： - 需要创建的组件类型（Skill / Rule / Agent） - 来自复盘清单的需求描述 - 当前 SKILL-INDEX 摘要 c. skill-designer 走完 Step 3-7（双视角产品定义 → 编写 → 关卡A → 关卡C） d. 通过后由 skill-designer 执行 Step 8（部署） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【路径④：E3 类 → skill-designer Level 3（含关卡A + B + C）】 a. 明确宣告：「▶ 正在处理 [N/总数]：[改进名称] — E3（路径④，Level 3，含关卡B）」 b. 加载 skill-designer Skill，Level 3 完整流程（Step 3-8） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【路径⑥：E1b/E2b 类 → skill-rule-修改规范（更新已有 Rule 或 Agent）】 a. 明确宣告：「▶ 正在处理 [N/总数]：[组件名] — [E1b/E2b]（路径⑥，更新已有组件）」 b. 执行 skill-rule-修改规范 完整流程： - 修改前三问（根因/影响/验证） - 备份：Rule → .cursor/rules/history/ / Agent → .cursor/agents/history/ - 最小化修改 - 追加变更记录 c. 更新 SKILL-INDEX（若 Rule/Agent 在索引中有条目） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【路径⑦：E5 类 → project-doc-versioning-guard（更新规范/参考文档）】 a. 明确宣告：「▶ 正在处理 [N/总数]：[文档名] — E5（路径⑦，更新规范文档）」 b. 执行 project-doc-versioning-guard 四步留痕： 1. Read 文件头部 → 获取当前版本号 2. cp 备份 → [所在目录]/history/[文件名]_v[版本]_YYYYMMDD.md 3. 最小化修改（只改本次经验相关部分） 4. 追加变更记录到文档末尾 c. 本路径无需 skill-updater，主 Agent 直接执行 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【路径⑤：E4 类 → 暂停，用户决策】 a. 输出：「⚠️ 发现 Level 4 系统型调整：[描述] 这将影响多个现有组件，建议开一个专门会话处理。 是否现在开始，还是加入 PENDING-SKILLS 后续规划？」 b. 等待用户决策，不自行启动 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 所有条目处理完后，若有 repair branch，按原路径串行处理 Step 6 输出复盘报告，更新 ClosureCase，清理暂存区 「📊 项目系统复盘完成 Skill 更新（路径①）： ✅ 更新已有 Skill：N 个（含版本升级） ✅ 状态升级：N 个（🔵→✅） 🔧 repair 处理：N 个 架构级改进（路径②③④⑥⑦）： ✅ 新建 Skill（Level 2）：N 个 ✅ 新建 Rule：N 个 ✅ 更新已有 Rule：N 个 ✅ 新建 Agent：N 个 ✅ 更新已有 Agent：N 个 ✅ Level 3 集成改造：N 个 ✅ 更新规范/参考文档：N 个 待后续处理（路径⑤）： 📋 Level 4 系统调整：N 个（已加入 PENDING-SKILLS） ⏭ 跳过：N 个 Skill 体系健康度：共 N 个，✅ X 个已验证，🔵 Y 个待验证」 更新 ClosureCase 快照（closure-case-[日期].yaml）： → status: "closed" → 所有处理完的 branch 移入 closed_branches 清理暂存区（两个文件同步清理）： → PENDING-EXPERIENCES.md：将所有 🔲 待处理 条目标记为 ✅ 已处理，移入归档区 → CO-BUILD-LOG.md：将「待处理日志条目」中已提炼的条目移入「已处理归档」区 ``` --- ## AI 自动判断触发粒度的规则 本规则写在此处，供 AI 在用户说「更新 Skill」类语句时自行判断： ``` 判断逻辑： IF 用户描述了具体的单个踩坑/经验点 → 触发 skill-capture-closure（单次） IF 用户说「项目/任务做完了」「基于整个过程」「全部更新一下」 → 触发 project-retrospective（批量） IF 用户只说「更新 Skill」但上下文是刚完成一个完整项目 → 默认触发 project-retrospective，并在 Step 3 输出清单时让用户确认范围 IF 不确定 → 先问用户：「是针对某个具体经验记录，还是对本次完整项目做系统复盘？」 ``` --- ## 注意事项 - **Step 4 必须串行**：每次只处理一个 Skill，等该 Skill 的变更记录和索引都写完，再处理下一个。并行处理极易导致变更记录写错文件。 - **Step 2 主动扫描，不依赖用户描述**：AI 应从对话历史中自主提取，用户只需最终确认清单，而非重新描述一遍。 - **Step 3 必须等用户确认**：清单可能有误判（AI 认为某个 Skill 需要更新，但用户不认同），必须先对齐再执行。 - **跳过项也要记录**：在索引「变更记录」中追加「[日期] | 项目复盘扫描 | 以下 Skill 确认无需更新：[列表]」，便于追溯。 --- ## 变更记录 ### v1.0 — 2026-03-19 — 初始创建 **触发事件**：沙盘推演发现 `skill-capture-closure` 按「单次经验」设计，无法覆盖「项目结束后批量更新多个 Skill」的场景（漏洞③）。同时发现 AI 在「更新 Skill」触发词下无法自动判断粒度（漏洞①的一部分）。 **经验核心**：需要「外壳+内核」两层结构：`project-retrospective` 负责扫描和批量调度，`skill-capture-closure` 负责每个具体更新动作。触发粒度判断逻辑内置在本 Skill 中。 **修改内容**： - 新增：本 Skill 全部内容（首次创建） **验证状态**：🔵 待验证 --- ### v1.1 — 2026-03-19 — 对接经验自动感知机制 **根因**：新建了 `auto-experience-hook` Rule 和 `PENDING-EXPERIENCES.md` 暂存文件，`project-retrospective` 的 Step 2 需要优先读取暂存文件（而不是从零扫描对话），同时新增 Step 5 的暂存区清理动作。 **经验核心**：暂存文件是经过任务执行中自动感知的高质量草稿，应作为 Step 2 的主要来源；对话扫描作为兜底，避免遗漏。 **修改内容**： - 修改：Step 2 → 改为「两路来源合并」：先读暂存文件，再补充扫描对话 - 修改：Step 5 → 报告完成后，同步清理暂存区（标记已处理并归档） **验证结果**： - 正向验证：有暂存条目时，Step 2 应直接读到草稿，无需 AI 从零扫描对话（待真实场景验证） - 负向验证：无暂存条目时，Step 2 仍走对话扫描兜底，流程不中断（待真实场景验证） **验证状态**：🔵 待验证 --- ### v1.2 — 2026-03-19 — Step 4 改用 skill-updater 子智能体 **根因**：Cursor 2.4/2.5 子智能体功能完整可用。之前 Step 4 是主 Agent 自己处理每条经验，占用主对话 context。改用 skill-updater 子智能体后，每条经验在独立 context 中处理，主 Agent 只看最终摘要，节省 token，且上下文不互相污染。 **经验核心**：「重复、有固定流程、需要独立上下文」的操作，是子智能体的理想使用场景。 **修改内容**： - 修改：Step 4 → 改为调用 `/skill-updater` 前台子智能体，串行传入每条经验草稿，等待返回后再处理下一条 **验证结果**： - 正向验证：skill-updater 接收经验草稿，能正确判断新建/更新并写入文件（待真实场景验证） - 负向验证：主对话 context 不包含子智能体的中间步骤（待验证） **验证状态**：🔵 待验证 --- ### v1.3 — 2026-03-19 — Step 2 加入第三路输入（CO-BUILD-LOG） **根因**：用户提出「协作建设新 Skill 时，过程中的设计意图/AI推理/试错轨迹/转折决策是最有提炼价值的隐性知识，但 PENDING-EXPERIENCES 只捕捉结果，不捕捉过程」。新建了 co-build-log 机制，需要接入 project-retrospective。 **经验核心**：过程日志（推理链/决策轨迹）与结果日志（踩坑/发现）是互补的两层记录，合并后的复盘质量远高于单一来源。 **修改内容**： - 修改：Step 2 → 从「两路来源合并」改为「三路来源合并」：PENDING-EXPERIENCES（结果层）+ CO-BUILD-LOG（过程层）+ 对话扫描（兜底） - 修改：Step 5 清理步骤 → 同步清理 CO-BUILD-LOG 中已处理的条目 **验证结果**： - 正向验证：做复盘时，若有 CO-BUILD-LOG 条目，应出现在待处理清单中（待真实场景验证） - 负向验证：PENDING-EXPERIENCES 的处理逻辑不变，对话扫描兜底逻辑不变 **验证状态**：✅ 已验证（2026-03-19 tashan-openbrain 部署复盘中首次真实执行三路来源合并，CO-BUILD-LOG 条目成功出现在待处理清单中） --- ### v1.4 — 2026-03-19 — 加入 ClosureCase 快照 + repair branch + 统一任务信封 **根因**：对比 closure-orchestration-package 发现三个缺口：①子智能体调用无结构化 I/O（主控无法可靠续跑）；②无显式状态追踪（靠 AI 记忆）；③验证失败无 repair branch 自动回路。 **经验核心**：从「文本流水」到「状态机」的关键一步是：给每个处理单元一个 task_id/case_id/branch_id，给输出一个 gate_recommendation。 **修改内容**： - 新增：Step 4（原 Step 4 后移为 Step 5）→ 生成 ClosureCase 快照文件 - 修改：Step 5（原 Step 4）→ 调用 skill-updater 时使用统一任务信封；解析 gate_recommendation；自动创建 repair branch - 修改：Step 6（原 Step 5）→ 复盘报告加入 repair 统计；更新 ClosureCase 状态为 closed **验证结果**： - 正向验证：下次复盘应生成 closure-case-[日期].yaml（待真实场景验证） - 负向验证：三路来源合并逻辑不变，清理逻辑不变 **验证状态**：✅ 已验证（2026-03-19 tashan-openbrain 复盘：ClosureCase 快照文件已生成，repair branch 机制 ready，统一任务信封格式运行正常） --- ### v1.5 — 2026-03-19 — 加入架构级反思维度 + 路由分发逻辑 **根因**：沙盘推演发现两个结构性漏洞：①扫描维度只有 A/B/C/D（Skill 相关），缺乏 Rule/Agent/编排架构维度；②所有条目统一走 skill-updater，绕过了 skill-designer 的关卡体系。 **修改内容**： - 修改：Step 2 → 新增 E 类扫描维度（E1新建Rule/E2新建Agent/E3集成改造/E4系统重构） - 修改：Step 3 → 清单分为「Skill更新类」和「架构级改进类」两组，说明路径差异 - 修改：Step 5 → 从「统一调 skill-updater」改为「五路路由分发」（路径①②③④⑤） - 修改：Step 6 → 复盘报告加入架构级改进分类统计 **验证结果**： - 正向验证：复盘时若有新建 Rule 需求，应出现 E1 类条目并路由到 skill-designer（待验证） - 负向验证：「更新已有 Skill」类条目仍走 skill-updater 路径①，不受影响 **验证状态**：✅ 已验证（2026-03-19 tashan-openbrain 复盘：E类条目正确识别，五路路由分发机制运行正常） --- ### v1.6 — 2026-03-23 — 新增 E1b/E2b/E5 + 路径⑥⑦（产物类型覆盖修复） **根因**：E 类扫描维度（v1.5新增）中 E1/E2 只有「新建」，无「更新已有Rule/Agent」分支；且无「更新规范/参考文档」（E5）维度。导致复盘时若发现已有 Rule 歧义或规范文档有误，无对应路由。 **修改内容**： - 新增：E1b（更新已有Rule）、E2b（更新已有Agent）、E5（更新规范/参考文档）三种扫描类别 - 新增：路径⑥（E1b/E2b → skill-rule-修改规范，三问+备份+修改+变更记录） - 新增：路径⑦（E5 → project-doc-versioning-guard 四步留痕，快速，无关卡） - 修改：Step 3 清单格式 → 路径说明更新为七路 - 修改：Step 6 复盘报告 → 统计项增加「更新已有Rule/Agent/规范文档」 **备份路径**：`history/SKILL_v1.5_20260323_before_e1b-e2b-e5.md` **验证状态**：🔵 待验证 --- ### v1.7 — 2026-03-23 — 新增 E6（结构性设计问题）扫描维度（元反思层修复） **根因**：同上，project-retrospective 的 E 类扫描维度缺少「结构性根因」诊断——复盘时若发现 AI 反复失败且根因是规范机制设计缺陷（连接缺口/类型错误/执行力度不足等），应被识别为 E6 而非只是「AI 疏忽」 **修改内容**： - 新增：E6 扫描类别（判断标准：同类失败≥2次 / Skill里的规范需要是Rule / 靠AI记忆才知道文档 / 建议语气需要禁止语气 / 靠AI主动记忆） - E6 内含二次分类（连接缺口/类型错误/规范质量/执行力度），各有对应路由 - 路由表和复盘报告统计项同步更新 **备份路径**：`history/SKILL_v1.6_20260323_before_e6.md` **验证状态**：🔵 待验证 --- ### v1.3.1 — 2026-03-23 — 新增知识导航表（D0/D3/D4 + 核心概念速查） **根因**：Skill 只有机械步骤，没有指向背景概念文档。AI 执行时不理解「B-object」「K-object」「D_op」「ceremony」等核心概念的来源（连接缺口）。 **经验核心**：根因 = 连接缺口——核心概念来自自进化智能体系统形式规范，但 Skill 没有指向这些文档。 **修改内容**： - 新增：「知识导航表」章节（D0 认知根 + D3 规范参考 + D4 运行时数据 + 核心概念速查 3 条） **验证状态**：🔵 待验证 **备份路径**：`history/SKILL_v1.3_20260323_before_nav.md`