Open Source Skills：我在把自己蒸馏成 Skill 的路上走出了一小步
起因：那些重复了一百遍的操作
维护开源项目这几年，我逐渐意识到自己的日常工作里有大量「肌肉记忆」式的操作：Issue 进来，先扫一眼有没有复现步骤，判断优先级，写一段礼貌又专业的回复；发版前，翻完 commit 记录整理一份 Release Notes；有人提 PR，根据 diff 写清楚描述和 checklist；新贡献者进来，发现项目连 CONTRIBUTING.md 都没有……
这些事情不难，但极其琐碎。更关键的是，我发现自己处理这些任务时遵循的模式几乎是固定的——判断依据、输出格式、注意事项，都已经内化成了某种「个人 SOP」。每次做的时候，脑子里跑的其实是同一套流程。
这让我产生了一个念头：能不能把这些内化的经验「蒸馏」出来，变成 AI Agent 可以直接使用的能力？
Open Source Skills 就是这次实验的产物。把我在开源维护中积累的经验打包成了一组可复用的 Agent Skill，装到 AI 编程助手里就能直接用。
13 个 Skill，覆盖开源维护全流程
Open Source Skills 仓库目前提供了 13 个 Skill，可以粗略分成几个类别：
项目治理与合规
| Skill | 做什么 |
|---|---|
| open-source-license | 开源许可证选型、兼容性分析、合规检查，支持生成 LICENSE/NOTICE 文件和源文件头，额外支持木兰宽松许可证 v2 |
| open-source-analysis | 输入一个 GitHub 仓库 URL，自动生成包含技术栈、活跃度评分、多维度评价的结构化分析报告（中英双语） |
| openrank-metrics | 基于 OpenDigger 数据源查询 GitHub/Gitee 项目的 OpenRank 值和各项统计指标 |
日常维护自动化
| Skill | 做什么 |
|---|---|
| pr-description | 根据 Git diff 自动生成带 checklist 的 PR 描述 |
| release-notes | 从 commit 记录提取并分类生成结构化发版说明（Breaking Change / Feature / Fix） |
| issue-triage | 分析 Issue 内容，评估优先级，检查缺失信息，生成专业回复模板 |
| contributor-guide-writer | 分析项目结构和构建工具，自动生成贴合项目的 CONTRIBUTING.md |
开发工具增强
| Skill | 做什么 |
|---|---|
| git-helper | Git 命令助手，将意图翻译为具体命令，对破坏性操作提供安全警告 |
| dockerfile-optimizer | 审查 Dockerfile，给出多阶段构建、层缓存优化、安全加固等建议 |
| rfc-writer | 将模糊的技术想法扩写为标准的 RFC 文档 |
| cli-help-writer | 将零散的命令行参数转化为符合 POSIX 标准的 --help 文案 |
| prompt-reviewer | 审查 Prompt，找出歧义、遗漏约束和潜在幻觉风险 |
| readme-grader | 从多个维度评估 README 质量并给出改进建议 |
这些 Skill 之间没有强依赖关系，你可以按需单独安装，也可以一次性全部装上。
怎么装、怎么用
快速安装
最简单的方式是一条命令装完整个仓库：
| |
如果只需要其中某一个 Skill：
| |
Claude Code Plugin 安装
如果你使用 Claude Code，还可以通过 Plugin Marketplace 方式安装：
| |
然后用 /plugin browse 浏览并选择需要的 Skill。或者直接安装：
| |
Clawhub 安装
如果你使用 OpenClaw，也可以通过 Clawhub 来安装：
| |
更多的安装命令可以前往 https://skills.guoxudong.io 查看。
实际使用
安装完成后不需要额外配置，Skill 会根据你的提问自动触发。举几个例子：
许可证选型——直接问：
我应该给这个 SDK 选 MIT 还是 Apache-2.0？
项目分析——丢一个 URL 进去：
Issue 分诊——粘贴 Issue 内容：
帮我分诊一下这个 Issue：组件在设置了 props.disabled 时子元素不显示了
生成发版说明——贴上 commit 记录：
帮我根据这些 commit 记录生成发版说明： feat(auth): 新增企业微信登录 fix(db): 修复并发导致的数据死锁 BREAKING CHANGE: 移除 v1 API
用起来和直接对话没有区别，只是 Agent 现在知道了一套更加结构化、更加专业的处理方式。
谁适合用
如果你是：
- 开源项目维护者，每天要处理 Issue、审 PR、写 Release Notes——这是最直接的受众。
- 团队 Tech Lead，希望统一团队在 AI 辅助开发中的行为规范——把这些 Skill 装到项目级配置里，所有人用同一套标准。
- 对 Agent Skill 生态感兴趣的开发者——这个仓库本身也是一个不错的 Skill 编写参考，每个 Skill 都有清晰的结构和评测样例。
结语：在把自己蒸馏成 Skill 的路上走出了一小步
最近总是听到：离职的同事并没有离开，他们只是被重新编译成了 Token、Prompt 和 Skill。
表述虽然多为调侃，但是道理是存在的。时代在不断的前行，技术也在不断的进步，他并不会因为你的抱怨而改变，能做的只是适应与提升，经历不被时代所抛下。
目前这 13 个 Skill 覆盖的还只是开源维护中最表层、最模式化的部分。但至少，这是走出去的一小步。把经验从大脑搬到 SKILL.md 的过程，本身就是一次有价值的自我审视。而且这些蒸馏出来的东西是可以被别人安装、使用、改进的——它不再只是我一个人的肌肉记忆，而是变成了一种可以流动的资产。