Leroy
d3e9bd45bd
- SKILL.md 双工作流（创建/迭代）+ 两道门（验料/通用化）+ 三档位 - 7 篇方法论 references + 3 个纯标准库脚本（scaffold/validate/trigger_eval） - 自身触发用例 16 条 + 先例研究/创建/迭代证据报告 - 方法论吸收自 qiaomu-meta-skill 与 luban-skill，取舍见 reports/prior-art.md
129 lines
9.0 KiB
Markdown
129 lines
9.0 KiB
Markdown
---
|
||
name: le-meta-skill
|
||
description: |
|
||
LeMetaSkill —— Leroy 的 Skill 工坊：创建与迭代 Agent Skill，ZCode / Claude Code / Codex 等 runtime 通用。把重复工作流、提示词、SOP、脚本、对话中反复出现的方法，变成可触发、可验证、可维护的 Skill；也负责改进、重构、体检、触发测试已有 Skill。
|
||
何时触发：用户想新建/创建/起草 skill（"帮我做个 skill""把这个流程沉淀成 skill""做成可复用的技能""turn this into a skill"）；想改进/优化/升级/重构/体检已有 skill（"这个 skill 触发不灵""给我的 skill 做个体检""改进这个 skill"）；想为 skill 设计触发测试或结构检查；丢来一个 SKILL.md、skill 目录或想法说"帮我看看怎么弄好"，只要上下文是想让Skill变得可复用，都应触发。
|
||
不要触发：与 skill 无关的普通提示词改写、一次性任务、代码 review、MCP/插件/斜杠命令配置排障。
|
||
metadata:
|
||
author: Leroy
|
||
version: "1.1.0"
|
||
runtimes: zcode, claude-code, codex
|
||
inspiration: joeseesun/qiaomu-meta-skill; LearnPrompt/luban-skill; ZCode skill-creator
|
||
---
|
||
|
||
# LeMetaSkill —— Leroy 的 Skill 工坊
|
||
|
||
把「重复出现的方法」变成「可触发、可验证、可维护的 Skill」。
|
||
|
||
判断放 `references/`，确定性检查放 `scripts/`，触发用例放 `evals/`，运行证据放 `reports/`。本文件只保留路由和最简工作流。
|
||
|
||
## 工坊总则
|
||
|
||
- **单一创建权威。** 本技能触发后，由它负责从意图、先例、蓝图、起草、验证到交付的完整流程；不要再同时调用宿主内置的 `skill-creator` 或其它 meta 技能——双重权威会导致冲突规范和重复提问。只有用户明确要求横向对比创建器、或本技能不可用时才引入其它工具，并说明职责边界。
|
||
- **写准，不写长。** 目标是 description 精准触发、正文精炼可执行。文档更长不等于技能更好；每一条规则都要为稳定性挣到自己的位置。
|
||
- **按档位比例投入。** 复用范围决定档位（见下）。只创建"挣来的"文件——每个文件必须回答它提高了哪方面的稳定性（判断力/确定性/可回归/证据），不造仪式性目录。
|
||
- **证据分级。** 交付时每个亮点标注 `[设计优势]`（源码可见的设计选择）、`[已验证]`（有触发/输出/实测证据）、`[假设]`（合理但未证明）。验证不了的写「证据缺失」，不写漂亮话补位。
|
||
- **中文优先，标识符英文。** 面向 Leroy 的说明、报告默认中文；`name`、目录、代码用英文 kebab-case。
|
||
- **先验证触发，再扩展内容。** description 是唯一的自动触发信号，先让它在真实对话里可靠触发，再扩正文——顺序反了会把房子盖在流沙上。
|
||
|
||
## 第一道门：验料——值不值得做成 Skill
|
||
|
||
动手前先回答（详见 [意图工坊](references/intent-workshop.md)）：
|
||
|
||
1. **重复性**：这类任务会反复出现吗？只出现一次的，做成 skill 是浪费。
|
||
2. **稳定性**：流程和规则相对稳定吗？需要大量实时判断、没有固定流程的，保留为普通对话步骤更好。
|
||
3. **增益**：做成 skill 比每次现场对话强在哪——一致性、触发可靠、携带脚本/模板、跨会话沉淀？说不出来就先不做。
|
||
|
||
```text
|
||
验料结论：[好料 / 料可用但需调整定位 / 朽木——建议保留为对话步骤或先积累案例]
|
||
```
|
||
|
||
判定为朽木时**停手直说**，给出替代路径，不要硬做。
|
||
|
||
## 第二道门：通用化门
|
||
|
||
把单次失败或单例反馈升级为核心规则之前：
|
||
|
||
1. 先改写成领域中立的行为描述（不绑定那个具体项目/文件/那次失误）；
|
||
2. 分类：核心机制、可选适配、还是仅测试用例；
|
||
3. 只有安全、事实、权限类硬边界，或**在两个不相关领域都复现过**的行为，才进 SKILL.md 正文；
|
||
4. 一次性细节放进 fixtures、示例或专项 reference。
|
||
|
||
这条门防的是过拟合：为一次翻车写的规矩，会变成以后每次的摩擦。
|
||
|
||
## 档位
|
||
|
||
| 档位 | 适用 | 必备件 | 验收门 |
|
||
|---|---|---|---|
|
||
| 轻量 draft | 个人试验、自用 | `SKILL.md` | frontmatter 合法、description 有触发词和负触发 |
|
||
| 共享 shared | 团队/跨项目复用 | + `evals/trigger_cases.json`、README 钩子 | 结构体检全绿、触发冒烟测试通过 |
|
||
| 严谨 rigorous | 长期维护的基础能力、meta skill | + `reports/` 证据、参考文档分层 | 共享档全部要求 + 交付报告带证据分级 + 真实对话实测记录 |
|
||
|
||
升级时机：别人开始复用 → draft 升 shared；成为基础设施或多项目依赖 → shared 升 rigorous。默认选最轻的够用档位。
|
||
|
||
## 创建工作流（CREATE）
|
||
|
||
1. **接单**：按 [意图工坊](references/intent-workshop.md) 捕获七要素（重复任务/输入/交付物/排除项/标准/参考/已有资产）。信息足够就直接做并写出假设，不做问卷。
|
||
2. **验料**：过第一道门。不过，停手给替代。
|
||
3. **先例研究**：按 [先例研究](references/prior-art.md) 搜 2–4 个同类，用 `keep/adapt/reject/invent` 提炼机制——只借结构和方法，不复制表达。轻量档可跳过，但要说明为什么。
|
||
4. **蓝图**：定档位和目录结构（见 [目录架构](references/architecture.md)），**先写 description** 再动正文。
|
||
5. **起草**：`python3 scripts/scaffold.py <name> "<一句话职责>" --tier <draft|shared|rigorous>` 生成骨架，按 [写作手艺](references/writing-craft.md) 填充。
|
||
6. **触发验证**：`python3 scripts/trigger_eval.py <skill目录>` 跑冒烟测试，再在真实对话里测 2–3 条用户原话（方法见 [触发测试](references/trigger-eval.md)）。触发不过，回头改 description，不扩内容。
|
||
7. **交付**：按 [交付报告](references/handoff.md) 输出 handoff，亮点标证据等级。
|
||
|
||
## 迭代工作流（ITERATE）
|
||
|
||
改进已有 skill 时（详见 [迭代工坊](references/iteration.md)）：
|
||
|
||
1. **冻结基线**：备份原版（`cp -r` 或 git 分支），所有改动与基线比。
|
||
2. **诊断三把尺**：结构尺（`python3 scripts/validate_skill.py <目录>`）＋触发尺（trigger_eval + 真实对话）＋活体尺（拿真实任务实际跑一遍，"看起来能触发"不等于"跑得出结果"）。
|
||
3. **评分定位**：六维评分（触发与边界/工作流清晰度/可执行具体性/失败模式与停手点/实测表现/资源纪律），每个分数给证据，找出最该刨的一个面。
|
||
4. **单面慢刨**：一轮只改一个面；批量授权后也是单面单提交，绝不混刨。
|
||
5. **验证门**：改动要全部满足——比基线多过至少 2 条测试原话、没把 skill 写得更长但更难用、没引入私有路径或不可复现依赖——才保留，否则回刀。
|
||
6. **交付**：改动报告 + 回炉清单（下一轮入口、本轮不做）。
|
||
|
||
## 核心命令
|
||
|
||
```bash
|
||
python3 scripts/scaffold.py <name> "<一句话职责>" --tier shared # 起草骨架
|
||
python3 scripts/validate_skill.py <skill目录> # 结构体检
|
||
python3 scripts/trigger_eval.py <skill目录> # 触发冒烟测试
|
||
```
|
||
|
||
脚本无第三方依赖，python3 标准库即可运行。
|
||
|
||
## 交付契约
|
||
|
||
只交付所选档位"挣来"的东西：工作中的 skill 目录、通过的体检/触发证据、handoff 报告。不发布（无发布流水线）、不虚构验证结果、不交付用例覆盖不了的承诺。
|
||
|
||
## 强制停手点
|
||
|
||
以下节点必须停下等用户确认：
|
||
|
||
1. 验料判定"朽木"时——给出替代方向后停，不硬做；
|
||
2. 改动会大幅改变 skill 的定位或职责边界时；
|
||
3. 需要删除或重写大段现有内容时；
|
||
4. 新 skill 会与已安装的其它 skill 同名（同名覆盖会改变触发优先级）时；
|
||
5. 迭代中要引入高风险脚本、删除逻辑或外部 API 调用时。
|
||
|
||
## 反例黑名单
|
||
|
||
- 不要把一次性总结、翻译、解释、头脑风暴做成 skill。
|
||
- 不要只改 SKILL.md 正文而不验证触发——description 才是触发信号。
|
||
- 不要为了让 skill 显得专业堆术语、堆 MUST/NEVER；讲清楚为什么，比喊口号有效。
|
||
- 不要把私有路径、密钥、私人账号写进任何文件。
|
||
- 不要在没有两个领域复现证据时，把单例教训升为核心规则。
|
||
- 不要一轮迭代刨多个面；拿到批量授权后也不要把多个面塞进一次改动。
|
||
- 不要让同一只手既"改"又"评"——验收时换成第一次见到这个 skill 的陌生用户视角。
|
||
- 不要凭记忆编造先例；每个参考都带真实 URL，搜不到就如实标注。
|
||
|
||
## Reference Map
|
||
|
||
- 接单与验料：[意图工坊](references/intent-workshop.md)
|
||
- 搜同类：[先例研究](references/prior-art.md)
|
||
- 写 description 与正文：[写作手艺](references/writing-craft.md)
|
||
- 目录怎么摆：[目录架构](references/architecture.md)
|
||
- 触发怎么测：[触发测试](references/trigger-eval.md)
|
||
- 改进已有 skill：[迭代工坊](references/iteration.md)
|
||
- 交付怎么说：[交付报告](references/handoff.md)
|