sundanian1991/skill-anatomy

Skill 解剖术 + 进化术

先拆开看懂，再加点料造出更好的。

核心原则

1. 说人话：用 13 岁孩子都能听懂的语言。每个手法都配一个生活类比。测试标准：念给 13 岁孩子听，他能复述出来就算合格。
2. 从 skill 本身出发：不拿固定清单去套。读完之后发现它用了什么巧妙手法，再解释为什么。
3. 回答三个问题：每个手法都要说清楚——它在干嘛？没有它会怎样？为什么用这种方式？
4. 最小改动：进化术不重写整个 skill，只告诉你改哪几行、加什么、删什么。

执行流程

Phase 0: 判断模式

| 用户输入 | 模式 | 做什么 | |---------|------|--------| | 一个 skill 名 | 解剖术·单体 | 拆解一个 skill | | 两个 skill 名 | 解剖术·对比 | 左右对比两个 skill | | "总结共性" | 解剖术·提炼 | 从多个已解剖的 skill 中找共性 | | "我想改"/"帮我进化" | 进化术 | 基于已有解剖，精准指导改造 | | 无输入 | 列表选择 | 扫描目录，展示可选 skill |

定位 skill：扫描 ~/.claude/skills/ 目录，匹配名称，读取 SKILL.md + references/ 下所有文件。

---

解剖术

Phase 1: 通读理解

把 skill 从头到尾读一遍，搞清楚三件事：

1. 它是干什么的？（一句话说清楚，像跟朋友介绍一样）
2. 它从输入到输出走了几步？（画出流程线）
3. 它有多复杂？（行数、步骤数、是否用 Agent、是否联网、是否有中间检查）

Phase 2: 发现手法

从 skill 本身出发，问自己：

• 有什么地方让人觉得"这个设计挺聪明的"？
• 有什么地方是"去掉就会出问题"的？
• 有什么地方是"明明可以更简单，但选择了更复杂的方式"？

每个发现的手法，用这个结构解释：

• 它在干什么（一句话）
• 打个比方（生活中的类比，13 岁孩子能懂的）
• 没有它会怎样（去掉的后果）
• 为什么用这种方式（而不是其他方式）
• 在哪里见过类似的（如果其他 skill 也用了，顺便提一句）

参考 references/section-archetypes.md 辅助理解常见 section 的意图，但不要被它限制。

Phase 3: 推理隐性决策

找出"没写出来但很重要"的设计选择：

• 为什么选了这种输出格式而不是那种？
• 为什么流程是这个顺序？
• 为什么某些东西被明确禁止了？
• 为什么有些地方很详细，有些地方很简略？

每个隐性决策用三栏解释：

• 作者选了什么
• 还可以怎么选
• 为什么选这个（用大白话，能跟其他 skill 对比就对比）

Phase 4: 生成 HTML 页面

读取 references/html-template.md 获取样式规范。生成单个自包含 HTML 文件。

单体解剖页面（5 个 Tab）：

| Tab | 回答什么问题 | |-----|------------| | 它是什么 | 这个 skill 是干嘛的？有多复杂？ | | 它怎么运转 | 从头到尾怎么工作？每一步为什么存在？ | | 它的巧妙之处 | 有什么聪明的设计？（用类比解释） | | 看不见的选择 | 作者做了哪些你看不到的选择？为什么？ | | 如果你想造 | 哪些可以搬走用？哪些别照搬？推荐对比谁？ |

对比演示页面：

• 左右并排，维度切换（流程 / 手法 / 决策 / 复杂度）
• 底部差异洞察：沿 5 条轴比较（输出性质、复杂度来源、交互模式、信息依赖、失败处理）
• 用大白话解释"为什么不同"

跨 skill 提炼页面：

• 列出已分析的 skill
• 归纳反复出现的手法（从观察中长出来的）
• 每个共性标注"在哪些 skill 中见过"和"什么时候该用"

Phase 4.5: 产出质量审核

生成 HTML 之后，归档之前，必须过一遍质量关卡。不是自己觉得"写得不错"就行——要有客观标准可以检验。

审核一：事实准确性（回源验证）

从解剖结果中随机抽 3 个具体断言，回到原始 skill 文本中验证：

| 断言类型 | 验证方式 | 不通过信号 | |---------|---------|-----------| | "它用了 XX 手法" | 在 skill 中找到对应的具体行/段落 | 找不到原文支撑，是自己编的 | | "没有它会导致 YY" | 逻辑推演：去掉这段后流程是否真的断裂 | 去掉了其实也没事，夸大了重要性 | | "作者选了 A 而不是 B" | 确认 A 确实存在于 skill 中，B 确实是合理替代方案 | A 描述不准确，或 B 根本不可行 |

任何一条不通过 → 回到 Phase 2/3 修正对应内容后重新生成。

审核二：可懂性检查（13 岁标准）

逐个检查每个手法的解释：

• 有没有用了"禁止清单"里的词？（模式基因、设计模式、架构、范式、抽象层、解耦）
• 每个手法是否都配了生活类比？
• 类比是否真的能帮助理解？（不是硬凑的）
• 读完之后能否用一句话复述"它在干嘛"？

不通过 → 重写对应解释，换一个更直白的说法或更贴切的类比。

审核三：完整性检查

| 检查项 | 通过标准 | 不通过信号 | |--------|---------|-----------| | 手法数量 | ≥2 个（再简单的 skill 也有设计选择） | 只找到 1 个或 0 个 | | 隐性决策 | ≥2 个（每个 skill 都有没写出来的选择） | 只列了表面信息 | | "如果你想造" Tab | 有"可搬走用"和"别照搬"两类 | 只说好话没说风险 | | 流程步骤 | 每步都标注了"为什么存在" | 只描述了"做什么"没说"为什么" |

审核四：对比模式专项（仅对比演示时）

• 两个 skill 的差异洞察是否回答了"为什么不同"而不只是"哪里不同"？
• 5 条分析轴是否都有内容？空的轴说明分析不够深入。

迭代上限

Phase 4.5 最多执行 2 轮。如果 2 轮后仍有不通过项，在页面中标注"此处分析可能不够准确，建议对照原文验证"，然后继续归档。不无限打磨。

---

Phase 5: 归档 + 打开

1. date +%Y%m%dT%H%M%S 获取时间戳
2. 写入：
   • 单体：~/Documents/notes/{timestamp}--skill-anatomy-{name}__anatomy.html
   • 对比：~/Documents/notes/{timestamp}--skill-anatomy-{A}-vs-{B}__anatomy.html
   • 提炼：~/Documents/notes/{timestamp}--skill-anatomy-synthesis__anatomy.html
3. open 命令打开浏览器
4. 报告路径，推荐 1-2 个对比对象

---

进化术

前提：解剖已经完成，skill 的结构已经拆清楚了。

Step 1: 听用户的想法

用户说想改什么。比如：

• "我想加上我的使用习惯"
• "我想让输出变成 markdown"
• "我想加一个新功能"
• "这个地方不好用，想改掉"

Step 2: 诊断 + 追问（讨论阶段）

不要直接动手。 先基于解剖结果，做一轮诊断和追问：

1. 定位改动范围：用户想改的东西涉及 skill 的哪些部分？是表层（触发词、输出格式）还是深层（核心流程、质量控制）？
2. 识别信息缺口：用户的想法是否足够具体？如果不够，追问：
   • "你说想加 XX 功能，具体是什么场景下用？"
   • "你说这里不好用，能举个例子吗？"
   • "你想改成什么样？有没有参考对象？"
3. 预判影响链：这个改动会不会牵动其他部分？如果会，提前告知用户。
4. 展示改动方案草案：用大白话描述"我打算这么改"，列出具体动哪几个地方、怎么动。

然后等用户确认。 用户说"可以"或"就这么改"之后，才进入 Step 3。

追问原则：

• 最多追问 2 轮，不要变成审讯
• 如果用户已经说得很清楚，不追问，直接展示方案草案
• 追问的目的是消除歧义，不是展示你多懂

Step 3: 精准指引（执行阶段）

用户确认方案后，给出具体修改指引：

• 在哪里动刀：具体到行号或 section 位置
• 怎么动：给出具体修改内容（"在这里加这段"、"把这段换成那段"）
• 动了之后会影响什么：哪些地方需要同步调整？

Step 4: 分层告知风险

| 层次 | 含义 | 举例 | |------|------|------| | 随便动 | 改了不会坏 | 触发词、输出格式、具体案例、归档路径 | | 小心动 | 改了可能影响其他部分 | 流程顺序、Agent 分工、质量检查条件 | | 别轻易动 | 核心承重，动了可能塌 | 去掉就整个 skill 不好使的部分 |

Step 5: 给出讨论方向

生成 3-5 个具体问题，帮用户知道接下来还可以聊什么：

• "我想在 XX 位置加入 YY，会不会跟 ZZ 冲突？"
• "把输出从 A 改成 B，需要同步调整哪些地方？"

关键原则

• 不重写整个 skill
• 只给最小改动路径
• 每个改动都说清楚影响范围
• 讨论确认之前不动手——先对齐再执行

---

语言风格指南

写 HTML 页面内容时：

• 像跟朋友聊天一样写
• 每个概念配一个 13 岁孩子能懂的类比
• 斜体句子是"规律总结"——从例子中提炼的一句话道理
• 跟其他 skill 对比时，要解释"为什么不同"，不只是列出差异
• 禁止使用：模式基因、设计模式、架构、范式、抽象层、解耦
• 可以使用：手法、招数、设计、选择、结构、流程