oss-skills： 18 个开源开发技能，让 Agent 像资深维护者一样做开源
veotax: Hi V 友们 👋
现在的 Agent 写代码基本够用了。但真把一个项目开源出去，写代码可能只占 20%，剩下 80% 是这些事：
- 选哪个许可证？ Apache-2.0 和 MIT 到底差在哪
- 这个改动算 minor 还是 major ？改个默认值算不算 breaking
- CI 为什么在 fork 的 PR 上永远是红的
- 有人提了个 3000 行的 PR ，我不想合，怎么关掉才不至于把人得罪走
- 发了个坏版本，是该删掉还是该 deprecate
这些问题的答案 Agent 大多答不准，或者答得很「正确但没用」——比如你问它 semver 怎么办，它跟你说「请仔细遵守语义化版本规范」。
所以我做了 **oss-skills**：18 个按需加载的 Agent 技能，把这部分判断力补上。
GitHub: [https://github.com/the-open-agent/oss-skills](https://github.com/the-open-agent/oss-skills)
---
## 一、装完之后是什么效果
你： 我想把这个内部工具开源。
Agent：[加载 open-source-playbook → repo-bootstrap → license-and-legal]
先读了仓库。有三件事得排在其他所有事情前面：
1. commit 8f3a91c 里有一个 AWS key （ src/config.py ，在 4b2e 被删掉了）。
它仍然在历史记录里 —— 去轮换掉。重写历史属于清理，不属于补救。
2. 没有 LICENSE 。按现状，任何人在法律上都不可以使用这个项目。
Apache-2.0 合适：你们有企业贡献者，专利授权条款是有意义的。
3. README 只有一行。对 95% 的访客来说，那就是整个产品页。
先处理密钥，还是先处理许可证？
重点不是它答得漂亮，而是它**先去读了仓库**，并且知道「历史里的密钥必须轮换」这种事优先级高于写 README 。
---
## 二、18 个技能，分五条线
| 线 | 技能 |
| ---- | ----------------------------------------------------------------------------------------------------------------- |
| 地基 | `open-source-playbook`（入口，先诊断阶段再路由）、`repo-bootstrap`、`license-and-legal` |
| 工程功底 | `api-design`、`testing-strategy`、`code-review`、`refactor-safely`、`performance-benchmarking` |
| 自动化 | `ci-pipelines`、`release-engineering`、`supply-chain-security`、`dependency-hygiene` |
| 社区 | `readme-that-converts`、`docs-architecture`、`issue-triage`、`contributor-experience`、`launch-and-growth` |
| 可持续 | `governance-and-sustainability` |
用法上建议从 `open-source-playbook` 开始，它会先判断你的项目处在哪个阶段（发布前 / 已发布没人知道 / 有人用没人贡献 / 被依赖 / 机构化），再把你导到具体技能。其余的会在命中触发条件时自己加载。
---
## 三、写这些技能时立的三条规矩
**1. 给判定表，不给原则。**
这是最重要的一条。比如 semver 那张表，直接把常见的判断写死：
| 改动 | 版本号 |
|--------------------------|-----------------|
| 加一个可选参数 | minor |
| 加一个必填参数 | **major** |
| 改一个默认值 | **major**（行为静默变化，最坏的一种）|
| 提高最低运行时版本（ Node 18→20 ）| **major** |
| 改 error message | patch |
| 改 error type | **major** |
| 收紧输入校验 | **major**（原来能跑的输入现在报错了） |
「提高最低 Node 版本算 major 」是能直接用的；「请认真遵守 semver 」不能。
**2. 把反模式明说出来。**
比如 CI 那个技能里写死了一条：`pull_request_target` 触发器 **加上** 检出 PR head ，等于把你的 secrets 交给任意一个提 PR 的人执行。这一条的价值，比一整段「 CI 最佳实践」高。
再比如发布出问题时：**deprecate ，不要删版本**。`npm unpublish` 会把所有已经锁定这个版本的 lockfile 全部搞崩，包括那些本来一点事没有的人。
**3. 社交那一半也写进去。**
这是我觉得大部分工程指南缺的部分。`code-review` 里有一节是「怎么体面地关掉一个 PR 」，`governance-and-sustainability` 里有一节是倦怠——不是鸡汤，是可执行的：缩范围、把机械劳动自动化、加维护者、在 README 里公开写「我周日上午处理这个项目」。
`code-review` 里还有一条我自己踩过的：**review 意见要标严重程度**。`blocking:` / `question:` / `suggestion:` / `nit:`，不标的话贡献者根本不知道哪条是必须改的，然后就跑了。
---
## 四、怎么装
Claude Code 直接装插件：
```bash
/plugin marketplace add the-open-agent/oss-skills
```
```bash
/plugin install oss-skills@the-open-agent
```
其他能读 [SKILL.md](http://skill.md/) 目录的 Agent ，clone 过去就行：
```bash
git clone https://github.com/the-open-agent/oss-skills ~/.claude/skills/oss-skills
```
只想要其中一个技能，直接扒走：
```bash
curl -sL https://raw.githubusercontent.com/the-open-agent/oss-skills/main/skills/release-engineering/SKILL.md \
-o .claude/skills/release-engineering/SKILL.md
```
验证装没装上，问一句就知道：
> 「把最低 Node 版本从 18 提到 20 ，算 minor 还是 major ？」
答 **major** 并且能说出「在版本范围内升级的用户会直接构建失败」，就是生效了。
---
## 五、工程上做了什么
技能这东西容易写成一堆没人管的 markdown ，所以加了点约束：
- **[`scripts/validate_skills.py`](http://validate_skills.py/)**—— 校验 frontmatter 、name 与目录是否一致、description 长度、交叉引用的技能是否存在、相对链接是否死掉。还会警告「 description 里没写触发条件」，因为 description 是唯一常驻上下文的部分，写不好这个技能就永远不会被加载。
- **[`scripts/check_readme_parity.py`](http://check_readme_parity.py/)**—— 任何一个 README 漏掉某个技能，CI 直接红。多语言文档最常见的腐烂方式就是翻译版悄悄少了一节，这个检查把它变成 CI 失败而不是半年后才发现。
- **9 种语言的 README**—— 英文 + 简中 / 繁中 / 日 / 韩 / 西 / 法 / 德 / 葡(BR)。
- 技能正文只维护英文版，故意的：它是给模型读的，一份维护，改一处全局生效；翻译版一旦滞后就会静默地发出错误的命令。
顺便，这个仓库自己是按里面的技能建的——issue 表单、CONTRIBUTING 、SECURITY 、CI 全套。这算是唯一能拿出手的自证。
---
## 六、坦白说几句
- **不适合谁**：如果你只是想让 Agent 帮你写个函数、解释一下 git ，这东西对你没用，纯占目录。它针对的是「要把项目开出去 / 已经开出去但没人来」这个场景。
- **技能正文全是英文**。理由上面说了。你用中文提问它照样中文回答，但技能文件本身不翻译。
- **有些内容是有立场的**，不是中立综述。比如默认推荐 DCO 而不是 CLA 、BSL/SSPL 我直接写了「这不是开源」、大部分情况下反对推倒重写。你不同意的话，欢迎来 issue 里吵，我确实可能是错的。
- **最想要的反馈是纠错**。如果哪条建议你在真实项目里试过、结果不是那样，来提个 issue 说说发生了什么。仓库里专门开了一个 `correction` 的 issue 模板，这类 issue 优先级最高——一条来自真实维护经验的纠错，比新加一个技能有价值。
---
仓库： [https://github.com/the-open-agent/oss-skills](https://github.com/the-open-agent/oss-skills)
Apache-2.0 。觉得有用点个 star ，有意见直接开 issue 或者在下面回复，我都看 🙏
---
原文链接：[点击查看](https://www.v2ex.com/t/1232916)
现在的 Agent 写代码基本够用了。但真把一个项目开源出去，写代码可能只占 20%，剩下 80% 是这些事：
- 选哪个许可证？ Apache-2.0 和 MIT 到底差在哪
- 这个改动算 minor 还是 major ？改个默认值算不算 breaking
- CI 为什么在 fork 的 PR 上永远是红的
- 有人提了个 3000 行的 PR ，我不想合，怎么关掉才不至于把人得罪走
- 发了个坏版本，是该删掉还是该 deprecate
这些问题的答案 Agent 大多答不准，或者答得很「正确但没用」——比如你问它 semver 怎么办，它跟你说「请仔细遵守语义化版本规范」。
所以我做了 **oss-skills**：18 个按需加载的 Agent 技能，把这部分判断力补上。
GitHub: [https://github.com/the-open-agent/oss-skills](https://github.com/the-open-agent/oss-skills)
---
## 一、装完之后是什么效果
你： 我想把这个内部工具开源。
Agent：[加载 open-source-playbook → repo-bootstrap → license-and-legal]
先读了仓库。有三件事得排在其他所有事情前面：
1. commit 8f3a91c 里有一个 AWS key （ src/config.py ，在 4b2e 被删掉了）。
它仍然在历史记录里 —— 去轮换掉。重写历史属于清理，不属于补救。
2. 没有 LICENSE 。按现状，任何人在法律上都不可以使用这个项目。
Apache-2.0 合适：你们有企业贡献者，专利授权条款是有意义的。
3. README 只有一行。对 95% 的访客来说，那就是整个产品页。
先处理密钥，还是先处理许可证？
重点不是它答得漂亮，而是它**先去读了仓库**，并且知道「历史里的密钥必须轮换」这种事优先级高于写 README 。
---
## 二、18 个技能，分五条线
| 线 | 技能 |
| ---- | ----------------------------------------------------------------------------------------------------------------- |
| 地基 | `open-source-playbook`（入口，先诊断阶段再路由）、`repo-bootstrap`、`license-and-legal` |
| 工程功底 | `api-design`、`testing-strategy`、`code-review`、`refactor-safely`、`performance-benchmarking` |
| 自动化 | `ci-pipelines`、`release-engineering`、`supply-chain-security`、`dependency-hygiene` |
| 社区 | `readme-that-converts`、`docs-architecture`、`issue-triage`、`contributor-experience`、`launch-and-growth` |
| 可持续 | `governance-and-sustainability` |
用法上建议从 `open-source-playbook` 开始，它会先判断你的项目处在哪个阶段（发布前 / 已发布没人知道 / 有人用没人贡献 / 被依赖 / 机构化），再把你导到具体技能。其余的会在命中触发条件时自己加载。
---
## 三、写这些技能时立的三条规矩
**1. 给判定表，不给原则。**
这是最重要的一条。比如 semver 那张表，直接把常见的判断写死：
| 改动 | 版本号 |
|--------------------------|-----------------|
| 加一个可选参数 | minor |
| 加一个必填参数 | **major** |
| 改一个默认值 | **major**（行为静默变化，最坏的一种）|
| 提高最低运行时版本（ Node 18→20 ）| **major** |
| 改 error message | patch |
| 改 error type | **major** |
| 收紧输入校验 | **major**（原来能跑的输入现在报错了） |
「提高最低 Node 版本算 major 」是能直接用的；「请认真遵守 semver 」不能。
**2. 把反模式明说出来。**
比如 CI 那个技能里写死了一条：`pull_request_target` 触发器 **加上** 检出 PR head ，等于把你的 secrets 交给任意一个提 PR 的人执行。这一条的价值，比一整段「 CI 最佳实践」高。
再比如发布出问题时：**deprecate ，不要删版本**。`npm unpublish` 会把所有已经锁定这个版本的 lockfile 全部搞崩，包括那些本来一点事没有的人。
**3. 社交那一半也写进去。**
这是我觉得大部分工程指南缺的部分。`code-review` 里有一节是「怎么体面地关掉一个 PR 」，`governance-and-sustainability` 里有一节是倦怠——不是鸡汤，是可执行的：缩范围、把机械劳动自动化、加维护者、在 README 里公开写「我周日上午处理这个项目」。
`code-review` 里还有一条我自己踩过的：**review 意见要标严重程度**。`blocking:` / `question:` / `suggestion:` / `nit:`，不标的话贡献者根本不知道哪条是必须改的，然后就跑了。
---
## 四、怎么装
Claude Code 直接装插件：
```bash
/plugin marketplace add the-open-agent/oss-skills
```
```bash
/plugin install oss-skills@the-open-agent
```
其他能读 [SKILL.md](http://skill.md/) 目录的 Agent ，clone 过去就行：
```bash
git clone https://github.com/the-open-agent/oss-skills ~/.claude/skills/oss-skills
```
只想要其中一个技能，直接扒走：
```bash
curl -sL https://raw.githubusercontent.com/the-open-agent/oss-skills/main/skills/release-engineering/SKILL.md \
-o .claude/skills/release-engineering/SKILL.md
```
验证装没装上，问一句就知道：
> 「把最低 Node 版本从 18 提到 20 ，算 minor 还是 major ？」
答 **major** 并且能说出「在版本范围内升级的用户会直接构建失败」，就是生效了。
---
## 五、工程上做了什么
技能这东西容易写成一堆没人管的 markdown ，所以加了点约束：
- **[`scripts/validate_skills.py`](http://validate_skills.py/)**—— 校验 frontmatter 、name 与目录是否一致、description 长度、交叉引用的技能是否存在、相对链接是否死掉。还会警告「 description 里没写触发条件」，因为 description 是唯一常驻上下文的部分，写不好这个技能就永远不会被加载。
- **[`scripts/check_readme_parity.py`](http://check_readme_parity.py/)**—— 任何一个 README 漏掉某个技能，CI 直接红。多语言文档最常见的腐烂方式就是翻译版悄悄少了一节，这个检查把它变成 CI 失败而不是半年后才发现。
- **9 种语言的 README**—— 英文 + 简中 / 繁中 / 日 / 韩 / 西 / 法 / 德 / 葡(BR)。
- 技能正文只维护英文版，故意的：它是给模型读的，一份维护，改一处全局生效；翻译版一旦滞后就会静默地发出错误的命令。
顺便，这个仓库自己是按里面的技能建的——issue 表单、CONTRIBUTING 、SECURITY 、CI 全套。这算是唯一能拿出手的自证。
---
## 六、坦白说几句
- **不适合谁**：如果你只是想让 Agent 帮你写个函数、解释一下 git ，这东西对你没用，纯占目录。它针对的是「要把项目开出去 / 已经开出去但没人来」这个场景。
- **技能正文全是英文**。理由上面说了。你用中文提问它照样中文回答，但技能文件本身不翻译。
- **有些内容是有立场的**，不是中立综述。比如默认推荐 DCO 而不是 CLA 、BSL/SSPL 我直接写了「这不是开源」、大部分情况下反对推倒重写。你不同意的话，欢迎来 issue 里吵，我确实可能是错的。
- **最想要的反馈是纠错**。如果哪条建议你在真实项目里试过、结果不是那样，来提个 issue 说说发生了什么。仓库里专门开了一个 `correction` 的 issue 模板，这类 issue 优先级最高——一条来自真实维护经验的纠错，比新加一个技能有价值。
---
仓库： [https://github.com/the-open-agent/oss-skills](https://github.com/the-open-agent/oss-skills)
Apache-2.0 。觉得有用点个 star ，有意见直接开 issue 或者在下面回复，我都看 🙏
---
原文链接：[点击查看](https://www.v2ex.com/t/1232916)
评论
暂无评论。