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 — 活动指标

使用维护分数标记项目健康状态：

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

效率规则

• 仅获取唯一仓库（不是每个包）。
• 每次批量处理 10 个。
• 此步骤可选 — 如果遇到速率限制则跳过，并在输出中注明。

---

步骤 5：查找资金链接

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

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

使用 web_fetch 访问 https://registry.npmjs.org/{package-name}/latest，检查 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），则检查所有者的默认社区健康仓库：
使用 get_file_contents 获取 {owner}/.github 路径下的 FUNDING.yml。

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

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

解析 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。 仅对前 10 个未找到资金的依赖项使用 5c。
• 对非 npm 生态系统跳过 npm 注册表调用。
• 对仓库去重 — 每个仓库只检查一次。
• 每个唯一所有者只进行一次 {owner}/.github 检查 — 对其所有仓库重用结果。
• 每次批量处理 10 个所有者 的组织级别查找。

---

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

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

对每个资金 URL 使用 web_fetch：

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

每次批量验证 5 个。绝不呈现未经验证的链接。

---

步骤 7：输出报告

输出纪律

在数据收集期间尽量减少中间输出。 不要宣布每个批次（“第 3 批，共 7 批…”、“正在检查资金…”）。相反：

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

报告模板

## 💜 Sponsor Finder 报告

**仓库：** {owner}/{repo} · {ecosystem} · {package}@{version}
**扫描时间：** {date} · 共 {total} 个依赖项（{direct} 个直接 + {transitive} 个传递）

---

### 🎯 回馈方式

赞助仅 {N} 个人/组织即可支持 {sponsorable} 个依赖项（共 {total} 个）——这是投资项目所依赖的开源社区的好方法。

1. **💜 @{user}** — {N} 个直接 + {M} 个传递依赖项 · ⭐ 积极维护
   {dep1}, {dep2}, {dep3}, ...
   https://github.com/sponsors/{user}

2. **🟠 Open Collective: {name}** — {N} 个直接 + {M} 个传递依赖项 · ⭐ 积极维护
   {dep1}, {dep2}, {dep3}, ...
   https://opencollective.com/{name}

3. **💜 @{user2}** — {N} 个直接依赖项 · 💤 低活跃度
   {dep1}
   https://github.com/sponsors/{user2}

---

### 📊 覆盖率

- **{sponsorable}/{total}** 个依赖项有资金选项（{percentage}%）
- **{destinations}** 个唯一资金目标
- **{unfunded_direct}** 个直接依赖项尚未设置资金（{top_names}, ...）
- 所有链接已验证 ✅

报告格式规则

• 以 "🎯 回馈方式" 开头 — 这是主要输出。编号列表，按覆盖的依赖项总数降序排列。
• 裸 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. 尽量减少中间输出。 不要宣布每个批次。收集所有数据，然后输出一份完整的报告。