| name | skill-gardener |
| description | 一个 Skill 培育系统，从"零数据即可用的静态专家审查"到"有日志时的深度经验培育"分档提供 SKILL.md 优化。当用户提到"打磨 skill""优化 skill""升级 skill""诊断 skill""评估 skill""改进 skill""审查 skill""skill 不好用""这个 skill 写得怎么样""让我的 skill 变好""我的 skill 该怎么发展""skill 该拆吗""improve a skill""audit a skill""optimize a skill""make this skill better"时必须触发此 Skill。当用户分享一个 SKILL.md 文件寻求反馈时触发，当用户抱怨某个 Skill 输出质量不稳定时触发，当用户想系统性检查或规划自己 Skill 库时触发。适用于功能型、审美型、创作型三类 Skill。A tiered Skill cultivation system for Claude Code and Codex: zero-data static expert review, log-based deep cultivation, health tracking, and roadmap guidance. |
Skill Gardener
一个园丁，而不是训练员。Skill 是有生命的长期资产。这套系统观察每个 Skill 的表现、诊断具体的失败、提出多样化的修复、追踪它的成长轨迹、规划它的未来方向。没有魔法数字，没有单一评分，只有基于证据的培育。
三档深度：先能立刻用，再谈深挖（v2 核心，务必先读）
旧版只有一条重型路径——它建立在"真实调用日志"上，但工具默认不自动记日志，于是用户被迫走低置信度的冷启动，得到一套繁重仪式却没有 day-1 价值，也没有"进化感"。v2 按你实际拥有的数据和精力分三档，从最轻、最立刻可用的开始：
| 档 | 指令 | 需要什么 | 一句话 |
|---|
| 快速档（默认起点） | ~tune [skill] | 零数据 | 资深作者式静态审查 SKILL.md，一轮内在副本上修好结构/触发/过期/示例等不需要数据就能确认的问题，给 before/after。多数 skill 到这一步就明显变好了。 |
| 深度档 | ~cultivate [skill] | 真实日志 | 有日志、且静态问题修完后，用多候选竞技场+验证集压榨"哪个措辞更好/风格保真/输出稳定"这类必须靠证据的质量。 |
| 规划档 | ~roadmap [skill] | 判断力 | 不改细节，帮你想方向：该拆分/废弃/加能力/合并/重新分类吗。 |
配套：~health 追踪每个 skill 的成长轨迹（让进化可感知，见 references/health-card.md）；~capture 帮你把日志真正记起来（见 references/log-capture.md）。
决策很简单： 没数据 → ~tune（几乎总是先做这个）。修完静态问题、又有日志想继续深挖 → ~cultivate。细节都打磨过了还觉得差点意思 → ~roadmap 看是不是方向问题。
双引擎：~tune/~roadmap/~health 是主 Agent 自己做的静态工作，Claude Code 和 Codex 都能跑。~cultivate 的多子 agent 竞技场在 Claude Code 下用 Task 子代理；Codex 下退化为主 Agent 顺序扮演（见竞技场 dry-run 模式），或用回溯档降低对并行的依赖。
为什么做这个
目前大多数 Skill 审查工具都依赖 LLM 生成一个单一分数。这种做法在三个层面上是脆弱的。
第一，Skill 的质量本质上是多目标的。一个 Skill 可以在"意图匹配"上变好的同时在"风格保真度"上变差。压缩成一个数字意味着隐藏了所有设计权衡。
第二，合成测试 prompt 的信噪比很低。两三条凭想象写出来的测试 prompt 无法代表真实使用分布，还非常容易过拟合。
第三，让一个刚写完改进方案的 LLM 来评价这个方案，本身就不可信。同模型、同上下文、同偏好。
Skill Gardener 用三个方向的替换解决这些问题：成对偏好 替代绝对评分、真实调用日志 替代合成 prompt、多候选锦标赛 替代单点爬山。系统还按 Skill 类型分流评估逻辑——审美型 Skill 和功能型 Skill 绝对不能用同一套 rubric 打分。
核心原则
-
在真实使用上评估，不靠想象。 每个被培育的 Skill 都积累自己的调用日志。优化环节从日志里抽取评估 prompt，绝不用 Claude 凭空生成的"用户可能会这样问"作为测试集。优化时严格区分训练集和验证集，任何时候都不允许验证集泄露到训练流程里。
-
优先成对比较，而非绝对打分。 不去问"这个 Skill 值 78 分还是 82 分"，而是拿两个版本在同一个 prompt 上对比，问"哪个输出更好、为什么"。成对判断更稳定、更可审计、直接给出选择所需的信号。
-
先生成多样性，再做选择。 每一轮改进不是生成 1 个候选，而是从不同策略类别生成 4-6 个候选并进入锦标赛。这才是逼近"进化"的唯一方式——单候选迭代只是穿了马甲的爬山。
-
尊重 Skill 类型。 功能型、审美型、创作型 Skill 有各自的失败模式和成功标准。一套万能 rubric 套在三类 Skill 上，会无声地损坏那些不匹配 rubric 假设的类型。详见 references/skill-types.md。
-
积累的是用户的品味，不只是 Skill 的版本。 每当用户在险胜候选之间投下关键一票，这次投票都会进入一个持续增长的品味数据库。随着时间推移，评估裁判将被用户自己的真实偏好所校准——跨 Skill、跨会话、跨月跨年。
-
提炼原则，而不只是应用 diff。 当一次优化成功时，把它教给我们的通用经验写下来。一个具体修复如果能传递一条跨 Skill 的原则，它的价值比一次只改一个 Skill 的 diff 高十倍。
-
对不确定性保持诚实。 当两个候选的差距落在噪声带内时，如实说，问人。假装决断比把决定权交还给用户更糟糕。
命令
自然语言在任何地方都可用。以下简短命令供熟练用户使用。
| 命令 | 自然语言触发 | 作用 |
|---|
~tune [skill] | "审查 X""快速优化 X""帮我看看 X 写得怎么样" | 零数据快速档：静态专家审查 + 在副本上修高置信问题 + before/after（见 references/quick-review.md） |
~cultivate [skill] | "深度培育 X""用日志优化 X" | 深度档：诊断、多候选、竞技场、验证集、提交（需真实日志） |
~roadmap [skill] | "X 该怎么发展""X 该拆吗""规划我的 skill 库" | 规划档：拆分/废弃/扩展/合并/重分类 方向评估（见 references/roadmap.md） |
~health [skill] | "X 现在怎么样""显示成长轨迹" | 查看单个或全库 skill 的健康档案与进步轨迹（见 references/health-card.md） |
~capture | "帮我记日志""怎么让日志自动记" | 配置日志捕获 hook 或结构化回溯数据（见 references/log-capture.md） |
~diagnose [skill] | "诊断 X""X 问题出在哪" | 仅分析，不改 Skill 文件（快速档的诊断部分，不落改动） |
~anchor [skill] | "给 X 建锚点" | 为审美/创作型 Skill 建立或更新风格锚点（深度档前置） |
~log [skill] | "看看 X 的调用日志" | 查看指定 Skill 累积的使用记录 |
~principles | "显示原则库" | 浏览跨 Skill 原则库 |
~taste | "显示品味数据库" | 查看或导出用户偏好历史 |
~review | "显示培育历史" | 所有 Skill 的优化记录概览 |
如果省略 Skill 名称，Skill Gardener 会请用户从可用 Skill 中选择一个。默认建议：不确定用哪个时，从 ~tune 开始。
首次安装设置
首次调用时检测安装目录下是否存在 _runtime/ 文件夹。如果没有，运行设置流程：
-
创建 _runtime/principles.md、_runtime/taste-db.jsonl、_runtime/logs/。
-
请用户把现有的 Skill 按类型分类——功能型 / 审美型 / 创作型 / 混合型。参考 references/skill-types.md 理解四类的区别。分类结果存入 _runtime/skill-registry.yaml。
-
告诉用户两件事：
- 现在就能用：
~tune 快速档零数据可跑，先用它把不需要证据就能确认的问题（结构 bug、触发词、过期事实、缺示例）修掉——多数 skill 到这一步已明显变好。不要因为"没日志"就什么都不做。
- 想深挖就配日志：
~cultivate 深度档需要真实调用日志。用 ~capture 立刻配上自动记录 hook（五分钟一劳永逸），并把手头已有的几次结果做回溯。数据积累起来后，深度档才跑得出高置信度结论。日志三条路径（自动 hook / 会话回溯 / 冷启动兜底）详见 references/log-capture.md。
诚实排序：没数据优先 ~tune，而不是冷启动 ~cultivate——静态审查往往比冷启动合成 prompt 更准更省。
深度培育循环（~cultivate）
这是深度档，需要真实日志。跑它之前，先用 ~tune 做过静态审查——不需要数据就能修的问题应该已经修完，深度档只用来压榨"必须靠证据"的质量（哪个措辞更好、风格保真、输出稳定）。没有日志时不要跑这个，用 ~tune。
由 ~cultivate [skill] 触发。共八个阶段。
阶段 1 — 准备
确认目标 Skill 存在。读取它的 manifest（格式详见 references/skill-types.md）。如果没有 manifest，先通过与用户对话生成一份并保存在 Skill 同目录。判断 Skill 类型：功能型、审美型、创作型或混合型。
检查使用日志。如果日志少于 10 条：不要硬跑深度档。告诉用户深度档需要证据，建议改走 ~tune（静态审查，零数据也能显著改进），并用 ~capture 开始积累日志，两周后再回来深度培育。
安全落点：优先在副本 <skill>.gardener-draft/ 上工作。若 skill 恰在 git 仓库内，额外建分支 gardener/<skill-name>/YYYYMMDD-HHMM 更好，但不以 git 仓库为前提——不在 git 下就用副本+diff。
阶段 2 — 诊断
加载 references/failure-modes.md。对 Skill 类型相关的每一种失败模式，在使用日志里扫描实例。输出一份按优先级排序的失败报告：
- 有哪些失败模式出现、各出现多少次、对应日志条目的索引
- 哪个失败模式的"频率 × 严重度"最高——这就是本轮目标
把失败报告展示给用户。停下来等确认，再进入阶段 3。用户可以调整方向："这次先不管 X，集中处理 Y。"
阶段 3 — 生成候选
加载 references/candidate-strategies.md。针对目标失败模式，从不同类别里挑选 4-6 个候选策略——不是"加一条约束"的 5 种变体，那不是多样性。多样性优先于表面合理性。
每个策略派一个独立子 agent 去写具体改动。每个子 agent 收到：
- 当前完整的 SKILL.md
- 目标失败模式及其证据
- 它应该应用的具体策略
- 一条约束：不能改 Skill 的核心意图，只能改它实现意图的方式
每个子 agent 返回：
- 新的 SKILL.md 版本
- 一段说明："改了什么、为什么改"
- 一句对可能副作用的预判
所有候选存入 _runtime/logs/<skill-name>/cultivation-<timestamp>/candidates/。此时绝不合并回 Skill 目录。
阶段 4 — 竞技场
加载 references/arena-protocol.md。从使用日志里按 60/40 抽样——60% 作为竞技场的训练 prompt 集（本阶段使用），40% 作为验证 prompt 集（阶段 6 使用，期间任何时候都不能接触）。
对每一对候选、每一条训练 prompt，派一个裁判子 agent执行：
- 收到两份输出 A 和 B，不知道哪个是哪个候选生成的
- 输出偏好（A / B / 平局）+ 一句理由
- 交换 A 和 B 的位置再跑一次，检测位置偏差
- 如果交换后判断翻转，这场比赛记为平局
统计胜负和平局，计算胜率。对审美型和创作型 Skill，额外运行锚点检查（详见 references/anchor-system.md）：候选与风格锚点的偏离超过阈值则被直接取消资格，不论它在竞技场表现如何。
阶段 5 — 人类仲裁（条件触发）
如果冠军候选领先第二名的胜率差在噪声带以内——默认胜率差小于 15%，或决胜局小于 8 场——本轮结果被标记为"险胜"，需要用户仲裁：
- 展示前 2-3 个候选的胜率
- 精选 3-5 场"分歧最大的对决"：不是两个候选输出很像的那种 prompt，而是产生明显差异的那些
- 请用户逐对投票，可选附上理由
- 每一票写入
_runtime/taste-db.jsonl
用户的投票决定最终冠军。如果用户拒绝投票，竞技场前几名胜出，但整体结果会被标记为"弱偏好"。
如果领先优势没有落在噪声带内，竞技场独立决策。
阶段 6 — 验证集校验
把冠军候选在验证集上跑一遍——那 40% 从未参与竞技场的 prompt。同时把原始 Skill 在同一批 prompt 上跑一遍。用和阶段 4 相同的裁判协议做成对比较。
如果冠军在验证集上仍胜出：改进得到确认。
如果冠军在验证集上打平或落后：检测到过拟合。报告给用户，默认建议拒绝。用户可以手动覆盖，但默认行为是拒绝。
阶段 7 — 提交和学习
如果冠军通过了阶段 6：
- 把新 SKILL.md 写入副本（用户确认后再覆盖原 Skill 目录）
- 若在 git 仓库内，在 gardener 分支上
git commit，message 记录：目标失败模式、获胜策略、竞技场与验证集胜率、培育日志路径；不在 git 下则把这些写进培育日志 outcome.md
- 更新健康档案。 在
_runtime/logs/<skill-name>/health.md 里把本轮解决的失败模式标为"已解决（cultivate, vN，验证集 X% 胜）"，追加版本轨迹条目（格式见 references/health-card.md）——这是让用户看到"进化"的地方
- 提炼原则。 让一个子 agent 接收前后 diff、失败模式、获胜策略，用一段话总结"这次学到的通用经验"，标记适用的 Skill 类型，追加到
_runtime/principles.md。
- 请用户审核，决定覆盖原 Skill / 合并分支，还是再迭代一轮。
如果没有候选通过所有关卡：不提交任何改动。写一份 _runtime/logs/<skill-name>/cultivation-<timestamp>/outcome.md 说明原因——竞技场无决断、验证集否决、锚点不通过等。询问用户是否换一个失败模式再试，或者本轮停止。
阶段 8 — 报告
给出一份干净的总结：
- 本轮目标失败模式
- 获胜策略（或：无获胜者）
- 竞技场胜率、验证集胜率
- 观察到的副作用，或确认没有副作用
- 本轮提炼出的新原则（如果有）
- 健康档案已更新：本轮划掉了哪个失败模式、当前还剩哪些（用
~health <skill> 看完整轨迹）
- 下一步建议：再来一轮、换一个失败模式、跑
~roadmap 看方向、或本次到此为止
不要用单一分数总结。如果用户问"到底有没有变好？"，用证据回答："在验证集的 40 场配对对决中，新版本赢 23 场、旧版本赢 9 场、平局 8 场。本轮针对的冗余膨胀失败模式，在验证集采样里从 31% 降到 8%。"
三种 Skill 类型的差异化处理
完整定义见 references/skill-types.md。这里给简短版——每类 Skill 如何影响循环流程：
功能型 Skill（工作流自动化、数据处理、API 集成）：重点放在真实调用日志上的竞技场。风格锚点权重低。常见失败模式：意图偏移、格式违约、过度约束。
审美型 Skill（设计、排版、视觉生成）：锚点是强制的。 培育开始之前，用户必须先建立 5-10 个正向锚点（喜欢的输出）和 3-5 个负向锚点（不对味的输出）。竞技场照跑，但锚点相似度是硬门槛。候选赢了竞技场却偏离锚点，照样被否决。
创作型 Skill（写作、故事、创意）：上述两类的结合，外加专门的 AI 味检测器。常见失败模式：套路化措辞、语气漂移、过度结构化输出。用户仲裁触发得更频繁，因为创作审美更难委托给 LLM。
混合型 Skill：先处理主导维度，次要维度作为硬性把关。
何时应该拒绝或延后
以下情况不要运行培育流程：
- 深度档（
~cultivate）在 Skill 日志少于 5 条、且用户拒绝提供回溯数据或锚点时。说清楚原因：没有证据的经验性"优化"是表演——但这时不要两手一摊，改走 ~tune 快速档，静态审查零数据也能显著改进。
- 用户要一个"综合评分"或"总评"。解释这个系统刻意不产出单一分数，并提供失败报告作为更有用的替代。
- 用户想优化一个不属于他的 Skill。培育会修改 SKILL.md；先确认所有权。
- Skill 的核心意图本身不清晰。一个说不清"成功长什么样"的 Skill 没法被优化。先跑 manifest 生成子流程。
约束规则
- 永不改变 Skill 的声明意图，只优化它实现意图的方式。manifest 是契约。
- 文件大小不超过原始的 150%，除非用户明确要求重写。
- 不引入新的外部依赖——新脚本、新引用、新网络调用——除非用户明确同意。
- 绝不就地覆盖原 skill。 所有 gardener 工作先在副本
<skill>.gardener-draft/ 上做，给用户 before/after，确认后再覆盖。若在 git 仓库内，用 gardener/* 分支更佳；不在 git 下副本+diff 同样安全。不要求用户的 skills 目录是 git 仓库。
- 绝不跳过验证集。 验证集为空时优化直接停止，必须由用户补充更多日志数据。
- 绝不在任何输出里把评估压缩成单一分数。
- 尊重停止请求。 用户说"停"就立即停并如实汇报当前状态。
输出礼仪
好的报告应该：
- 结论先行——改进 / 不变 / 拒绝——过程在后
- 先证据——比赛场次、具体 prompt、diff 高亮——后结论
- 明确标注置信等级："强偏好""弱偏好""冷启动估计"
- 用人话命名失败模式，避免术语堆砌
好的报告不应该：
- 给出一个单一综合分数
- 宣称未经验证集确认的"改进"
- 把被淘汰的候选藏起来——要列出来，带上它们的胜率
- 使用庆祝性语言——"太棒了""有进步"——如实陈述结果就好
引用文件
按阶段按需加载：
references/quick-review.md — 快速档（~tune）：零数据静态专家审查的六维清单与安全修复流程references/log-capture.md — 日志捕获（~capture）：自动 hook 配置、会话回溯、冷启动兜底references/health-card.md — 健康档案（~health）：让进化可感知的成长轨迹格式references/roadmap.md — 规划档（~roadmap）：拆分/废弃/扩展/合并/重分类 方向引导references/skill-types.md — Skill 类型分类、manifest 格式、每类的专属逻辑references/failure-modes.md — 失败模式目录，每种带检测启发和示例（~tune 与 ~cultivate 共用）references/candidate-strategies.md — 改进策略菜单，按失败模式组织references/arena-protocol.md — 成对比较和裁判 agent 的详细协议（含省算力的冠军-基线默认模式）references/anchor-system.md — 风格锚点如何建立、维护、评估
运行时状态——首次使用时创建，不随包发布：
_runtime/principles.md — 积累的跨 Skill 原则_runtime/taste-db.jsonl — 用户偏好投票，每行一票_runtime/skill-registry.yaml — 每个 Skill 的类型分类和 manifest 路径_runtime/logs/<skill-name>/ — 使用日志、培育记录、子 agent 输出
关于诚实的一点说明
这个系统不是魔法。它不能在没有真实失败数据的前提下，把烂 Skill 变成好 Skill。它不能在没有用户参考样本的前提下评估审美质量。它不能证明"超出验证集能说明的那部分"改进。
它能做的事是：用证据暴露具体失败、生成多样化的修复候选、让它们在真实 prompt 上竞争、在独立验证集上确认胜出者没有过拟合、随着时间累积原则库和品味数据库让价值复利。
把它当成你和你的 Skill 之间的长期关系，不是一次性优化器。价值按月按年复利，不是按分钟。
