开源项目赞助者查找工具 - 一键分析依赖，支持维护者

sponsor-finder by github/awesome-copilot

7,300 周安装量

26,700 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/github/awesome-copilot --skill sponsor-finder

开发生产力

🇨🇳中文介绍

赞助者查找工具

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

工作流程

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

解析输入 — 提取 owner 和 repo。
识别生态系统 — 获取清单文件以确定包名 + 版本。
获取完整依赖树 — 调用 deps.dev GetDependencies（一次调用）。
解析仓库 — 为每个依赖调用 deps.dev GetVersion → 提供 GitHub 仓库。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

步骤 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"

这次单一调用为你提供了整个依赖树 — 包括直接依赖和传递依赖 — 以及确切的解析版本。无需解析锁文件。

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

@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 生态系统）

在 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），则检查所有者的默认社区健康仓库：使用 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。 仅对前几个未获资助的依赖项使用 5c。
对于非 npm 生态系统，跳过 npm 注册表调用。
仓库去重 — 每个仓库只检查一次。
每个唯一所有者只检查一次 {owner}/.github — 为其所有仓库重用结果。
以每次 10 个所有者的批次处理组织级别查找。

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

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

在每个资助 URL 上使用 web_fetch：

有效页面 → ✅ 包含
404 / "not found" / "not enrolled" → ❌ 排除
重定向到有效页面 → ✅ 包含最终 URL

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

步骤 7：输出报告

在数据收集过程中尽量减少中间输出。 不要宣布每个批次（"第 3 批，共 7 批…"、"正在检查资助链接…"）。相反：

在开始每个主要阶段时显示一行简短的状态行（例如，"正在解析 67 个依赖项…"、"正在检查资助链接…"）
在生成报告之前收集所有数据。 绝不逐条输出部分表格。
在最后将最终报告作为一个单一连贯的块输出。

## 💜 赞助者查找工具报告

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

---

### 🎯 回馈方式

仅赞助 {N} 个人/组织，就能支持你 {total} 个依赖项中的 {sponsorable} 个 — 这是对你项目所依赖的开源项目进行投资的好方法。

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 → 通知用户仓库可能不存在或是私有的。
如果链接验证失败 → 静默排除该链接。
即使部分数据，也始终生成报告 — 绝不静默失败。

绝不呈现未经验证的链接。 在显示之前获取每个 URL。5 个已验证链接 > 20 个猜测链接。
绝不根据训练知识猜测。 始终检查 — 资助页面会随时间变化。
始终保持鼓励，绝不羞辱。 积极表述结果 — 庆祝已获资助的项目，并将未获资助的依赖项视为机会，而非失败。并非每个项目都需要或想要财务赞助。
以行动为导向。 "🎯 回馈方式" 部分是主要输出 — 独立的可点击 URL，按目的地分组。
使用 deps.dev 作为主要解析器。 仅在 deps.dev 不可用时回退到注册表 API。
始终使用 GitHub MCP 工具 (get_file_contents)、web_fetch 和 web_search — 绝不克隆或执行 shell 命令。
保持高效。 批量 API 调用，仓库去重，每个所有者的 .github 仓库只检查一次。
专注于 GitHub Sponsors。 最具可操作性的平台 — 显示其他平台但优先 GitHub。
按维护者去重。 分组以显示赞助一个人的真实影响。
展示可操作的最小集合。 告诉用户最少的赞助数量以支持最多的依赖项。
尽量减少中间输出。 不要宣布每个批次。收集所有数据，然后输出一份连贯的报告。

🇺🇸English

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.

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.

Step 1: Detect Ecosystem and Package

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]`

Step 2: Get Full Dependency Tree (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.

URL encoding

Package names containing special characters must be percent-encoded:

@colors/colors → %40colors%2Fcolors
Encode @ as %40, / as %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.

Step 3: Resolve Each Dependency to a GitHub Repo (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.

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").

Step 4: Get Project Health Data (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

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.

Step 5: Find Funding Links

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

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

Use web_fetch on 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

5b: `.github/FUNDING.yml` (repo-level, then org-level 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}

5c: Web search fallback

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).

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.

Step 6: Verify Every Link (CRITICAL)

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.

Step 7: Output the Report

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.

Report template

## 💜 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 ✅

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.

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.

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.

Weekly Installs

7.3K

Repository

github/awesome-copilot

GitHub Stars

26.7K

First Seen

Feb 13, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

codex7.2K

gemini-cli7.2K

opencode7.2K

github-copilot7.2K

cursor7.2K

kimi-cli7.2K

custom: [urls] → use as-is

Minimize intermediate output. Don't announce each batch. Collect all data, then output one cohesive report.

开源项目赞助者查找工具 - 一键分析依赖，支持维护者

🇨🇳中文介绍

赞助者查找工具

工作流程

相关 Skills

步骤 1：识别生态系统和包

步骤 2：获取完整依赖树 (deps.dev)

URL 编码

对于没有单一根包的仓库

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

效率规则

步骤 4：获取项目健康数据 (deps.dev)

效率规则

步骤 5：查找资助链接

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

5b: .github/FUNDING.yml（仓库级别，然后组织级别回退）

5c: 网络搜索回退

效率规则

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

步骤 7：输出报告

输出规范

报告模板

报告格式规则

错误处理

关键规则

🇺🇸English

Sponsor Finder

Your Workflow

Step 1: Detect Ecosystem and Package

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

URL encoding

For repos without a single root package

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

Efficiency rules

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

Efficiency rules

Step 5: Find Funding Links

5a: npm funding field (npm ecosystem only)

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

5c: Web search fallback

Efficiency rules

Step 6: Verify Every Link (CRITICAL)

Step 7: Output the Report

Output discipline

Report template

Report format rules

Error Handling

Critical Rules

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

5b: `.github/FUNDING.yml`（仓库级别，然后组织级别回退）

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

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