Luban Skill

鲁班.Skill

天工开物 工匠鲁班

---

设计哲学

autoresearch + SkillOpt 场景自适应。

12 条原则

1. 单一可编辑资产：每次只改一个 SKILL.md
2. 双重评估：结构评分（静态分析）+ 效果验证（实际跑测试看输出）
3. 棘轮机制：只保留改进，自动回滚退步
4. 独立评分：评分用子 agent，消除「自己改自己评」的偏差
5. 人在回路：每个 skill 优化完暂停，用户确认再继续
6. 文本学习率预算：每次编辑字符变化量 ≤ 原文件 10%
7. 拒绝编辑缓冲区：被回滚的方案留作负反馈，后续绕行
8. Epoch Meta-Review：跨 skill 汇总优化规律，沉淀可迁移经验
9. 场景自适应双模：Quick（轻量 Self-Refine）/ Full（完整循环 + 仪表盘监控）
10. ROI 前置评估：基线分 ≥85 且最低维度分 ≥7 跳过（天花板已近）
11. 消费者能力基线：Full 模式先测目标模型裸能力，低于阈值直接阻断
12. 全链路审计：Full 模式所有操作记录 git commit 可追溯

路径约定

• luban-workspace = 本 SKILL.md 所在目录（即本 skill 目录本身是一个 git 仓库）
• skills 目录 = 父目录
• 分支命名 auto-optimize/YYYYMMDD-HHMM
• 被优化技能的数据文件（diagnostics.tsv / rejected_edits.md / test-prompts.json / results.tsv）放在被优化 skill 自己的目录下
• 鲁班全局文件（meta_learnings.md / luban-profile.json / optimization-registry.tsv）放在 luban-workspace/

架构底座：L0-L4 分层治理

5 个正交层级，按场景模式动态激活：

L0 原子操作（所有编辑必须走这三步）：

1. 读：read_text 读取目标 SKILL.md 全文
2. 改：edit_file 执行编辑（Quick 模式直接用 .bak 备份；Full 模式先 git commit 暂存）
3. 验：按 Rubric 逐项自检本次改动影响的维度（dim1/4/7a/9 按评分标准逐条核对，dim2/3/5 通读确认未引入新问题），不通过则回退

---

📋 阅读导航

---

📍 你在这里: 鲁班.Skill > 评估 Rubric

评估 Rubric（10 维度，总分 100）

SkillLens（arXiv 2605.23899）实证 LLM-as-judge 准确率仅 46.4%，加入 meta-skill 三维度后提升到 73.8%。

评分类型

权重和：7+12+12+6+17+4+12+20+6+4 = 100。确定性维度覆盖 25/100=25%，LLM 承担 71 分，dim10 公式计算 4 分。

评分公式

维度总分 = Module 子分 + Rubric 子分（同维占比加权合并）。dim5/dim6/dim7b/dim10 四维有模块介入，其余维度仅 Rubric。

加权原始分 = (dim1×7 + dim2×12 + dim3×12 + dim4×6 + dim5×17 + dim6×4 + dim7a×6 + dim7b×6 + dim8×20 + dim9×6 + dim10×4) / 10

架构总览

                          ┌──────────────────────────────────────┐
                          │      鲁班.Skill 技能自进化调度器       │
                          │   事件驱动 + 定时轮询 + 按需触发       │
                          └────────────────┬─────────────────────┘
                                           │
              ┌────────────────────────────┼────────────────────────────┐
              │                            │                            │
    ┌─────────┴──────────┐      ┌─────────┴──────────┐      ┌─────────┴────────────┐
    │   模块层（缺陷检测）   │    │ 核心引擎（评分+修复）│      │   事件钩子（旁路）    │
    │ SkillOps 定期体检   │      │                    │      │  编辑完成 → MUSE 回归 │
    │ EvoSkill 失败驱动   │ 子分 │  Phase 0   初始化   │      │  错误反馈 → EvoSkill  │
    │ HASP     规则硬化   │───→  │  Phase 0.3 模块检测 │      │  规则连续忽略 → HASP  │
    │ CASCADE  知识更新   │      │  🔴 CHECKPOINT     │      └──────────────────────┘
    │ Distill  精简瘦身   │      │  Runtime Gate      │
    │ Sentinel  安全审计  │      │  Phase 0.5 测试设计 │
    └────────────────────┘      │  🔴 CHECKPOINT     │
              │                 │  Phase 1  基线评估 │
              │                 │  🔴 CHECKPOINT     │
              │                 │  Phase 2  优化循环 │
              │                 │  Phase 2.5探索重写 │
              │                 │  Phase 3  汇总报告  │
              │                 └─────────┬──────────┘
              │                           │
              │      diagnostics.tsv      │   results.tsv
              │      (模块子分清单)        │   (评分+优化记录)
              │                           │
              └─────────────┬─────────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │    技能文件仓库      │
                 │  SKILL.md           │
                 │  references/        │
                 │  tests.yaml         │
                 │  test-prompts.json  │
                 └─────────────────────┘

dry_run 降权规则

dry_run 模式下确定性维度不受影响；LLM 维度处理：

反例 #6 强制约束：total dry_run_ratio > 30% 时必须至少跑 1 个 full_test。

模块子分规则（Phase 0.3 产出 → Phase 1 同维合并）

模块不独立扣分，而是产出同维内的确定性子分，与 Rubric LLM 子分合并为维度总分。

子分占比（模块 / Rubric）：

Module 子分计算：

dim10 Sentinel 子分：5 类独立计分，每类 0-2 分（0 命中=2，≥2 处命中=0，1 处=1），5 类取均值直接作为 Sentinel 子分（范围 [0,2]）。

dim10 审查子分：起始 2 分，P0 未闭合每项 −2.0，P1 未闭合每项 −0.5，下限 0。即 审查子分 = max(0, 2 − P0未闭合数 × 2.0 − P1未闭合数 × 0.5)。任一 P0 未闭合即清零审查子分，P1 累积 4 项可归零。结合 dim10 上限锁死 ≤40 规则形成双重门控。

模块子分存入 diagnostics.tsv（子分列替代原扣分列），Phase 1 从 diagnostics.tsv 读取，与 Rubric 子分合并为维度总分。

Runtime 中立性 Gate（前置于 Phase 1）

参照 darwin 设为独立 gate，在 Phase 0.3 之后、Phase 1 之前执行。扫描 SKILL.md 全文：

命中任一项则打断流程，报告具体违规位置（行号+原文），要求修复后重新通过此 Gate → Phase 0.5。免检白名单：skill name 明确绑定单一 runtime。

十维执行模式

---

📍 你在这里: 鲁班.Skill > 双模策略

双模策略

模式选择（前置网关）

输入：用户指令 + skill 历史评分
if 用户明确要求"完整/深度/全面/工业/生产" → Full
elif baseline 分 < 70 → Full（需要完整优化）
elif results.tsv 有 revert 记录 → Full（曾退化）
elif delta > 5 且连续 2 轮保持 → Full（有金矿）
elif 用户说"看看/评一下/扫一眼" → Quick
else → Quick（默认）

触顶信号：连续 2 轮 Δ < 2 分 → break，见好就收。

双轨反馈

• Quick→Full：Quick 模式下 3 轮内 Δ > 5 分，自动升级 Full（有金矿）
• Full→Quick：Full 模式下连续 3 个 skill 稳定 delta < 3，后续降级 Quick（成熟稳定）

---

📍 你在这里: 鲁班.Skill > 约束规则

约束规则

1. 不改变 skill 核心功能和用途 — 只优化"怎么写"和"怎么执行"，不改"做什么" → 白话：鲁班只是润色师，不是重写师。skill 该干嘛还干嘛，只把话说得更清楚
2. 不引入新依赖 — 不添加 skill 原本没有的 scripts 或 references 文件 → 白话：不能为了让评分好看就给 skill 偷偷塞新文件，只能用现有的东西优化
3. 每轮只改一个维度 — 避免多个变更导致无法归因；相关簇（dim2/3/4）改其一时观察另两个是否跟涨 → 白话：一次只动一个地方，改完看效果，别东改西改不知道哪一步起了作用
4. 保持文件大小合理 — 优化后 SKILL.md ≤ 原文件 150% 体积 → 白话：优化不是堆字数，膨胀超过一半就是水内容了
5. 尊重花叔风格 — 中文为主、简洁为上 → 白话：别把简洁的中文改成长篇英文论文腔
6. 可回滚 — 所有改动在 git 分支上，用 git checkout 而非 git reset --hard → 白话：改坏了能一键退回，而且退回记录留痕可查
7. 评分独立性 — 效果维度必须用子 agent 独立评分，禁止同一 context「改完直接评」→ 白话：不能自己改完自己打分，那等于既当运动员又当裁判
8. Runtime 中立性 — skill 必须能在 Claude Code、Codex、Cursor、OpenClaw 等任何 skills-compatible runtime 正常运行。除非 skill name 明确绑定单一 runtime（如 xxx-codex），任何单 runtime 措辞、单一 badge、安装路径写死均视为 gate 不通过，须在 P0 优先修复 → 白话：skill 不能只在某一个工具里能用，写的时候要通用，除非名字本身就标明了只给某个工具用
9. 编辑同源检测 — 编辑 agent 与评分 agent 来自同一 context → dim8 所有子维度分 ×0.5，results.tsv 记录 redline_1_violation=true → 白话：如果编辑和评分是同一个 agent 做的，效果分直接砍半——因为很可能有偏见

架构红线运行时检测

1. 禁止 self-edit-self-evaluate：同一 agent 不得既编辑又评分。违反 → dim8 降权 ×0.5
2. 禁止跨维度打包修改：一轮只改一个维度。违反 → 整轮回滚
3. 禁止 dry_run 为 full_test：dim8 全部 dry_run 等于跳过效果验证。违反 → results.tsv 标记 invalid
4. 禁止 bypass gate：P0 未闭合不得进入下一 phase。违反 → 中断流程

---

📍 你在这里: 鲁班.Skill > 多评委与多角色评分

多评委与多角色评分（Full 模式）

同质多评委（压制采样噪声）

Full 模式采用 2 个独立 file-agent 评委（dispatch_task），评分取中位数。2 个评委读同一份 SKILL.md 和同一套量规，系统性高估方向一致——中位数不纠正共享偏误。

异质评委（按需触发）

异质评委不计入标准评委数量，结果以 [orthogonality] 标注追加到评分卡。

多角色并行审查（P0/P1/P2 分级）

当 dim8c < 5 或 dim10 原始分 < 60 时触发。角色组合按文档类型选派：

审查严重度分级（直接影响 dim10 审查子分）：

审查流程（阶段 0-4）

阶段 0 — 前置：识别文档类型 → 选派角色 → 公开分级声明

阶段 1 — 独立审查：角色间绝对隔离（不通信、不协商、不共享发现），逐章覆盖登记，输出结构化问题清单（<角色缩写>-<序号>，字段含章节/角色/P级/问题描述/建议修复方向）

阶段 2 — 问题归一化：同类合并（同章节+同根源→保留最高 P 级）、侧面互补（不同视角→合并注明"双重视角"）、独立保留（不同章节/根源→各自独立）；输出归一化清单（ID 重编号 N-01…）+ 原始ID→归一化ID 映射表

阶段 3 — 编辑修复：按 P0→P1→P2 逐项修复，禁止"顺手改"（仅修清单内条目），修复后全文档交叉验证

阶段 4 — 复审闭环：P0 由原审查角色逐条确认闭合（不通过打回阶段 3）；P1 由编辑方自检 + 原角色 30% 抽查（不通过降级 P0）；P2 由编辑方自检（不通过升级 P1）

子 Agent 不可用降级

当 dispatch_task 无法派发独立 judge 时（工具报错或 agent 类型不可用），触发降级：

降级模式下 dim8 子维度处理：8a 意图完成度 → 推演值 ×0.3（无实测置信度低）、8b 净提升 → 推演值 ×0.3（无 baseline 对照）、8c 副作用 → 正则扫描（格式异常/冗余文本检测）。降级原因写入 results.tsv note 字段。

警告：降级模式评分不可与 full_test 评分直接比较——降级分虚高。连续 3 轮降级需在汇总报告中显式标注。

---

📍 你在这里: 鲁班.Skill > 优化流程

优化流程（Phase 0-3）

Phase 0: 初始化

Quick 模式：跳过 step 2（不建 git 分支），其余相同。

1. 确认优化范围：全部 skills 或用户指定列表
2. git checkout -b auto-optimize/YYYYMMDD-HHMM
3. 检查 results.tsv 是否存在，不存在则创建并写入表头（12 列）
4. 读取 results.tsv 了解历史评分
5. ROI 前置评估：若历史基线分 ≥85 且最低维度分 ≥7 → 跳过优化，告知用户「天花板已近，建议仅评估不改」
6. 从 results.tsv 读取 status=revert 的历史维度，标记为「绕行」；对照反例黑名单 8 条，确认当前方案不命中
7. 检查 diagnostics.tsv 是否存在，不存在则创建并写入表头（模块/维度/子分/文件/行号/详情）

Phase 0.3: 模块缺陷检测（子分清单）

六模块对目标 skill 做静态检测，输出确定性子分到 diagnostics.tsv。模块不产生评分，只产子分。

for each skill:
  1. 按优先级顺序执行：SkillOps → EvoSkill → HASP → CASCADE → Distill → Sentinel
  2. 每模块按「模块子分规则」逐项检测
  3. 命中缺陷 → 追加 diagnostics.tsv 一行（模块/维度/子分/文件/行号/详情）
  4. 模块完成后不回写 SKILL.md，仅写入子分记录

EvoSkill 例外：振荡检测仅标注 [oscillation]，不产生子分，供 Phase 2 Step 1 人工决策。

Sentinel 执行方式：运行 scripts/security_audit.py --diagnostics ，扫描目标 skill 的 scripts/ + references/ 中所有文本文件（排除 SKILL.md 文档层描述），匹配 5 类模式：

• 恶意指令：exec( / system( / subprocess / rm -rf / format / del /f / reg delete
• 硬编码凭据：api_key= / password= / token= / secret= / 私钥 PEM
• Prompt 注入：DAN / jailbreak / simulate / system override / ignore.*instructions
• 数据外泄：smtp / upload.*external / scp / ftp upload
• 权限越权：chmod / chown / sudo / su - / icacls

🔴 CHECKPOINT：展示子分摘要（各维度子分、哪些模块有输出、EvoSkill 振荡告警、Sentinel 安全告警），确认后进入 Runtime 中立性 Gate → Phase 0.5。

Runtime 中立性 Gate

扫描 SKILL.md 全文，命中 Runtime 中立性 Gate 中任一未豁免项则打断流程，报告违规行号+原文，要求修复后重新进 Phase 1。通过后进入 Phase 0.5。

Phase 0.5: 测试 Prompt 设计

for each skill:
  1. 读 SKILL.md，理解功能
  2. 设计 2-3 个测试 prompt（典型场景 + 歧义场景）
  3. 保存到 skill目录/test-prompts.json

test-prompts.json 模板：

[
  {
    "id": "tp-01",
    "prompt": "帮我优化这个skill的frontmatter",
    "expected_behavior": "能正确读取并识别 frontmatter 字段",
    "category": "典型场景"
  },
  {
    "id": "tp-02",
    "prompt": "改一下",
    "expected_behavior": "歧义输入，应追问具体需求而非直接修改",
    "category": "歧义场景"
  }
]

展示所有 prompt 给用户，🔴 CHECKPOINT · 🛑 STOP 确认后进入 Phase 1。

Phase 1: 基线评估

维度总分 = Module 子分 + Rubric 子分（同维内按比例加权合并）。dim5/dim6/dim7b/dim10 四维有模块介入，其余维度仅 Rubric。

for each skill:
  1. 按 Rubric 表逐维评分，得各维度 Rubric 子分
  2. 读取 diagnostics.tsv，取 Module 子分
  3. 同维合并：dim5 = (HASP子分 × 3 + Rubric子分 × 14) / 17 × 10
              dim6 = (SkillOps子分 × 3 + Rubric子分 × 1) / 4 × 10  # SkillOps=0 不归零 Rubric（Rubric 评估语义完整性，与引用可达性正交）
              dim7b = (Distill子分 × 2 + Rubric子分 × 4) / 6 × 10
              dim10 = (Sentinel子分 × 2 + P0/P1审查子分 × 2) / 4 × 10
              其余维度 = Rubric子分 × 10
  4. 效果评分：spawn 子 agent 跑 test-prompts
     - with_skill: 带 SKILL.md 执行
     - baseline: 不带 skill 直接执行（裸 prompt）
  5. 加权计算总分，记录到 results.tsv

Full 模式额外执行消费者能力基线测试：若 references/baseline-skill.md 不存在，则按当前所评估 skill 的核心领域自动生成一份通用基线 skill（含 name/description/workflow/约束规则 等基本结构），保存到该路径。用 baseline-skill 测目标模型裸能力，若 baseline-skill 评分 < 60 则输出能力不足报告并阻断后续优化。此测试独立于 dim8 的 with_skill vs baseline 对比，不要混淆。

🔴 CHECKPOINT：展示基线分 + diagnostics 诊断摘要，确认后进入 Phase 2。

Phase 2: 优化循环

Quick 模式：不建 git 分支，Step 3 用 cp SKILL.md SKILL.md.bak 代替 git commit，Step 6 用 cp SKILL.md.bak SKILL.md 代替 git checkout 回滚。

for each skill（按基线分数升序，先优化最弱的）:
  round = 0
  while round < MAX_ROUNDS:
    round += 1

    # Step 0: 模块检测（每轮重新执行）
    重新运行 Phase 0.3 六模块检测 → 更新 diagnostics.tsv（子分清单）
    EvoSkill 读取最新的 results.tsv，HASP 读取最新的 SKILL.md，Distill 重算密度

    # Step 1: 诊断
    读取更新后的 diagnostics.tsv + results.tsv 最新评分
    找子分最低或得分最低维度。注意 dim2/3/4 是相关簇——修一个时另两个常跟涨。
    EvoSkill 振荡标注 `[oscillation]` 的维度→跳过不改，除非用户明确要求。

    # Step 2: 提方案
    1 个具体改进方案：改什么（段落/行）+ 为什么（对应 rubric 哪条）+ 预期提升。
    对照反例黑名单 8 条 + rejected_edits.md + luban-profile.json oscillation_guard，命中 → 改方案重写。

    # Step 3: 编辑前备份
    git add -A && git commit -m "pre-edit: {skill_name}"

    # Step 4: 执行改进
    编辑 SKILL.md（字符变化 ≤10%） → 按 Rubric 逐项自检 dim1/4/7a/9

    # Step 5: 重新评分
    结构维度：主 agent 重评；效果维度：spawn 独立子 agent（不同 context）

    # Step 6: 决策
    if 新总分 > 旧总分:
      git commit -m "optimize: {skill_name} +{delta}分 [{dimension}]"
      触顶信号 → break
    else:
      git checkout HEAD~1  # 回滚
      记录到 rejected_edits.md
      break

🔴 CHECKPOINT · 每个 skill 优化完展示改动摘要 + 分数变化，等用户确认再继续。

Phase 2 出口：全部 skill 优化完成后 → 检查 Phase 2.5 触发条件：满足则进入 Phase 2.5，否则进入 Phase 3。

Phase 2.5: 探索性重写（按需触发）

连续 2 个 skill 都在 round 1 break 时触发（或单 skill 连续 2 轮 round 1 break）：git stash → 从头重写 SKILL.md → 重新评估 → 重写版 > stash 版则采用，否则 git stash pop。🛑 STOP：必须征得用户同意。

Phase 3: 汇总报告

展示全局战绩：

Epoch Meta-Review（Full 模式）

1. 汇总本次所有 skill 的优化记录
2. 提炼可迁移规律 → 追加到 meta_learnings.md
3. 识别 oscillation 模式：同一维度在 2+ skill 间反复涨跌 → 追加到 luban-profile.json：

{
  "oscillation_guard": [
    {"dimension": "dim5", "skills": ["skill-a", "skill-b"], "pattern": "细化→回滚→细化→回滚", "recommendation": "跳过 dim5 优化，先加固 dim3"}
  ]
}

此字段供后续 Phase 2 Step 2 查阅，命中则跳过该维度。

备份轮转策略

git 分支无限增长会导致仓库膨胀。Phase 3 完成后触发清理：

• 每个 skill 目录保留最近 5 轮编辑的备份（latest-5）
• baseline 备份和首轮备份永久保留，不受轮转影响
• 超出 5 轮的历史备份移至 luban-backups-archive/{skill_name}/ 归档

---

📍 你在这里: 鲁班.Skill > 优化流程 > 异常与边界条件

异常与边界条件

流程假设环境理想，但实操常遇异常。以下预定义 fallback，保证优化不会「一跑就卡住」。

原则：异常先告知用户，再按规则处理；绝不静默跳过或静默失败。

---

📍 你在这里: 鲁班.Skill > 关键数据结构

关键数据结构

results.tsv（12 列）

timestamp	commit	skill	round	old_score	new_score	status	dim_changed	delta	note	eval_mode	judge_count
2026-06-11T10:00	baseline	luban-slides	0	-	78	baseline	-	-	初始评估	full_test	2
2026-06-11T10:05	a1b2c3d	luban-slides	1	78	84	keep	dim3	+6	补充 fallback 三段式	full_test	2
2026-06-11T10:10	b2c3d4e	luban-slides	2	84	82	revert	dim5	-2	过度细化，回滚	dry_run	1

• eval_mode: full_test（跑了子 agent 测试）或 dry_run（模拟推演）
• judge_count: 参与评分的独立 judge 数量
• 文件位置：被优化 skill 目录下的 results.tsv

diagnostics.tsv

模块子分清单（Phase 0.3 产出），每模块对目标 skill 的静态缺陷检测结果：

模块	维度	子分	文件	行号	详情
SkillOps	dim6	3	-	-	全引用路径可到达
HASP	dim5	1	SKILL.md	-	软化词 3 处（建议×2/可考虑×1）
EvoSkill	dim3	—	-	-	[oscillation] dim5 历史 3 轮回弹

• 文件位置：被优化 skill 目录下的 diagnostics.tsv
• Phase 0.3 每次运行前清空重建（保持最新一轮子分）
• Phase 1 读子分按维度取 Module 子分，与 Rubric 子分占比加权合并
• EvoSkill 不产生子分，子分=—，详情标注 [oscillation]

optimization-registry.tsv

鲁班全局优化登记表（鲁班自己的目录下），记录每次对某个 skill 执行的优化：

• skill_name：被优化的 skill 名
• timestamp：运行时间戳（ISO 8601）
• score_before：优化前分数
• score_after：优化后分数
• rounds：本次运行的优化轮次
• eval_mode：full_test / dry_run
• 只增不删，每次 luban optimize 追加一行
• 文件位置：luban-workspace/optimization-registry.tsv

rejected_edits.md

被回滚的编辑方案，每轮回滚追加一条：

## REJ-{序号} | {时间戳} | {skill名}

- **目标维度**: dim5
- **改动段落**: L120-L135
- **方案摘要**: 将三处"建议"改为"必须"
- **被拒原因**: 改变了 skill 核心语义，违反约束规则 #1
- **绕行建议**: dim5 已触顶，优先修 dim3

meta_learnings.md

跨 skill 可迁移规律，Phase 3 Meta-Review 追加：

## ML-{序号} | {时间戳}

- **规律**: dim2/3/4 相关簇——修 dim3（三段式 fallback）时 dim2 平均跟涨 1.5 分
- **来源 skill**: luban-slides, code-reviewer（2/2 验证）
- **置信度**: 高
- **可复用场景**: 任何有"步骤描述"+"错误处理"双薄弱点的 skill

---

📍 你在这里: 鲁班.Skill > 反例黑名单

luban 操作反例黑名单

来自早期 40 次 0 revert 的教训。每轮 Phase 2 Step 2 改动前对照一次，命中 → 改方案重写。

📎 HASP / CASCADE / Distill / MUSE / 调度器 模块完整流程 → references/modules.md

优化策略库

按优先级排序，每轮只做最高优先级的一个。命中即停止向下检索。

P0: 适配性与效果问题（gate 项，必须先修）

例外：skill name 明确标注单 runtime（如 xxx-codex）的，跳过 Runtime 绑定检查。

P1: 结构性问题

P2: 具体性问题

P3: 可读性问题

维度相关簇提醒：dim2/3/4 联动——修 dim3（fallback 三段式）时 dim2 常跟涨 1-2 分。

优先级公式：弱点深度 = (10 − 当前维度分) × 权重。同级策略内按弱点深度降序选目标。

---

📍 你在这里: 鲁班.Skill > HL 操作速查

HL 操作速查

3 条高杠杆操作：

• HL-1（dim4）显性视觉标记是杠杆：加 🔴 CHECKPOINT / 🛑 STOP。4 行改动撬动 dim4 +3 分
• HL-2（dim2/3/4 相关簇）三段式 fallback 一石三鸟：修 dim3（触发条件/一线修复/仍失败兜底）→ dim2 跟涨 1-2 分，dim4 顺便补检查点
• HL-3（Phase 2 退出）触顶自动 break：+0.15 是停手信号，不是继续信号

完整红线定义见上文「架构红线运行时检测」4 条。

---

📎 HASP / CASCADE / Distill / MUSE / 调度器 模块完整流程 → references/modules.md

---

📍 你在这里: 鲁班.Skill > 资源文件速查

资源文件速查

---

📎 反模式、FAQ、架构红线 → references/faq.md