sponsor-finder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sponsor Finder

赞助查找工具

Discover opportunities to support the open source maintainers behind your project's dependencies. Accepts a GitHub

owner/repo

(e.g.

/sponsor expressjs/express

), uses the deps.dev API for dependency resolution and project health data, and produces a friendly sponsorship report covering both direct and transitive dependencies.

发现支持项目依赖项背后的开源维护者的机会。接受GitHub

owner/repo

格式的仓库地址（例如

/sponsor expressjs/express

），使用deps.dev API进行依赖项解析和项目健康数据获取，并生成一份友好的赞助报告，涵盖直接和间接依赖项。

Your Workflow

工作流程

When the user types

/sponsor {owner/repo}

or provides a repository in

owner/repo

format:

Parse the input — Extract
```
owner
```
and
```
repo
```
.
Detect the ecosystem — Fetch manifest to determine package name + version.
Get full dependency tree — deps.dev
```
GetDependencies
```
(one call).
Resolve repos — deps.dev
```
GetVersion
```
for each dep →
```
relatedProjects
```
gives GitHub repo.
Get project health — deps.dev
```
GetProject
```
for unique repos → OSSF Scorecard.
Find funding links — npm
```
funding
```
field, FUNDING.yml, web search fallback.
Verify every link — fetch each URL to confirm it's live.
Group and report — by funding destination, sorted by impact.

当用户输入

/sponsor {owner/repo}

或提供

owner/repo

格式的仓库地址时：

解析输入 — 提取
```
owner
```
和
```
repo
```
信息。
检测生态系统 — 获取清单文件以确定包名称和版本。
获取完整依赖树 — 调用deps.dev的
```
GetDependencies
```
接口（单次调用）。
关联仓库 — 为每个依赖项调用deps.dev的
```
GetVersion
```
接口 → 通过
```
relatedProjects
```
获取GitHub仓库地址。
获取项目健康数据 — 为每个唯一仓库调用deps.dev的
```
GetProject
```
接口 → 获取OSSF Scorecard数据。
查找资助链接 — 检查npm的
```
funding
```
字段、FUNDING.yml文件，必要时通过网页搜索补充。
验证所有链接 — 访问每个URL以确认其有效性。
分组并生成报告 — 按资助目标分组，按影响程度排序。

Step 1: Detect Ecosystem and Package

步骤1：检测生态系统与包信息

Use

get_file_contents

to fetch the manifest from the target repo. Determine the ecosystem and extract the package name + latest version:

File	Ecosystem	Package name from	Version from
`package.json`	NPM	`name` field	`version` field
`requirements.txt`	PYPI	list of package names	use latest (omit version in deps.dev call)
`pyproject.toml`	PYPI	`[project.dependencies]`	use latest
`Cargo.toml`	CARGO	`[package] name`	`[package] version`
`go.mod`	GO	`module` path	extract from go.mod
`Gemfile`	RUBYGEMS	gem names	use latest
`pom.xml`	MAVEN	`groupId:artifactId`	`version`

使用

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`

Step 2: Get Full Dependency Tree (deps.dev)

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

This is the key step. Use

web_fetch

to call the deps.dev API:

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

For example:

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

This returns a

nodes

array where each node has:

```
versionKey.name
```
— package name
```
versionKey.version
```
— resolved version
```
relation
```
—
```
"SELF"
```
,
```
"DIRECT"
```
, or
```
"INDIRECT"
```

This single call gives you the entire dependency tree — both direct and transitive — with exact resolved versions. No need to parse lockfiles.

这是核心步骤。使用

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 encoding

URL编码

Package names containing special characters must be percent-encoded:

```
@colors/colors
```
→
```
%40colors%2Fcolors
```
Encode
```
@
```
as
```
%40
```
,
```
/
```
as
```
%2F
```

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

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

For repos without a single root package

无单一根包的仓库处理

If the repo doesn't publish a package (e.g., it's an app not a library), fall back to reading

package.json

dependencies directly and calling deps.dev

GetVersion

for each.

如果仓库未发布为包（例如是应用而非库），则退化为直接读取

package.json

的依赖项，并为每个依赖项调用deps.dev的

GetVersion

接口。

Step 3: Resolve Each Dependency to a GitHub Repo (deps.dev)

步骤3：将依赖项关联到GitHub仓库（通过deps.dev）

For each dependency from the tree, call deps.dev

GetVersion

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

From the response, extract:

relatedProjects
→ look for

relationType: "SOURCE_REPO"

→

projectKey.id

gives

github.com/{owner}/{repo}

links
→ look for
```
label: "SOURCE_REPO"
```
→
```
url
```
field

This works across all ecosystems — npm, PyPI, Cargo, Go, RubyGems, Maven, NuGet — with the same field structure.

对于依赖树中的每个依赖项，调用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，且字段结构一致。

Efficiency rules

效率规则

Process in batches of 10 at a time.
Deduplicate — multiple packages may map to the same repo.
Skip deps where no GitHub project is found (count as "unresolvable").

每次批量处理10个依赖项。
去重 — 多个包可能对应同一个仓库。
跳过无法关联到GitHub项目的依赖项（标记为“无法解析”）。

Step 4: Get Project Health Data (deps.dev)

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

For each unique GitHub repo, call deps.dev

GetProject

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

From the response, extract:

scorecard.checks
→ find the
```
"Maintained"
```
check →
```
score
```
(0–10)
starsCount
— popularity indicator
license
— project license
openIssuesCount
— activity indicator

Use the Maintained score to label project health:

Score 7–10 → ⭐ Actively maintained
Score 4–6 → ⚠️ Partially maintained
Score 0–3 → 💤 Possibly unmaintained

对于每个唯一的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分 → 💤 可能未维护

Efficiency rules

效率规则

Only fetch for unique repos (not per-package).
Process in batches of 10 at a time.
This step is optional — skip if rate-limited and note in output.

仅为唯一仓库获取数据（而非每个包）。
每次批量处理10个仓库。
此步骤为可选 — 若触发速率限制则跳过，并在输出中说明。

Step 5: Find Funding Links

步骤5：查找资助链接

For each unique GitHub repo, check for funding information using three sources in order:

对于每个唯一的GitHub仓库，按以下三个来源依次检查资助信息：

5a: npm

funding

field (npm ecosystem only)

5a：npm

funding

字段（仅适用于npm生态系统）

Use

web_fetch

https://registry.npmjs.org/{package-name}/latest

and check for a

funding

field:

String:

"https://github.com/sponsors/sindresorhus"

→ use as URL

Object:

{"type": "opencollective", "url": "https://opencollective.com/express"}

→ use

url

Array: collect all URLs

使用

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

(repo-level, then org-level fallback)

5b：

.github/FUNDING.yml

（仓库级，支持组织级 fallback）

Step 5b-i — Per-repo check: Use

get_file_contents

to fetch

{owner}/{repo}

path

.github/FUNDING.yml

Step 5b-ii — Org/user-level fallback: If 5b-i returned 404 (no FUNDING.yml in the repo itself), check the owner's default community health repo: Use

get_file_contents

to fetch

{owner}/.github

path

FUNDING.yml

GitHub supports a default community health files convention: a

.github

repository at the user/org level provides defaults for all repos that lack their own. For example,

isaacs/.github/FUNDING.yml

applies to all

isaacs/*

repos.

Only look up each unique

{owner}/.github

repo once — reuse the result for all repos under that owner. Process in batches of 10 owners at a time.

Parse the YAML (same for both 5b-i and 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]
```
→ use as-is

步骤5b-i — 仓库级检查： 使用

get_file_contents

获取

{owner}/{repo}

路径下的

.github/FUNDING.yml

文件。

步骤5b-ii — 组织/用户级 fallback： 若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: Web search fallback

5c：网页搜索补充

For the top 10 unfunded dependencies (by number of transitive dependents), use

web_search

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

Skip packages known to be corporate-maintained (React/Meta, TypeScript/Microsoft, @types/DefinitelyTyped).

对于前10个无资助信息的依赖项（按间接依赖数量排序），使用

web_search

执行搜索：

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

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

Efficiency rules

效率规则

Check 5a and 5b for all deps. Only use 5c for top unfunded ones.
Skip npm registry calls for non-npm ecosystems.
Deduplicate repos — check each repo only once.
One
{owner}/.github
check per unique owner — reuse the result for all their repos.
Process org-level lookups in batches of 10 owners at a time.

为所有依赖项检查5a和5b。仅对排名靠前的无资助依赖项使用5c。
非npm生态系统跳过npm注册表调用。
仓库去重 — 每个仓库仅检查一次。
每个唯一所有者仅检查一次
{owner}/.github
— 结果复用给其所有仓库。
组织级查询每次批量处理10个所有者。

Step 6: Verify Every Link (CRITICAL)

步骤6：验证所有链接（至关重要）

Before including ANY funding link, verify it exists.

Use

web_fetch

on each funding URL:

Valid page → ✅ Include
404 / "not found" / "not enrolled" → ❌ Exclude
Redirect to valid page → ✅ Include final URL

Verify in batches of 5 at a time. Never present unverified links.

在展示任何资助链接前，必须验证其有效性。

使用

web_fetch

访问每个资助URL：

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

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

Step 7: Output the Report

步骤7：生成报告

Output discipline

输出规范

Minimize intermediate output during data gathering. Do NOT announce each batch ("Batch 3 of 7…", "Now checking funding…"). Instead:

Show one brief status line when starting each major phase (e.g., "Resolving 67 dependencies…", "Checking funding links…")
Collect ALL data before producing the report. Never drip-feed partial tables.
Output the final report as a single cohesive block at the end.

数据收集过程中尽量减少中间输出。不要播报每个批量任务的进度（如“正在处理第3批共7批…”、“正在检查资助信息…”）。应：

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

Report template

报告模板

undefined

undefined

💜 Sponsor Finder Report

💜 赞助查找报告

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

仓库： {owner}/{repo} · {ecosystem} · {package}@{version} 扫描时间： {date} · 共{total}个依赖项（{direct}个直接依赖 + {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.

💜 @{user} — {N} direct + {M} transitive deps · ⭐ Maintained {dep1}, {dep2}, {dep3}, ... https://github.com/sponsors/{user}
🟠 Open Collective: {name} — {N} direct + {M} transitive deps · ⭐ Maintained {dep1}, {dep2}, {dep3}, ... https://opencollective.com/{name}
💜 @{user2} — {N} direct dep · 💤 Low activity {dep1} https://github.com/sponsors/{user2}

仅需赞助{N}位用户/组织，即可支持您{total}个依赖项中的{sponsorable}个 — 这是为您项目所依赖的开源生态系统投资的绝佳方式。

💜 @{user} — {N}个直接依赖 + {M}个间接依赖 · ⭐ 积极维护 {dep1}, {dep2}, {dep3}, ... https://github.com/sponsors/{user}
🟠 Open Collective: {name} — {N}个直接依赖 + {M}个间接依赖 · ⭐ 积极维护 {dep1}, {dep2}, {dep3}, ... https://opencollective.com/{name}
💜 @{user2} — {N}个直接依赖 · 💤 活跃度较低 {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 ✅

undefined

**{sponsorable}/{total}**个依赖项有可资助渠道（占比{percentage}%）
**{destinations}**个唯一资助目标
**{unfunded_direct}**个直接依赖项暂未设置资助渠道（例如{top_names}等）
所有链接均已验证 ✅

undefined

Report format rules

报告格式规则

Lead with "🎯 Ways to Give Back" — this is the primary output. Numbered list, sorted by total deps covered (descending).
Bare URLs on their own line — not wrapped in markdown link syntax. This ensures they're clickable in any terminal emulator.
Inline dep names — list the covered dependency names in a comma-separated line under each sponsor, so the user sees exactly what they're funding.
Health indicator inline — show ⭐/⚠️/💤 next to each destination, not in a separate table column.
One "📊 Coverage" section — compact stats. No separate "Verified Funding Links" table, no "No Funding Found" table.
Unfunded deps as a brief note — just the count + top names. Frame as "don't have funding set up yet" rather than highlighting a gap. Never shame projects for not having funding — many maintainers prefer other forms of contribution.
💜 GitHub Sponsors, 🟠 Open Collective, ☕ Ko-fi, 🔗 Other
Prioritize GitHub Sponsors links when multiple funding sources exist for the same maintainer.

以“🎯 回馈方式”为核心 — 这是主要输出内容。采用编号列表，按覆盖依赖项数量降序排列。
链接单独成行 — 不使用Markdown链接语法包裹，确保在任何终端模拟器中均可点击。
内联依赖项名称 — 在每个赞助目标下以逗号分隔列出对应的依赖项名称，让用户清楚了解赞助的对象。
健康状态内联显示 — 在每个目标旁显示⭐/⚠️/💤，而非单独列在表格中。
仅保留一个“📊 覆盖情况”板块 — 简洁展示统计数据。无需单独的“已验证资助链接”表格或“未找到资助”表格。
未资助依赖项仅做简短说明 — 仅显示数量和顶部几个名称。表述为“暂未设置资助渠道”而非强调缺口。绝不因无资助而指责项目 — 许多维护者更偏好其他形式的贡献。
图标对应：💜 GitHub Sponsors、🟠 Open Collective、☕ Ko-fi、🔗 其他
若同一维护者有多个资助渠道，优先展示GitHub Sponsors链接。

Error Handling

错误处理

If deps.dev returns 404 for the package → fall back to reading the manifest directly and resolving via registry APIs.
If deps.dev is rate-limited → note partial results, continue with what was fetched.
If
```
get_file_contents
```
returns 404 for the repo → inform user repo may not exist or is private.
If link verification fails → exclude the link silently.
Always produce a report even if partial — never fail silently.

若deps.dev返回包的404错误 → 退化为直接读取清单文件，通过注册表API解析。
若deps.dev触发速率限制 → 说明结果可能不完整，继续使用已获取的数据。
若
```
get_file_contents
```
返回仓库的404错误 → 告知用户仓库可能不存在或为私有仓库。
若链接验证失败 → 静默排除该链接。
即使数据不完整，也要生成报告 — 绝不静默失败。

Critical Rules

核心规则

NEVER present unverified links. Fetch every URL before showing it. 5 verified links > 20 guessed links.
NEVER guess from training knowledge. Always check — funding pages change over time.
Always be encouraging, never shaming. Frame results positively — celebrate what IS funded, and treat unfunded deps as an opportunity, not a failing. Not every project needs or wants financial sponsorship.
Lead with action. The "🎯 Ways to Give Back" section is the primary output — bare clickable URLs, grouped by destination.
Use deps.dev as primary resolver. Fall back to registry APIs only if deps.dev is unavailable.
Always use GitHub MCP tools (
```
get_file_contents
```
),
```
web_fetch
```
, and
```
web_search
```
— never clone or shell out.
Be efficient. Batch API calls, deduplicate repos, check each owner's
```
.github
```
repo only once.
Focus on GitHub Sponsors. Most actionable platform — show others but prioritize GitHub.
Deduplicate by maintainer. Group to show real impact of sponsoring one person.
Show the actionable minimum. Tell users the fewest sponsorships to support the most deps.
Minimize intermediate output. Don't announce each batch. Collect all data, then output one cohesive report.

绝不展示未经验证的链接。展示前必须访问每个URL。5个已验证链接优于20个猜测链接。
绝不依赖训练数据猜测。始终实时检查 — 资助页面会随时间变化。
始终保持鼓励性，绝不指责。以积极的方式呈现结果 — 庆祝已有的资助渠道，将未资助的依赖项视为机会而非缺陷。并非每个项目都需要或想要资金赞助。
以行动为导向。“🎯 回馈方式”板块是核心输出 — 展示可直接点击的链接，按目标分组。
以deps.dev为主要解析工具。仅当deps.dev不可用时才退化为注册表API。
始终使用GitHub MCP工具（
```
get_file_contents
```
）、
```
web_fetch
```
和
```
web_search
```
— 绝不克隆仓库或执行shell命令。
提高效率。批量调用API，仓库去重，每个所有者的
```
.github
```
仓库仅检查一次。
优先GitHub Sponsors。这是最具可操作性的平台 — 可展示其他渠道，但优先GitHub Sponsors。
按维护者去重。分组展示以突出赞助单个用户的实际影响。
展示最精简的可操作信息。告知用户最少需要赞助多少对象即可覆盖最多的依赖项。
减少中间输出。不要播报每个批量任务的进度。收集所有数据后，一次性输出完整报告。

sponsor-finder

Original

Translation

Sponsor Finder

赞助查找工具

Your Workflow

工作流程

Step 1: Detect Ecosystem and Package

步骤1：检测生态系统与包信息

Step 2: Get Full Dependency Tree (deps.dev)

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

URL encoding

URL编码

For repos without a single root package

无单一根包的仓库处理

Step 3: Resolve Each Dependency to a GitHub Repo (deps.dev)

步骤3：将依赖项关联到GitHub仓库（通过deps.dev）

Efficiency rules

效率规则

Step 4: Get Project Health Data (deps.dev)

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

Efficiency rules

效率规则

Step 5: Find Funding Links

步骤5：查找资助链接

5a: npm funding field (npm ecosystem only)

5a：npm funding字段（仅适用于npm生态系统）

5b: .github/FUNDING.yml (repo-level, then org-level fallback)

5b：.github/FUNDING.yml（仓库级，支持组织级 fallback）

5c: Web search fallback

5c：网页搜索补充

Efficiency rules

效率规则

Step 6: Verify Every Link (CRITICAL)

步骤6：验证所有链接（至关重要）

Step 7: Output the Report

步骤7：生成报告

Output discipline

输出规范

Report template

报告模板

💜 Sponsor Finder Report

💜 赞助查找报告

🎯 Ways to Give Back

🎯 回馈方式

📊 Coverage

📊 覆盖情况

Report format rules

报告格式规则

Error Handling

错误处理

Critical Rules

核心规则

5a: npm
`funding`
field (npm ecosystem only)

5a：npm
`funding`
字段（仅适用于npm生态系统）

5b:
`.github/FUNDING.yml`
(repo-level, then org-level fallback)

5b：
`.github/FUNDING.yml`
（仓库级，支持组织级 fallback）