name	darwin-skill
disable-model-invocation	true
description	Darwin Skill 2.1 (达尔文.skill 2.1): autonomous skill optimizer, v2.0 integrates Microsoft Research SkillLens (arXiv 2605.23899) 9-dim rubric + SkillOpt (arXiv 2605.23904) validation-gated design + human-in-the-loop checkpoints. Evaluates SKILL.md files using a 9-dimension rubric (structure + effectiveness + meta-skill blacklists), runs hill-climbing with git version control, spawns independent judge agents for blind evaluation, validates improvements through test prompts with auto-break on diminishing returns, and generates visual result cards. Use when user mentions "优化skill", "skill评分", "自动优化", "auto optimize", "skill质量检查", "达尔文", "darwin", "帮我改改skill", "skill怎么样", "提升skill质量", "skill review", "skill打分".

Darwin Skill 2.1

v2.1 · 2026-06-10 — keep/revert 棘轮从「绝对分数 delta」改为「paired 同-judge 比较 + 奇数 N 多数决」（绝对分数 ±8 judge 噪音淹没保守编辑的真实增益、是 false-revert 源；within-judge 比较消除换尺污染）。绝对分数降级为 triage-only。 v2.0 · 2026-05-28 — 吸收 Microsoft Research SkillLens（arXiv 2605.23899）的 9 维评分药方 + SkillOpt（arXiv 2605.23904）的 validation-gated 验证机制 + human in the loop 三层守关。

借鉴 Karpathy autoresearch 的自主实验循环，对 skills 进行持续优化。核心理念：评估 → 改进 → 实测验证 → 人类确认 → 保留或回滚 → 生成成果卡片 GitHub: https://github.com/alchaincyf/darwin-skill

设计哲学

darwin 的设计精髓（借鉴 autoresearch）：

单一可编辑资产 — 每次只改一个 SKILL.md
双重评估 — 结构评分（静态分析）+ 效果验证（跑测试看输出）
棘轮机制 — 只保留改进，自动回滚退步
独立评分 — 评分用子agent，避免「自己改自己评」的偏差
人在回路 — 每个skill优化完后暂停，用户确认再继续

与纯结构审查的区别：不只看 SKILL.md 写得规不规范，更看改完后实际跑出来的效果是否更好。

评估 Rubric（9 维，总分 100）

权重：① Frontmatter 7｜② 工作流 12｜③ 失败模式 12｜④ 检查点 6｜⑤ 可执行具体性 18｜⑥ 资源整合 4｜⑦ 整体架构 12｜⑧ 实测表现 23｜⑨ 反例黑名单 6

总分 = Σ(维度分×权重)/10（维度分 0-10，总分 0-100）；绝对总分只做 triage（粗排先改谁），绝不用于 keep/revert（judge 噪音 ±8）。dim8 实测表现分不进 triage 加权总分（与 judge 噪音同源，只作定性 gate）
keep/revert 走 paired 同-judge 比较 + 奇数 N 多数决（Phase 2 Step 4；judge 模板 references/judge-prompt.md）
各维详细评分标准 / 实证基础 / 「实测表现」说明 → references/rubric-details.md

Runtime 适配性审查（gate 项，独立于 9 维度评分）

skill 应当能在 Claude Code / Codex / Cursor / OpenClaw / Hermes / Gemini CLI / OpenCode 等 skills-compatible runtime 通用——否则其他 agent 解析时会被「在 Claude Code 里」「Claude Code skill」等措辞误判为「不是给我用的」直接拒装（实例：nuwa-skill 因此被 Marvis agent 拒绝）。

Phase 1 基线评估时强制跑一次红灯扫描

grep -nE "(在 Claude Code|Claude Code skill|Claude Code 用户|Cursor only|Codex 中|^\[!\[Claude Code|~/\.claude/skills/[a-z]*|/plugin install\b)" SKILL.md README.md "$技能目录"/*.md 2>/dev/null

输出非空 = 红灯命中 → 先对照「例外」节排除规则定义行，其余命中强制把 Phase 2 第一轮定为 P0「runtime drift 修复」（写入 results.tsv 的 note 列 runtime_warn=<命中条数>，与 judge 人数 N 无关）。注意：对本技能自扫必命中自身 38/43 行的规则定义文本，属例外。

例外（允许的「Claude Code 痕迹」）

frontmatter 触发词、花叔生态内部 skill 名引用、明确标注 runtime-specific 章节、commit message——这些正当出现，不算红灯。

→ 红灯/绿灯完整对照表 + 例外清单详细规则 + Phase 1/2/3 各阶段审查时机见 references/runtime-neutrality.md

自主优化循环

Phase 0: 初始化

1. 确认优化范围：
   - 全部skills → 扫描技能根目录的 */SKILL.md（技能根 = {SKILL_DIR} 所在目录，runtime 自探测；排除 darwin-skill 自身，防自我优化递归）
   - 指定skills → 用户指定列表
2. 创建 git 分支：auto-optimize/YYYYMMDD-HHMM
3. 初始化 results.tsv（如不存在）
4. 读取现有 results.tsv 了解历史优化记录

Phase 0.5: 测试Prompt设计

在评估之前，为每个skill设计测试prompt。这步很关键——没有测试prompt，「实测表现」维度就打不了分。

for each skill:
  1. 读取 SKILL.md（大文件用 sed 切片读，勿用 Read 工具读全文），理解它做什么
  2. 设计2-3个测试prompt，覆盖：
     - 最典型的使用场景（happy path）
     - 一个稍复杂或有歧义的场景
  3. 保存到审计工作区 .darwin/test-prompts/{skill名}.json（不写进被审技能目录，防污染其 git）：
     [
       {"id": 1, "prompt": "用户会说的话", "expected": "期望输出的简短描述"},
       {"id": 2, "prompt": "...", "expected": "..."}
     ]

展示所有测试prompt给用户，确认后再进入评估。测试prompt的质量决定了优化方向是否正确。

Phase 1: 基线评估（Baseline）— triage 用途

本阶段绝对分数是 triage 排名（决定先改谁），不是 keep/revert 基准。judge 对 gross 差异会一致（「哪支最弱」可信），对 fine-grained delta 不可信（±8 噪音）。keep/revert 在 Phase 2 用 paired 比较。

for each skill in 优化范围:

  # 结构评分（主agent可以做）
  1. 读取 SKILL.md 全文
  2. 按维度1-7、9逐项打分（附简短理由）——dim8 不进加权总分

  # 效果评分（用子agent做，独立于主agent）
  3. 对每个测试prompt，spawn子agent：
     - with_skill: 带着SKILL.md执行测试prompt（两组同模型、同 prompt 骨架、同上下文裁剪，受控变量一致）
     - baseline: 不带skill执行同一prompt（基线组声明「不加载本技能、不读技能目录」，报告标注隔离置信度）
  4. 对比两组输出，打实测表现（dim8）的分（定性：过/打回；不进 triage 加权总分）

  # 汇总
  5. 计算加权总分
  6. 计算加权总分（结构 7 维 + dim9），记录到 results.tsv；dim8 分单独记 note 列

如果子agent不可用（超时、环境限制），实测表现（dim8）用干跑验证打分，标注 dry_run，分数 ×0.7 折算且不进 triage 排名。不要因为跑不了测试就跳过这个维度——哪怕是模拟推演也比完全不看效果好。

基线评估完成后，展示评分卡：

┌──────────────────────────┬───────┬──────────────┬──────────────┐
│ Skill                    │ Score │ 结构短板      │ 效果短板      │
├──────────────────────────┼───────┼──────────────┼──────────────┤
│ huashu-proofreading      │ 78    │ 边界条件      │ 测试prompt2  │
│ huashu-slides            │ 72    │ 指令具体性    │ baseline持平  │
├──────────────────────────┼───────┼──────────────┼──────────────┤
│ 平均                     │ 75    │              │              │
└──────────────────────────┴───────┴──────────────┴──────────────┘

🔴 CHECKPOINT · 🛑 STOP：暂停等用户确认，再进入优化循环。

Phase 2: 优化循环

用户确认后，按加权短板从大到小排序（与 Step 1 同口径），先优化最弱的。

for each skill:
  round = 0
  while round < MAX_ROUNDS (默认3):
    round += 1

    # Step 1: 诊断
    找出加权短板最大的维度：weighted_gap = weight × (10 - score) / 10，结构或效果都算
    # /10 与「总分 = Σ(维度分 × 权重) / 10」同标度：weighted_gap 就是该维度还能贡献的总分数
    # 为什么不用「原始分最低」：低权重维度会制造进步幻觉——issue #18 实战中
    # dim9（权重6，gap 5.3）原始分最低被优先修，而 dim8（权重23）加权短板最大（11.5）却 3 轮未动
    # 加权短板相近（差距 ≤ 1.0，同上述标度）时，按权重高者优先，其次随机（不回退原始分升序）
    # HL-3 警告：dim2/dim3/dim4 是相关簇，修一个时另两个常跟着涨
    # → 不要因为 dim3 短板最大就单独修，要看整簇短板再决定是否同步改

    # Step 2: 提出改进方案
    针对该维度，生成1个具体改进方案（若目标维度属 dim2/3/4 相关簇，方案必须声明对另两维的影响）：
      - 改什么（具体段落/行）
      - 为什么改（对应rubric哪条）
      - 预期提升多少分

    # Step 3: 执行改进
    编辑 SKILL.md
    git add + commit（message: "optimize {skill}: {改进摘要}"）

    # Step 4: Paired 重新评估（取代绝对重打分——绝对分数 judge 噪音 ±8、淹没保守编辑的 +3~8 真实增益）
    spawn N=3 独立 judge，每个【同一次 call 内】读两版：
      - 改前版：git show HEAD:<skill-path>/SKILL.md（上一个 kept commit）
      - 改后版：working tree 当前 SKILL.md
    照 9 维 rubric 当【比较准则】（不是各打绝对分），回 {better | worse | tie} + margin{clear|slight} + 一句理由。
    judge prompt 模板见 `references/judge-prompt.md`（版本标签随机化，防顺序偏差；替换 {repo}/{commit-before}/改前版传 {commit-before}，改后版 cat 工作树文件，全走 bash 不用 Read——模板见该文件）。
    关键：同一 judge 在一次 call 内比两版 → 它那把不准的尺对两版【等量作用、在比较时抵销】(within-judge cancellation)，
    这正是 paired 优于绝对的机制。N 取奇数（默认 3；close call 升 5）。

    # Step 5: 共识决策（多数决，取代「新总分 > 旧总分」）
    cur = 投 better 的 judge 数；wor = 投 worse 的；tie = 投 tie 的
    if cur > wor and cur > (cur + wor) / 2:  # better 严格过半；tie 不计入多数；1:1:1 判不确定 → 人工裁断或重评一次
      status = "keep"
      # HL-4 见好就收：连续 2 轮多数 judge 判 margin=slight 或 tie → break 进 Phase 3（计数器在每个技能优化开始时清零）
    else:           # 多数说 worse —— 这才是真退步（已扣掉换尺噪音）
      status = "revert"
      git revert <本次改进 commit hash>（Step 3 提交时记录该 hash；创建新commit回滚，不用 reset --hard）
      记录到 results.tsv（note 记 vote 比数 + 一句 worse 理由）
      break
    # 单评绝对分数出现「负 delta」≠ revert 信号；必须经 paired 多数判 worse 才 revert（否则在丢真实增益）

    # Step 6: 日志
    results.tsv 追加行；主线程按最新版本重算 triage 分数，作为下一轮 Step 1 的 score 输入

  # === 🔴 CHECKPOINT · 每个 skill 优化完后强制人审 ===
  展示该skill的改动摘要：
    - git diff（改前 vs 改后）
    - 分数变化（哪些维度提升/下降）
    - 测试prompt输出对比（如果跑过的话）
  等用户确认 OK 再继续下一个skill。
  如果用户说"不好"，回滚到该skill的优化前版本。

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

当 hill-climbing 连续2个skill都在 round 1 就 break（涨不动）时，提议一次「探索性重写」：

1. 选一个瓶颈skill
2. git stash 保存当前最优版本
3. 从头重写SKILL.md（不是微调，是重新组织结构和表达方式）
4. 重新评估
5. if 重写版 > stash版（用同一批测试 prompt 的 paired 比较裁决）: 采用重写版 + git stash drop
   else: git stash pop 恢复

这解决了 hill-climbing 的局部最优问题——有时候需要「先拆后建」才能突破瓶颈。 🔴 CHECKPOINT · 🛑 STOP：必须征得用户同意后才执行。

Phase 3: 汇总报告

## 优化报告

### 总览
- 优化skills数：N
- 总实验次数：M
- 保留改进：X（Y%）
- 回滚次数：Z
- 实测验证：A次完整测试 / B次干跑

### 分数变化
┌──────────────────────────┬────────┬────────┬────────┐
│ Skill                    │ Before │ After  │ Δ      │
├──────────────────────────┼────────┼────────┼────────┤
│ huashu-proofreading      │ 78     │ 87     │ +9     │
│ huashu-slides            │ 72     │ 83     │ +11    │
├──────────────────────────┼────────┼────────┼────────┤
│ 平均                     │ 75     │ 85     │ +10    │
└──────────────────────────┴────────┴────────┴────────┘

### 主要改进
1. [skill-A] 补充了边界条件处理，测试输出质量提升明显
2. [skill-B] 重组了workflow结构，baseline对比优势增大

results.tsv 格式

9 列：timestamp commit skill old_score new_score status dimension note eval_mode

eval_mode：paired（同 judge 比改前/改后，keep/revert 权威依据）｜full_test（子agent 跑 prompt）｜dry_run（模拟推演、仅供参考）
paired 行：new_score 记 -，vote 比数（如 3-0 better）记进 note 列，保持 new_score 列纯数字语义
完整示例与位置说明 → references/results-tsv-format.md；账本在 {SKILL_DIR}/results.tsv

实战 high-leverage 操作（精髓速查）

HL-1~HL-4 诊断启发式全表 → references/high-leverage.md。核心：HL-1 关键决策点加 🔴/🛑 显性视觉标记（靠「必须」措辞不算）；HL-2 失败分支三段式；HL-3 dim2/3/4 相关簇；HL-4 连续 2 轮 triage 总分增量 Δ<2 即停手。

优化策略库

P0-P3 按优先级全表 → references/optimization-strategies.md。每轮只做最高优先级的一个：P0 runtime 适配/效果问题 → P1 结构 → P2 具体性 → P3 可读性。

异常与边界条件

11 条 fallback 全表 → references/exceptions.md。原则（同反例黑名单 #7）：异常先告知用户，再按规则处理。新增分支：子代理超时/挂起（3 轮未归 = 派发后经 3 次检查轮仍未收到完成通知）→ 中断，主线程降级串行/内联执行，报告标注「inline 降级，置信度低于独立子代理」。

darwin 操作反例黑名单（dim9 应用）

8 条反例全表 → references/darwin-blacklist.md。触发场景：每轮 Phase 2 改动前对照一次，任一命中即改方案重写。

约束规则

不改变skill的核心功能和用途 — 只优化"怎么写"和"怎么执行"，不改"做什么"
不引入新依赖 — 不添加skill原本没有的scripts或references文件
每轮只改一个维度 — 避免多个变更导致无法归因
保持文件大小合理 — 优化后SKILL.md不应超过原始大小的150%
尊重花叔风格 — 中文为主、简洁为上
可回滚 — 所有改动在git分支上，用git revert而非reset --hard
评分独立性 — 实测表现维度（dim8）必须用子agent或至少干跑验证，不能在同一上下文里「改完直接评」
Runtime 中立性 — skill 必须能在 Claude Code、Codex、Cursor、OpenClaw、Hermes 等任何 skills-compatible runtime 中正常运行。除非 skill 名明确绑定单一 runtime（如 xxx-codex、huashu-slides-codex），任何「在 Claude Code 里」「Claude Code skill」「单一 badge 钉死」「安装命令只给 .claude/skills/ 一种路径」都视为 gate 不通过，须在 P0 优先修复（详见「Runtime 适配性审查」章节）

使用方式

全量优化（推荐首次使用）

用户："优化所有skills"
→ Phase 0-3 完整流程
→ 默认：先基线评估，按分数升序优先优化最低 5-10 个

单个优化

用户："优化 huashu-slides 这个skill"
→ 只对指定skill执行 Phase 0.5-2

仅评估不改

用户："评估所有skills的质量"
→ 只执行 Phase 0.5-1（设计测试prompt + 基线评估），不进入优化循环

查看历史

用户："看看skill优化历史"
→ 读取并展示 results.tsv

设计灵感与学术依据

详见 references/credits.md（autoresearch 对应关系 + SkillLens/SkillOpt 引用 + 微软官方集成名单）。

成果卡片生成（Result Card）

完整模板/生成流程/资源速查 → references/result-card-guide.md。要点：复制 templates/result-card.html 换 data-field → 随机风格（swiss/terminal/newspaper）→ node {SKILL_DIR}/scripts/screenshot.mjs <html> <png>（脚本失败回退 npx playwright）。

FilesExpand file tree

SKILL.md

Latest commit

History