| 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 中。
修改内容：
验证状态：🔵 待验证
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
