很多 Claude Skill 在本地能跑，却很难发布出去。
原因通常不是功能完全不可用，而是缺少产品化打磨：别人不知道它解决什么问题，不清楚为什么要安装，也不知道运行后会得到什么结果。README 写得再整齐，如果没有清晰触发条件、失败边界、安装路径和可验证产物，这个 Skill 仍然只是一个“自己电脑上能用”的工作流。
鲁班 Skill 要解决的就是这个断层：把一个粗糙但能用的 Skill，升级成一个可以公开发布、被别人安装、被 Agent 稳定调用的 Skill。
它本质上不是普通的“提示词润色器”，而是一个专门用来升级 Skill 的 Skill。
Skill 为什么需要升级流程
Claude Skill 可以理解为一套可复用的 Agent 能力包，通常包含：
SKILL.md：说明 Skill 何时触发、如何工作、有哪些边界。- 脚本或资源文件：可选，用于执行自动化任务。
- README：面向人类用户，解释安装、使用和效果。
- 示例与测试 Prompt：证明这个 Skill 能在真实场景中工作。
很多人创建 Skill 时，会直接告诉 Agent：“帮我把这个需求打包成 Skill。”这样确实可以快速得到一个能跑的版本，但能跑不等于能发布。
一个可发布 Skill 至少要跨过三道门槛：
| 阶段 | 关键问题 | 常见失败 |
|---|---|---|
| 能运行 | Agent 能不能按说明完成任务 | 触发条件模糊、步骤缺失 |
| 能理解 | 用户能不能快速知道它干什么 | README 首屏没有价值说明 |
| 能复用 | 别人能不能稳定跑出结果 | 没有测试 Prompt、没有失败处理 |
如果只是让 Agent “优化一下 SKILL.md”，它往往会补几个标题、扩写描述、整理格式。这些改动有帮助，但不会自动解决定位、差异化、验证和发布的问题。
鲁班 Skill 把升级过程拆成一条完整流水线。
flowchart TD
A[已有 Skill] --> B[挑战前提]
B --> C[寻找同类项目]
C --> D[横纵分析]
D --> E[Darwin 评分]
E --> F[候选改写]
F --> G[验证门]
G --> H{是否通过}
H -- 否 --> F
H -- 是 --> I[发布级 Skill]
这条流程的重点是：先判断这个 Skill 值不值得存在，再决定怎么改，而不是一上来就改文档。
第一步：挑战前提，判断它为什么值得安装
鲁班 Skill 会先扮演产品经理的角色，追问几个基础问题：
- 这个 Skill 解决的真实问题是否成立？
- 用户为什么要安装它，而不是临时问 Agent？
- 它的独特性来自方法论、脚本资产、私有经验、数据、工作流，还是展示效果？
- 它有没有一句话能讲清楚的传播钩子？
- 它运行后有没有截图、报告、网页、差异对比等可展示结果？
可以把这一步理解为“安装理由审查”。
一个 Skill 如果只是把普通提示词包了一层文件，很难让别人主动安装。用户安装 Skill 的理由，通常来自下面几类：
| 安装理由 | 说明 | 示例 |
|---|---|---|
| 省步骤 | 把重复操作固定成流程 | 自动生成技术调研报告 |
| 降低门槛 | 把复杂经验封装成检查清单 | 新项目发布前审查 README |
| 交付稳定 | 每次输出结构一致 | 生成固定格式的周报 |
| 连接资源 | 内置脚本、模板、数据源 | 聚合公开数据并生成页面 |
| 形成风格 | 保持多个产物一致 | 统一一组 Skill 的命名和文档风格 |
如果这些问题答不上来，后面再怎么润色 README 都很难救回来。
一个可用的定位模板可以这样写：
这个 Skill 帮助【目标用户】在【具体场景】中完成【高频任务】，
输出【可验证产物】，相比临时问 Agent，它能减少【关键成本】。
例如：
这个 Skill 帮助已经写过本地 Skill 的用户，在准备开源发布前完成定位审查、
竞品分析、文档重写和测试验证，输出升级后的 SKILL.md、README 和测试 Prompt。
相比临时问 Agent，它能避免每次都重新设计发布标准。
定位越具体，后续的命名、README、示例、测试 Prompt 越容易统一。
第二步：寻找同类项目，不靠想象做升级
很多 Skill 的迭代失败，是因为改进建议完全来自凭空讨论。鲁班 Skill 会要求 Agent 去找同类型项目，看它们为什么被收藏、安装和传播。
搜索对象可以分成三类：
| 类型 | 查什么 | 目的 |
|---|---|---|
| 直接同类 | 同主题 Skill、Agent 工作流、SKILL.md 仓库 |
找功能差距 |
| 间接同类 | 相近场景的工具、模板、脚本 | 找表达方式 |
| 展示标杆 | README、Showcase、Demo 做得好的项目 | 学发布包装 |
搜索词不应该只用 Skill 名称，而要拆成三组：
功能词：它做什么，例如 skill optimizer、agent workflow、readme generator
人群词：谁会用，例如 Claude user、AI builder、open source maintainer
形态词：以什么形式存在，例如 skill、agent skill、SKILL.md、Claude skill
一次合理的搜索分工可以这样设计：
子 Agent 1：搜索 GitHub 上的同类仓库
子 Agent 2：搜索 Skill 目录和 Agent 工具市场
子 Agent 3：深读指定对标项目的 README、安装路径、Demo 和 Release
这一步的目标不是复制别人的功能，而是看清楚市场里已经存在的表达方式和用户预期。一个 Skill 如果想被安装，至少要让用户一眼看出它和同类工具有什么不同。
第三步：用横纵分析确定生态位
鲁班 Skill 的核心判断方法可以概括为“纵向看演进，横向看竞争”。
纵向分析关注这个 Skill 自己从哪里来、要往哪里走：
| 纵向问题 | 判断目的 |
|---|---|
| 它最初解决什么具体痛点 | 确定真实需求 |
| 它现在是工具、方法论、工作流，还是自动化系统 | 确定产品形态 |
| 它从私用走向公开还缺什么 | 确定升级重点 |
| 下一版应该增强功能、展示、安装、适配还是验证 | 确定迭代方向 |
横向分析关注同类项目凭什么立足：
| 横向维度 | 检查点 |
|---|---|
| 命名钩子 | 名字是否容易记住，是否能暗示用途 |
| 一句话定位 | 是否用人话说清楚解决什么问题 |
| 安装摩擦 | 是否一条命令或少量步骤即可安装 |
| 首屏信任 | README 首屏是否有截图、GIF、结果样例、真实数据 |
| 可验证产物 | 跑完后是否得到报告、网页、JSON、diff、测试结果 |
| 安全边界 | 是否说明不会乱删文件、泄露数据、擅自请求外部服务 |
| 生态兼容 | 是否说明兼容哪些 Agent runtime |
| 故事感 | 是否解释为什么现在需要这个 Skill |
这两个方向交叉后，才会得到真正有价值的生态位判断。
flowchart LR
A[纵向分析: 自身演进] --> C[生态位判断]
B[横向分析: 同类竞争] --> C
C --> D[改功能]
C --> E[改文档]
C --> F[改安装路径]
C --> G[改验证方式]
例如，一个 AI 新闻聚合项目表面上看是在做“更好的新闻站”，但横纵分析后可能发现，真正有差异的不是页面，而是它在 GitHub Pages 上暴露了一份静态 JSON 数据。
这意味着它可以被描述成一个开放数据接口：
- 不需要鉴权。
- 不依赖后端服务。
- 可以被 fork。
- 可以用
curl直接读取。 - 可以被其他 Agent 或 Skill 当作数据源。
这类判断比“再加几个页面功能”更重要，因为它改变了项目对外表达的重点。
第四步：用 Darwin 评分找出最该打磨的地方
鲁班 Skill 不会只给一堆泛泛建议，而是用固定维度给 Skill 做体检。评分不是为了好看，而是为了决定优先改哪里。
一套实用的评分维度可以这样设计：
| 维度 | 检查内容 | 权重倾向 |
|---|---|---|
| Frontmatter 与触发条件 | Agent 什么时候应该调用它 | 高 |
| 工作流清晰度 | 步骤是否能按顺序执行 | 高 |
| 失败模式 | 出错、缺文件、权限不足时怎么处理 | 高 |
| 检查点 | 每个阶段有没有可确认结果 | 中 |
| 可执行具体性 | 是否有明确命令、路径、输入输出 | 高 |
| 资源整合度 | 是否用好脚本、模板、外部数据 | 中 |
| 整体架构 | 文件结构和职责是否清晰 | 中 |
| README 表达 | 人类用户能否快速理解 | 中 |
| 实测表现 | 是否有测试 Prompt 和真实输出 | 最高 |
其中“实测表现”应该放在最高权重。一个 Skill 写得再漂亮，如果没有测试 Prompt、没有前后对比、没有真实输出样例，就不能证明它升级成功。
评分结果可以转换成优先级：
80 分以上：可以做发布前精修
60～79 分：需要补齐验证、文档或失败处理
60 分以下：先重做定位和核心工作流
这能避免 Agent 一直在不重要的地方打磨措辞，却忽略了最影响安装和复用的部分。
第五步：候选改写，每轮只改一个主要变量
鲁班 Skill 借鉴了 SkillOpt 的思路：把 Skill 文档看成一个可优化状态，通过多轮候选改写和验证逐步变好。
关键点是每轮只改一个主要方向。
如果这一轮修触发词，就不要顺手重写 README；如果这一轮补失败模式，就不要同时加一堆 Showcase。否则结果变好了，也不知道到底是哪一个改动起作用。
flowchart TD
A[当前 Skill] --> B[选择一个优化方向]
B --> C[生成候选版本]
C --> D[运行测试 Prompt]
D --> E[对比旧版本结果]
E --> F{是否通过验证门}
F -- 是 --> G[接受候选版本]
F -- 否 --> H[丢弃或重写候选]
H --> C
G --> I[进入下一轮优化]
常见优化方向包括：
| 优化方向 | 目标 | 不该顺手做什么 |
|---|---|---|
| 触发条件 | 让 Agent 更准确调用 Skill | 不重写完整 README |
| 工作流步骤 | 让执行过程更稳定 | 不改项目定位 |
| 失败模式 | 让异常场景有处理方案 | 不新增无关功能 |
| Showcase | 让用户看到实际效果 | 不改内部流程 |
| 安装路径 | 降低上手成本 | 不扩展复杂依赖 |
验证门可以设置得很明确：
1. 至少 2 个典型测试 Prompt 的输出优于旧版。
2. README 首屏能在 10 秒内说明价值。
3. 安装路径没有新增明显摩擦。
4. 输出产物可见、可检查、可复现。
5. 安全边界比旧版更清楚。
有了验证门，Skill 升级就不再是“感觉写得更好”，而是有标准、有对比、有取舍。
一个发布级 Skill 应该包含什么
一个适合开源的 Skill，不需要一开始就很复杂，但要把核心信息交代清楚。
推荐结构如下：
my-skill/
├── SKILL.md
├── README.md
├── examples/
│ ├── prompt-01.md
│ └── prompt-02.md
├── scripts/
│ └── optional-helper.sh
└── outputs/
└── sample-result.md
SKILL.md 面向 Agent，重点是触发和执行：
# Skill Name
## When to use
Use this skill when the user wants to upgrade an existing Claude Skill
from a private workflow into a publishable open-source Skill.
## Inputs
- Path to an existing Skill directory
- Current README, if available
- Target audience or release goal, if specified
## Workflow
1. Inspect the current Skill structure.
2. Challenge the product premise.
3. Search comparable Skills and tools.
4. Score the Skill across release-readiness dimensions.
5. Propose focused candidate improvements.
6. Validate improvements with test prompts.
## Safety
Do not delete user files without explicit confirmation.
Do not publish, push, or upload anything unless the user asks.
README 面向人类用户，重点是价值和上手：
# Luban Skill
Upgrade a private Claude Skill into a publishable Skill with positioning,
competitive analysis, release-readiness scoring, focused rewrites, and test prompts.
## What it produces
- Improved SKILL.md
- README recommendations
- Release-readiness score
- Test prompts
- Before/after comparison notes
这两个文件职责不同。SKILL.md 要让 Agent 稳定执行，README 要让用户快速决定要不要安装。
鲁班 Skill 的完整工作流
把前面的阶段串起来，鲁班 Skill 可以抽象成五个角色协作：
| 角色 | 负责内容 | 输出 |
|---|---|---|
| 掌柜 | 判断真实问题和安装理由 | 定位结论 |
| 行脚 | 搜索同类项目和展示标杆 | 竞品分析 |
| 师爷 | 做横纵分析和生态位判断 | 升级方向 |
| 量尺师傅 | 按维度评分 | 体检报告 |
| 慢刨 | 单变量候选改写并验证 | 可接受改动 |
对应的执行流程是：
sequenceDiagram
participant User as 用户
participant Luban as 鲁班 Skill
participant Agent as 子 Agent
participant Repo as Skill 仓库
User->>Luban: 提供待升级 Skill
Luban->>Repo: 读取 SKILL.md 与 README
Luban->>Luban: 挑战前提与安装理由
Luban->>Agent: 并行搜索同类项目
Agent-->>Luban: 返回竞品与展示案例
Luban->>Luban: 横纵分析生态位
Luban->>Luban: Darwin 评分
Luban->>Repo: 生成候选改写
Luban->>Repo: 运行测试 Prompt 对比结果
Luban-->>User: 输出升级建议与可发布版本
这个流程的价值在于，它把“写 Prompt”推进到了“做产品”。Skill 不再只是一次性提问，而是一套可以安装、触发、验证、传播的工作方式。
适合和不适合使用鲁班 Skill 的场景
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 已经有本地 Skill，准备开源 | 适合 | 最需要定位、文档、测试和发布检查 |
| 有一套重复工作流，想沉淀成 Skill | 适合 | 可以先补安装理由和触发条件 |
| README 很乱，但功能已经稳定 | 适合 | 能通过 Showcase 和验证样例提升可信度 |
| 只有一个临时 Prompt，没有稳定场景 | 不太适合 | 应先确认高频需求是否存在 |
| 需要自动执行高风险操作 | 谨慎使用 | 必须先设计权限、安全边界和确认步骤 |
| 只是想让文字更好看 | 不必使用完整流程 | 普通文档润色已经足够 |
鲁班 Skill 最适合处理“已经有雏形，但还没达到发布标准”的项目。它不保证每个 Skill 都会受欢迎，但能在发布前把关键问题问清楚。
实际上手步骤
准备一个已经能用的 Skill 目录，然后让 Agent 使用鲁班 Skill 做升级审查。输入信息越完整，结果越稳定。
建议提供这些材料：
1. Skill 目录路径
2. 当前 SKILL.md
3. 当前 README.md
4. 目标用户
5. 希望发布的平台，例如 GitHub
6. 2～3 个典型使用场景
7. 不允许改动的边界，例如不能新增外部依赖
可以直接给 Agent 这样的任务：
使用鲁班 Skill 升级这个 Claude Skill。
目标：
- 判断它是否具备公开发布价值
- 搜索同类 Skill 或 Agent 工作流
- 给出横纵分析和生态位判断
- 按发布标准评分
- 每轮只改一个主要方向
- 生成至少 2 个测试 Prompt
- 输出升级后的 SKILL.md 和 README 修改建议
限制：
- 不要删除现有文件
- 不要自动发布到 GitHub
- 不要新增必须联网才能运行的依赖
如果项目已经准备开源，可以再加一条：
请重点检查 README 首屏是否能在 10 秒内说明价值，并补充一个可截图展示的输出样例。
发布前检查清单
发布 Skill 前，可以用这份清单做最终验收：
| 检查项 | 合格标准 |
|---|---|
| 定位 | 一句话能讲清楚谁在什么场景下用它 |
| 触发 | Agent 能判断什么时候该调用它 |
| 输入 | 用户知道需要提供哪些文件或信息 |
| 输出 | 运行后有明确、可见、可检查的产物 |
| 失败处理 | 缺文件、权限不足、联网失败时有处理方案 |
| 安全边界 | 明确说明不会擅自删除、上传、发布 |
| 安装路径 | 步骤少，前置条件清楚 |
| Showcase | 有截图、样例、报告或对比结果 |
| 测试 Prompt | 至少覆盖两个典型场景 |
| 差异化 | 能说清楚比临时问 Agent 强在哪里 |
如果一个 Skill 能通过这些检查，它就不再只是本地自用的小工具，而是一个别人能理解、能安装、能跑通的工作流资产。
Skill 真正重要的地方，不是把提示词保存成文件，而是把反复发生的复杂任务沉淀成稳定方法。鲁班 Skill 做的事情，就是把这个沉淀过程标准化：先确认问题，再找到位置，然后评分、改写、验证，直到它具备被公开复用的基本条件。