【Skill 创作】my-skill-builder：把一个模糊想法做成完整可发布 Skill Creater

SOLO技能创作赛
1

1、Skill 简介

my-skill-builder 是一个面向 Skill 设计、组装、脚手架生成与发布 的 meta-skill。

它和普通 Skill 最大的不同是：它不是解决某个业务问题，而是用来 生成、重构、打包、发布其他 Skill。

我在做这个 Skill 时，真正想解决的是一个很常见新手需解决的问题：

  • 我有一个大概想法，但不知道该做成哪种 Skill

  • 我不知道这个 Skill 该不该有 CLI

  • 我不知道什么时候该加 scripts/，什么时候只写 SKILL.md

  • 我不知道怎么把一个 Skill 做成既能本地用、又能 GitHub 发布的标准包

所以 my-skill-builder 的目标不是“再做一个 Skill 模板”，而是把 判断 → 组装 → 生成 → 发布 这一整条链路做成一个真正可复用的能力。

围绕这个目标，它当前提供了四大核心能力：

  • Skill 类型判断：先判断需求属于哪一类 Skill

  • 结构生成：生成类型化 SKILL.md、references/、scripts/

  • 发布组装：生成 README.md、README.en.md、LICENSE、package.json

  • 标准打包：输出可发布仓库结构和标准 zip 包

它的重点不只是“帮你写文件”，而是帮助你把一个 Skill 真正做成产品形态。

2、使用场景

场景一：只有一个模糊想法，想知道该做成什么类型的 Skill

  • 痛点：很多时候手里只有一句话，比如“我想做一个能自动写周报的 Skill”，但完全不知道应该走知识型、工作流型还是执行器型。

  • 解法：让 my-skill-builder 先做类型判断，再决定结构，而不是一开始就写模板。

场景二：想快速起一个新 Skill，但不想从零搭目录

  • 痛点：每次做新 Skill 都要重复创建目录、写 frontmatter、想结构、补文档，成本很高。

  • 解法：直接用 scaffold 起骨架，根据类型自动生成初始 SKILL.md、references/、scripts/。

场景三：想把一个已有 Skill 重构成更标准的结构

  • 痛点：很多 Skill 一开始只是能用，但越写越乱，后面发现结构不清晰、执行层和说明层混在一起。

  • 解法：把 Skill 重新抽成知识型、路由型、工作流型、执行器型或混合型，再按标准结构重组。

场景四：想把 Skill 发到 GitHub，但不知道怎么做成标准包

  • 痛点：本地能用的 Skill，不等于能公开发布的 Skill。要考虑 README、LICENSE、package.json、安装片段、zip 包等问题。

  • 解法：使用 --publishable 直接生成单 Skill 仓库结构，并写出真实安装片段。

场景五：想做一个可以直接分享给别人安装的 Skill

  • 痛点：很多时候本地目录已经做好了，但别人没法直接下载和复用。

  • 解法：生成标准 skill 包 zip，方便直接分发、解压和安装。

3、创作过程

这个 Skill 的设计核心，围绕的是 “先判断，再生成，最后发布” 这一理念。

我不想让它变成一个只会吐模板的工具，所以整个设计过程大致分成五步。

第一步：确定它是 Meta Skill，而不是普通业务 Skill

如果它只是帮用户写一个 SKILL.md 文件，那本质上它只是一个模板生成器。

但我想让它做的更完整，所以一开始就明确了定位：

  • 它不是业务 Skill

  • 它是 造 Skill 的 Skill

  • 它的职责是帮助开发者完成 Skill 的判断、设计、生成和发布

这样它就不是单一模板，而是一个更高层的 Skill 工厂。

第二步：先做 Skill 类型体系，而不是先写脚本

一个真正有用的 Skill Builder，核心不在“会不会建目录”，而在“能不能先判断类型”。

所以我先把 Skill 抽成五类：

- knowledge

- router

- workflow

- executor

- hybrid

并且把判断逻辑写进 scaffold，这样它不会不分青红皂白地给每个需求都套同一个结构。

第三步：把结构生成做成类型化，而不是统一骨架

这一点非常关键。

如果所有 Skill 的输出都长一样，那最后只是换词填空，价值不大。

所以我把生成层拆成三块：

  • SKILL.md 按类型变化

  • references/overview.md 按类型变化

  • scripts/ 也按类型变化

这样 knowledge、router、workflow、executor、hybrid 不是名字不同，而是结构真的不同。

第四步：把发布能力纳入 Skill 本身，而不是留给人工处理

很多工具只做到“能生成本地结构”，但我觉得这还不够。

真正完整的 Skill 工厂，应该能往前走到发布层，所以我继续补了：

  • README.md

  • README.en.md

  • LICENSE

  • package.json

  • 真实安装片段

  • 标准 zip 包

这一步的意义在于：

Skill 不只是能生成，还能直接进入分享和分发状态。

4、使用步骤

方式一：快速起一个新 Skill

  1. 确定 Skill 名称

  2. 执行最小 scaffold：


node ./scripts/scaffold-skill.js --name weekly-report-skill

  1. 查看生成目录

  2. 继续补充业务内容

方式二：按类型生成标准骨架

  1. 明确 Skill 类型

  2. 执行类型化 scaffold：


node ./scripts/scaffold-skill.js \

--name api-guide-skill \

--type knowledge
  1. 查看对应类型的 SKILL.md 与参考文件

方式三：自动判型生成

  1. 写出名称和大致描述

  2. 执行自动判型：


node ./scripts/scaffold-skill.js \

--name weekly-report-builder \

--description "Builds weekly reports from meeting notes and task context."
  1. 查看推断出来的结构

方式四：生成可发布的 Skill 包

  1. 确定仓库名与输出路径

  2. 执行发布模式：


node ./scripts/scaffold-skill.js \

--name publishable-router \

--type router \

--publishable \

--repo-owner Damond-Fung \

--repo-name my-skill-builder \

--publish-readme-style community \

--target-root ./publish

  1. 检查 README.md、LICENSE、package.json

  2. 上传 GitHub 或打 zip 分发

方式五：生成带真实安装片段的标准仓库

  1. 准备好 GitHub 仓库地址

  2. 执行带仓库参数的生成：


node ./scripts/scaffold-skill.js \

--name repo-executor \

--type executor \

--publishable \

--repo-url https://github.com/Damond-Fung/real-executor-repo \

--publish-readme-style minimal \

--target-root ./publish
  1. 得到可直接展示给别人安装的仓库说明

5、核心文件一览

| 文件 | 作用 | 何时加载 |

|—|—|—|

| SKILL.md | Skill 入口，负责判断、澄清、分型和构建方法论 | 始终加载 |

| scripts/scaffold-skill.js | Scaffold 主脚本，负责生成结构和文件 | 执行生成时 |

| references/overview.md | hybrid 参考说明，承载结构层辅助信息 | 需要补充说明时 |

| README.md | 中文主页，仓库级说明与安装入口 | 仓库查看时 |

| README.en.md | 英文切换页 | 英文读者查看时 |

| package.json | 发布元信息 | 发布时 |

| dist/my-skill-builder-skill-package.zip | 标准 skill 包压缩文件 | 分发时 |

6、脚本生态

当前这个仓库的脚本生态虽然只有一个核心脚本，但它已经承担了完整的 scaffold 生成逻辑：

| 功能 | 脚本 | 说明 |

|—|—|—|

| 命令解析 | scripts/scaffold-skill.js | 负责读取参数、解析类型、决定结构 |

| 模板生成 | scripts/scaffold-skill.js | 负责生成 SKILL.md、references/、scripts/ |

| 发布组装 | scripts/scaffold-skill.js | 负责输出 README、LICENSE、package.json |

脚本使用示例


# 查看帮助

node ./scripts/scaffold-skill.js --help

# 知识型 skill

node ./scripts/scaffold-skill.js --name api-guide-skill --type knowledge

# 工作流型 skill

node ./scripts/scaffold-skill.js --name weekly-report-builder --type workflow

# 可发布 skill 包

node ./scripts/scaffold-skill.js \

--name publishable-router \

--type router \

--publishable \

--repo-owner Damond-Fung \

--repo-name my-skill-builder

7、总结与思考

在做 my-skill-builder 的过程中，我最大的感受是：

一个真正优秀的 Skill，不只是会回答问题，还应该能把自己做成产品。

而要做到这一点，最难的地方往往不是“写内容”，而是：

  • 先判断类型

  • 再决定结构

  • 再决定是否要执行层

  • 最后决定如何发布

这也是我为什么会做这个 Skill。

相比直接做一个业务 Skill，my-skill-builder 更像是一个方法论工具：

  1. 先分类

  2. 再组装

  3. 再生成

  4. 再发布

它最重要的价值，不是某一个模板，而是把“造 Skill 的流程”本身给产品化了。

如果说这个 Skill 当前最重要的设计结论是什么，我会总结为一句话：

做 Skill 的重点，不只是写一个 SKILL.md，而是把 Skill 从想法一路推进到可发布成品。

8、Skill 链接

4 个赞
👾「一切皆可 Skill」SOLO 技能创作赛｜赛事速递 DAY 12（5月29日）
【Skill 测评】My Skill Builder：开发者必备的 Skill 脚手架神器，但新手需要适应期
2

澄清一下：

meta-skill 里的 meta ，本质上就是“ 关于自身这一层 ”或“ 更上一层 ”。

  • skill ：直接解决一个任务

  • meta-skill ：不直接做任务，而是 帮助定义、组织、生成、管理 skill 本身
    所以：

  • meta 是概念

  • meta-skill 是这个概念落到 skill 体系里的具体形态

跟那个公司的meta没有关系哈！！

5 个赞
3

image
image618×180 19.3 KB

5 个赞
4

一个带有reference 和 script 的skill才觉得是比较深度的skill

4 个赞