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