为什么选这个项目

oomol-lab/open-connector，给 AI agent 用的开源鉴权网关，Pipedream / Composio 的开源替代品。数据：约 6k star、550+ fork，4 个月 23 个 release，非常活跃。

选它有三个理由：

1. 项目够大：6k star 的项目，PR 被合并是硬通货，写在简历上不用解释
2. 新人友好：贡献指南完善，自带 .codex/skills/add-provider/SKILL.md，按步骤走就行
3. 方向对口：我是网络安全方向，安全类 provider 是我的舒适区

选什么贡献：先调研"空位"

没急着动手，先把安全类 provider 的现状摸了一遍：

Provider	状态
virustotal	已有
shodan	已有
abuseipdb	已有
urlscan	已有
censys	已有
greynoise	缺失（404）

GreyNoise 是知名 IP 信誉/噪音分类 API，有免费社区版（免 key，IPv4 only）。别人都做了、就它没人做，这就是切入点。

看最近 20 个合并 PR 的规律，社区新人主要成功提两类：新增 provider 连接器、文档类。核心代码基本是维护者在做，新手不建议碰。

动手：4 个文件

以社区已合并的 PR #697（ScanMalware）为模板：

• definition.ts：Provider 定义（service id、displayName、categories、authTypes），约 18 行
• actions.ts：Action 定义 + input/output schema，用项目自带的 s 构建器
• runtime.ts：实际调 API 的逻辑，用 provider-runtime.ts 的 request helpers
• executors.ts：executor 接线

坑1：description 不能照搬。规范明确要求 action description 用自己的话重写，不许照搬厂商文档。我第一版直接从 GreyNoise 官网抄了一段，被自己的检查清单拦下来重写了。

坑2：definition.ts 不能 import executors.ts。executor 是懒加载的，定义文件里引用会导致循环依赖。这个在 AGENTS.md 里有写，但很容易忽略。

本地验证：三项全绿才敢提

npm run generate:catalog
# 生成 catalog，1613 个 providers

npm run fix-check
# lint + format + typecheck，零报错

node scripts/check-action-examples.ts
# 19091/19091 通过

坑3：绝不手改生成文件。generate:catalog 会改一堆生成文件，PR 里只提交自己写的 4 个文件，生成文件的 diff 不能带上去。我是用单 commit 推送，提交前 git status 确认只有 4 个文件。

提 PR 时遇到的权限坑

坑4：fork 按钮点不了。GitHub App 没有 fork 权限，常规的 fork → clone → PR 流程走不通。

解决方法：改走 Git Trees API，用代理凭证直接把 commit 推到自己账号的 fork 仓库，再从网页开 PR。PR #716：feat(providers): add GreyNoise provider，分支 feat/greynoise-provider，单 commit，无生成文件噪音。

等合并

PR 开完不是结束。我建了个每 30 分钟检查一次的监测脚本，盯着：新评论、review 意见、CI 结论、合并状态。有实质动态才通知，没变化就静默。

结果：当天被合并，无人工 review 意见（只有 coderabbit bot 的自动摘要），说明代码质量一次过关。

复盘

做对的三件事：

1. 选项目时看"新人 PR 合并记录"，不只看 star 数——有的项目 star 高但不收外部 PR
2. 选方向时找"空位"而不是去卷已有的，调研现状这步不能省
3. 提 PR 前本地把三项检查全跑通，不给 reviewer 找茬的机会

给想试的人的建议：先从 docs 类或新增 provider 类入手，别一上来就改核心代码。读 CONTRIBUTING.md 比读代码更重要。遇到权限、流程问题别硬刚，换条路走通就行。