oss-skills： 18 个开源开发技能，让 Agent 像资深维护者一样做开源

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

一、装完之后是什么效果

你：   我想把这个内部工具开源。

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 直接装插件：

/plugin marketplace add the-open-agent/oss-skills

/plugin install oss-skills@the-open-agent

其他能读 SKILL.md 目录的 Agent ，clone 过去就行：

git clone https://github.com/the-open-agent/oss-skills ~/.claude/skills/oss-skills

只想要其中一个技能，直接扒走：

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 —— 校验 frontmatter 、name 与目录是否一致、description 长度、交叉引用的技能是否存在、相对链接是否死掉。还会警告「 description 里没写触发条件」，因为 description 是唯一常驻上下文的部分，写不好这个技能就永远不会被加载。
scripts/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

Apache-2.0 。觉得有用点个 star ，有意见直接开 issue 或者在下面回复，我都看 🙏