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 或者在下面回复，我都看 🙏
yidinghe 08-08 19:461楼
Alliot 08-10 01:062楼
chjqpmain 08-10 02:123楼