sponsor-finder

Sponsor Finder

发现支持项目依赖背后开源维护者的机会。接受 GitHub owner/repo（例如 /sponsor expressjs/express），使用 deps.dev API 进行依赖解析并获取项目健康数据，并生成一份友好的赞助报告，涵盖直接和间接依赖。

工作流

当用户输入 /sponsor {owner/repo} 或提供 owner/repo 格式的仓库时：

1. 解析输入 — 提取 owner 和 repo。
2. 检测生态系统 — 获取清单文件以确定包名称 + 版本。
3. 获取完整依赖树 — deps.dev GetDependencies（一次调用）。
4. 解析仓库 — 对每个依赖调用 deps.dev GetVersion → relatedProjects 给出 GitHub 仓库。
5. 获取项目健康数据 — 对唯一仓库调用 deps.dev GetProject → OSSF Scorecard。
6. 查找资助链接 — npm funding 字段、FUNDING.yml、网络搜索作为后备。
7. 验证每个链接 — 获取每个 URL 以确认其可访问。
8. 分组并报告 — 按资助目标分组，按影响力排序。

---

步骤 1：检测生态系统和包

使用 get_file_contents 从目标仓库获取清单文件。确定生态系统并提取包名称 + 最新版本：

文件	生态系统	包名称来自	版本来自
package.json	NPM	name 字段	version 字段
requirements.txt	PYPI	包名称列表	使用最新版本（在 deps.dev 调用中省略版本）
pyproject.toml	PYPI	[project.dependencies]	使用最新版本
Cargo.toml	CARGO	[package] name	[package] version
go.mod	GO	module 路径	从 go.mod 提取
Gemfile	RUBYGEMS	gem 名称	使用最新版本
pom.xml	MAVEN	groupId:artifactId	version

---

步骤 2：获取完整依赖树（deps.dev）

这是关键步骤。 使用 web_fetch 调用 deps.dev API：

https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{PACKAGE}/versions/{VERSION}:dependencies

例如：

https://api.deps.dev/v3/systems/npm/packages/express/versions/5.2.1:dependencies

这会返回一个 nodes 数组，其中每个节点包含：

• versionKey.name — 包名称
• versionKey.version — 解析后的版本
• relation — "SELF"、"DIRECT" 或 "INDIRECT"

这一次调用即可获得整个依赖树 — 包括直接和间接依赖 — 并带有精确的解析版本。无需解析锁文件。

URL 编码

包含特殊字符的包名称必须进行百分号编码：

• @colors/colors → %40colors%2Fcolors
• 将 @ 编码为 %40，/ 编码为 %2F

对于没有单一根包的仓库

如果仓库不发布包（例如，它是应用而非库），则回退到直接读取 package.json 依赖并针对每个依赖调用 deps.dev GetVersion。

---

步骤 3：将每个依赖解析到 GitHub 仓库（deps.dev）

对于依赖树中的每个依赖，调用 deps.dev GetVersion：

https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{NAME}/versions/{VERSION}

从响应中提取：

• relatedProjects → 查找 relationType: "SOURCE_REPO" → projectKey.id 给出 github.com/{owner}/{repo}
• links → 查找 label: "SOURCE_REPO" → url 字段

这适用于所有生态系统 — npm、PyPI、Cargo、Go、RubyGems、Maven、NuGet — 且字段结构相同。

效率规则

• 按每次 10 个分批处理。
• 去重 — 多个包可能映射到同一个仓库。
• 跳过未找到 GitHub 项目的依赖（计为“无法解析”）。

---

步骤 4：获取项目健康数据（deps.dev）

对于每个唯一的 GitHub 仓库，调用 deps.dev GetProject：

https://api.deps.dev/v3/projects/github.com%2F{owner}%2F{repo}

从响应中提取：

• scorecard.checks → 查找 "Maintained" 检查 → score（0–10）
• starsCount — 流行度指标
• license — 项目许可证
• openIssuesCount — 活跃度指标

使用 Maintained 分数标记项目健康度：

• 分数 7–10 → ⭐ 积极维护
• 分数 4–6 → ⚠️ 部分维护
• 分数 0–3 → 💤 可能未维护

效率规则

• 仅对 唯一仓库 拉取（而非每个包都拉取）。
• 以 每次 10 个 为一批处理。
• 此步骤是可选的 — 若受速率限制则跳过，并在输出中注明。

---

步骤 5：查找资助链接

对每个唯一的 GitHub 仓库，按顺序使用三个来源检查资助信息：

5a：npm funding 字段（仅 npm 生态）

对 https://registry.npmjs.org/{package-name}/latest 使用 web_fetch，并检查 funding 字段：

• 字符串： "https://github.com/sponsors/sindresorhus" → 用作 URL
• 对象： {"type": "opencollective", "url": "https://opencollective.com/express"} → 使用 url
• 数组： 收集所有 URL

5b：.github/FUNDING.yml（先仓库级，再组织级回退）

步骤 5b-i — 逐仓库检查： 使用 get_file_contents 获取 {owner}/{repo} 路径下的 .github/FUNDING.yml。

步骤 5b-ii — 组织/用户级回退： 若 5b-i 返回 404（仓库本身没有 FUNDING.yml），检查该 owner 的默认社区健康仓库： 使用 get_file_contents 获取 {owner}/.github 路径下的 FUNDING.yml。

GitHub 支持默认社区健康文件约定：用户/组织级的一个 .github 仓库为所有缺少自身配置的仓库提供默认值。例如，isaacs/.github/FUNDING.yml 适用于所有 isaacs/* 仓库。

每个唯一的 {owner}/.github 仓库只查找 一次 — 对该 owner 下的所有仓库复用结果。以 每次 10 个 owner 为一批处理。

解析 YAML（5b-i 和 5b-ii 相同）：

• github: [username] → https://github.com/sponsors/{username}
• open_collective: slug → https://opencollective.com/{slug}
• ko_fi: username → https://ko-fi.com/{username}
• patreon: username → https://patreon.com/{username}
• tidelift: platform/package → https://tidelift.com/subscription/pkg/{platform-package}
• custom: [urls] → 原样使用

5c：网络搜索回退

对 前 10 个未获资助的依赖项（按传递依赖者数量），使用 web_search：

"{package name}" github sponsors OR open collective OR funding

跳过已知由企业维护的包（React/Meta、TypeScript/Microsoft、@types/DefinitelyTyped）。

效率规则

• 对所有依赖项检查 5a 和 5b。 仅对排名靠前的未获资助项使用 5c。
• 对非 npm 生态跳过 npm registry 调用。
• 仓库去重 — 每个仓库只检查一次。
• 每个唯一 owner 只检查一次 {owner}/.github — 对其所有仓库复用结果。
• 以 每次 10 个 owner 为一批处理组织级查找。

---

步骤 6：验证每个链接（关键）

在包含任何资助链接之前，验证其存在。

对每个资助 URL 使用 web_fetch：

• 有效页面 → ✅ 包含
• 404 / “未找到” / “未注册” → ❌ 排除
• 重定向到有效页面 → ✅ 包含最终 URL

以 每次 5 个 为一批进行验证。绝不呈现未验证的链接。

---

步骤 7：输出报告

输出规范

在数据收集过程中尽量减少中间输出。 不要逐一宣布每批（“第 3 批，共 7 批……”、“现在检查资助……”）。而应：

• 在开始每个主要阶段时显示 一行简短状态（例如，“正在解析 67 个依赖项……”、“正在检查资助链接……”）
• 在生成报告前收集所有数据。 绝不零散地输出部分表格。
• 在最后以 单个完整块 的形式输出最终报告。

报告模板

## 💜 Sponsor Finder Report

**Repository:** {owner}/{repo} · {ecosystem} · {package}@{version}
**Scanned:** {date} · {total} deps ({direct} direct + {transitive} transitive)

---

### 🎯 Ways to Give Back

Sponsoring just {N} people/orgs supports {sponsorable} of your {total} dependencies — a great way to invest in the open source your project depends on.

1. **💜 @{user}** — {N} direct + {M} transitive deps · ⭐ Maintained
   {dep1}, {dep2}, {dep3}, ...
   https://github.com/sponsors/{user}

2. **🟠 Open Collective: {name}** — {N} direct + {M} transitive deps · ⭐ Maintained
   {dep1}, {dep2}, {dep3}, ...
   https://opencollective.com/{name}

3. **💜 @{user2}** — {N} direct dep · 💤 Low activity
   {dep1}
   https://github.com/sponsors/{user2}

---

### 📊 Coverage

- **{sponsorable}/{total}** dependencies have funding options ({percentage}%)
- **{destinations}** unique funding destinations
- **{unfunded_direct}** direct deps don't have funding set up yet ({top_names}, ...)
- All links verified ✅

报告格式规则

• 以“🎯 回馈方式”开头 —— 这是主要输出。使用编号列表，按覆盖的依赖总数降序排列。
• 裸 URL 单独一行 —— 不要包裹在 markdown 链接语法中。这能确保它们在任何终端模拟器中都可点击。
• 内联依赖名称 —— 在每个赞助者下方用一行以逗号分隔列出所覆盖的依赖名称，让用户清楚看到自己在资助什么。
• 健康指示符内联显示 —— 在每个目标旁显示 ⭐/⚠️/💤，而不是放在单独的表格列中。
• 只设一个“📊 覆盖情况”部分 —— 紧凑的统计信息。不要单独的“已验证资助链接”表格，也不要“未找到资助”表格。
• 未获资助的依赖以简短说明呈现 —— 只写数量 + 主要名称。措辞用“尚未设置资助”，而不是强调缺口。绝不要因项目没有资助而使其难堪 —— 许多维护者更偏好其他形式的贡献。
• 💜 GitHub Sponsors，🟠 Open Collective，☕ Ko-fi，🔗 其他
• 当同一维护者存在多个资助来源时，优先使用 GitHub Sponsors 链接。

---

错误处理

• 如果 deps.dev 对该包返回 404 → 回退为直接读取清单，并通过注册表 API 解析。
• 如果 deps.dev 被限流 → 注明结果不完整，继续使用已获取的内容。
• 如果 get_file_contents 对该仓库返回 404 → 告知用户仓库可能不存在或为私有。
• 如果链接验证失败 → 静默排除该链接。
• 即使结果不完整也始终生成报告 —— 绝不静默失败。

---

关键规则

1. 绝不展示未验证的链接。 在显示每个 URL 之前先抓取它。5 个已验证链接 > 20 个猜测链接。
2. 绝不根据训练知识猜测。 始终核实 —— 资助页面会随时间变化。
3. 始终保持鼓励，绝不羞辱。 以积极方式呈现结果 —— 庆祝已获得资助的部分，并将未获资助的依赖视为机会，而非失败。并非每个项目都需要或希望获得资金赞助。
4. 以行动开头。 “🎯 回馈方式”部分是主要输出 —— 裸可点击 URL，按目标分组。
5. 使用 deps.dev 作为主要解析器。 仅在 deps.dev 不可用时回退到注册表 API。
6. 始终使用 GitHub MCP 工具（get_file_contents）、web_fetch 和 web_search —— 绝不克隆或调用 shell。
7. 保持高效。 批量调用 API，去重仓库，每个所有者的 .github 仓库只检查一次。
8. 聚焦 GitHub Sponsors。 这是最具可操作性的平台 —— 展示其他平台，但优先 GitHub。
9. 按维护者去重。 分组展示赞助一个人所带来的真实影响。
10. 展示可操作的最小方案。 告诉用户用最少的赞助支持最多的依赖。
11. 尽量减少中间输出。 不要逐批宣布。收集所有数据，然后输出一份连贯的报告。