Use deps.dev API for dependency resolution

Major upgrade: - deps.dev GetDependencies: full tree in one call (direct + transitive) - deps.dev GetVersion: cross-ecosystem package→repo mapping (7 ecosystems) - deps.dev GetProject: OSSF Scorecard health data per project - Direct vs transitive column (✅ vs ⛓️) - Health column from Scorecard Maintained check - Actionable minimum: '💡 Sponsoring just N people covers all funded deps' - Graceful fallback to registry APIs if deps.dev unavailable
2026-02-20 02:15:12 +00:00 · 2026-02-12 16:24:08 -08:00
parent 131585af9b
commit 03e1b3a178
2 changed files with 168 additions and 198 deletions
--- a/skills/sponsor-finder/SKILL.md
+++ b/skills/sponsor-finder/SKILL.md
@@ -1,287 +1,257 @@
 ---
 name: sponsor-finder
-description: Find which of a GitHub repository's dependencies are sponsorable via GitHub Sponsors. Resolves dependencies to source GitHub repos, checks npm funding metadata, FUNDING.yml files, and web search. Verifies every link before presenting. Supports npm, Python, Rust, Go, and Ruby. Use when evaluating which open source projects to sponsor, building an OSPO sponsorship strategy, or auditing dependency funding. Invoke by providing a GitHub owner/repo (e.g. "find sponsorable dependencies in expressjs/express").
+description: Find which of a GitHub repository's dependencies are sponsorable via GitHub Sponsors. Uses deps.dev API for dependency resolution across npm, PyPI, Cargo, Go, RubyGems, Maven, and NuGet. Checks npm funding metadata, FUNDING.yml files, and web search. Verifies every link. Shows direct and transitive dependencies with OSSF Scorecard health data. Invoke by providing a GitHub owner/repo (e.g. "find sponsorable dependencies in expressjs/express").
 ---

 # Sponsor Finder

-Find which of a repository's open source dependencies accept sponsorship via GitHub Sponsors (or Open Collective, Ko-fi, etc.). Accepts a GitHub `owner/repo`, inspects its dependencies using the GitHub MCP tools, npm/PyPI registries, and web search, and produces a verified sponsorship report.
+Find which of a repository's open source dependencies accept sponsorship via GitHub Sponsors (or Open Collective, Ko-fi, etc.). Accepts a GitHub `owner/repo`, uses the deps.dev API for dependency resolution and project health data, and produces a verified sponsorship report covering both direct and transitive dependencies.

 ## Your Workflow

 When the user provides a repository in `owner/repo` format:

-1. **Parse the input** — Extract the `owner` and `repo` from the user's message.
-2. **Fetch the dependency manifest** from the repo.
-3. **Extract dependency names** from the manifest.
-4. **Resolve each dependency** to its source GitHub repo via registry APIs.
-5. **Check funding sources** — registry `funding` field, `.github/FUNDING.yml`, and web search fallback.
-6. **Verify every link** — fetch each funding URL to confirm it's live.
-7. **Group by maintainer** and produce the report.
-
-Always complete all steps before producing the report.
+1. **Parse the input** — Extract `owner` and `repo`.
+2. **Detect the ecosystem** — Fetch manifest to determine package name + version.
+3. **Get full dependency tree** — deps.dev `GetDependencies` (one call).
+4. **Resolve repos** — deps.dev `GetVersion` for each dep → `relatedProjects` gives GitHub repo.
+5. **Get project health** — deps.dev `GetProject` for unique repos → OSSF Scorecard.
+6. **Find funding links** — npm `funding` field, FUNDING.yml, web search fallback.
+7. **Verify every link** — fetch each URL to confirm it's live.
+8. **Group and report** — by funding destination, sorted by impact.

 ---

-## Step 1: Fetch the Dependency Manifest
+## Step 1: Detect Ecosystem and Package

-Use `get_file_contents` to look for dependency files in this order (stop at first match):
+Use `get_file_contents` to fetch the manifest from the target repo. Determine the ecosystem and extract the package name + latest version:

-| Ecosystem | File | Priority |
-|-----------|------|----------|
-| Node.js/npm | `package.json` | 1st |
-| Python | `requirements.txt`, `pyproject.toml` | 2nd |
-| Rust | `Cargo.toml` | 3rd |
-| Go | `go.mod` | 4th |
-| Ruby | `Gemfile` | 5th |
-
-If none exist, inform the user that no supported manifest was found.
+| 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` |

 ---

-## Step 2: Extract Dependency Names
+## Step 2: Get Full Dependency Tree (deps.dev)

-### Node.js (`package.json`)
-Extract package names from `dependencies` (production — most important) and optionally `devDependencies` (include if user asks or fewer than 30 production deps).
+**This is the key step.** Use `web_fetch` to call the deps.dev API:

-### Python (`requirements.txt`)
-Extract package names before version specifiers (`==`, `>=`, `~=`). Ignore comments (`#`), blank lines, and `-r` includes.
-
-### Python (`pyproject.toml`)
-Extract from `[project.dependencies]` or `[tool.poetry.dependencies]`.
-
-### Rust (`Cargo.toml`)
-Extract package names from `[dependencies]` section.
-
-### Go (`go.mod`)
-Extract module paths from `require` statements. The GitHub repo is usually the module path itself (e.g., `github.com/gin-gonic/gin`).
-
-### Ruby (`Gemfile`)
-Extract gem names from `gem` statements.
-
---
-
-## Step 3: Resolve Dependencies to GitHub Repos AND Collect Funding Info
-
-For each dependency, query the appropriate registry to find the source GitHub repository **and** any funding metadata.
-
-### Node.js (npm)
-Use `web_fetch` on `https://registry.npmjs.org/{package-name}/latest`.
-
-From the JSON response, extract:
- **`repository.url`** → parse to `owner/repo` (handle `git+https://`, `git://`, `git+ssh://` formats)
- **`funding` field** → primary funding source (string URL, object with `url`, or array)
-
-### Python (PyPI)
-Use `web_fetch` on `https://pypi.org/pypi/{package}/json`.
-
-From the response, extract:
- **`info.project_urls`** → look for `Source`, `Repository`, `Homepage`, or `GitHub` keys pointing to github.com
- **`info.project_urls.Funding`** → if present, use as funding URL directly
-
-### Rust (crates.io)
-Use `web_fetch` on `https://crates.io/api/v1/crates/{package}`.
-
-From the response, extract:
- **`crate.repository`** → parse GitHub URL to `owner/repo`
-
-### Go
-Module paths starting with `github.com/` already contain the `owner/repo`. No registry lookup needed.
-
-### Ruby (RubyGems)
-Use `web_fetch` on `https://rubygems.org/api/v1/gems/{gem}.json`.
-
-From the response, extract:
- **`source_code_uri`** or **`homepage_uri`** → parse GitHub URL to `owner/repo`
-
-### URL parsing
-Handle these common repository URL formats:
- `git+https://github.com/{owner}/{repo}.git` → `{owner}/{repo}`
- `https://github.com/{owner}/{repo}.git` → `{owner}/{repo}`
- `https://github.com/{owner}/{repo}` → `{owner}/{repo}`
- `git://github.com/{owner}/{repo}.git` → `{owner}/{repo}`
- `git+ssh://git@github.com/{owner}/{repo}.git` → `{owner}/{repo}`
-
-### Efficiency rules
- Process dependencies in batches of **10 at a time**.
- If a dependency has no repository URL or it doesn't point to GitHub, skip it and count it as "unresolvable".
- If there are more than **60 production dependencies**, sample the first 60 and note in the output.
- **Deduplicate** GitHub repos — multiple packages may come from the same repo.
-
---
-
-## Step 4: Check for FUNDING.yml
-
-For dependencies that did NOT have a `funding` field from the registry, check their GitHub repo for a FUNDING.yml.
-
-Use `get_file_contents` to fetch `{owner}/{repo}` path `.github/FUNDING.yml`.
-
-Also check the org-level `.github` repo: `{org}/.github` path `.github/FUNDING.yml`.
-
-FUNDING.yml is a YAML file with these possible fields:
-
-```yaml
-github: [username]           # GitHub Sponsors
-open_collective: slug        # Open Collective
-ko_fi: username              # Ko-fi
-tidelift: platform/package   # Tidelift
-liberapay: username          # Liberapay
-patreon: username            # Patreon
-custom: [url1, url2]         # Custom URLs
+```
+https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{PACKAGE}/versions/{VERSION}:dependencies
 ```

-Generate sponsor links:
- `github: ljharb` → `https://github.com/sponsors/ljharb`
- `open_collective: express` → `https://opencollective.com/express`
- `ko_fi: username` → `https://ko-fi.com/username`
- `custom: ["https://..."]` → use as-is
+For example:
+```
+https://api.deps.dev/v3/systems/npm/packages/express/versions/5.2.1:dependencies
+```

-### Efficiency rules
- **Skip repos that already have funding info from Step 3.**
- Process remaining repos in batches of **10 at a time**.
+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 5: Web Search Fallback
+## Step 3: Resolve Each Dependency to a GitHub Repo (deps.dev)

-For dependencies that still have NO funding info after Steps 3 and 4, use `web_search` as a fallback:
+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`
+Use `get_file_contents` to fetch `{owner}/{repo}` path `.github/FUNDING.yml`.
+
+Parse the YAML:
+- `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
+
+### 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
 ```
-
-Look for:
- Links to `github.com/sponsors/{user}`
- Links to `opencollective.com/{project}`
- Funding sections on official project websites
-
-Only use results from authoritative sources (GitHub, Open Collective, official project sites).
+Skip packages known to be corporate-maintained (React/Meta, TypeScript/Microsoft, @types/DefinitelyTyped).

 ### Efficiency rules
- Only search for the **top 10 most important unfunded dependencies** (by download count or centrality).
- Skip packages known to be corporate-maintained (e.g., `react` by Meta, `typescript` by Microsoft, `@types/*` by DefinitelyTyped).
+- **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.

 ---

 ## Step 6: Verify Every Link (CRITICAL)

-**Before including ANY funding link in the report, verify it exists by fetching the URL.**
+**Before including ANY funding link, verify it exists.**

 Use `web_fetch` on each funding URL:
- **Valid page** (returns content about sponsoring/donating) → ✅ Include it
- **404, "not found", "not enrolled"** → ❌ Do NOT include it
- **Redirect to a valid page** → ✅ Include the final URL
+- **Valid page** → ✅ Include
+- **404 / "not found" / "not enrolled"** → ❌ Exclude
+- **Redirect to valid page** → ✅ Include final URL

-This is critical because:
- GitHub Sponsors pages only exist if the user enrolled
- Open Collective pages only exist if the project created one
- Funding URLs in FUNDING.yml or npm metadata may be stale
-
-### Efficiency rules
- Verify in batches of **5 at a time**.
- If verification fails, exclude the link silently — don't show broken links.
+Verify in batches of **5 at a time**. Never present unverified links.

 ---

-## Step 7: Parse and Group Results
-
-After verifying all links, determine the platform for each:
- Contains `github.com/sponsors/` → GitHub Sponsors (💜)
- Contains `opencollective.com/` → Open Collective (🟠)
- Contains `ko-fi.com/` → Ko-fi (☕)
- Contains `tidelift.com/` → Tidelift (🔗)
- Contains `patreon.com/` → Patreon (🔗)
- Other URLs → Custom (🔗)
-
-Group sponsorable dependencies by their funding destination. For GitHub Sponsors, group by username. For Open Collective, group by project.
-
-Sort by **number of dependencies** (most impact first).
-
---
-
-## Output Format
-
-Always produce the report in this exact format:
+## Step 7: Output the Report

 ```
 ## 💜 Sponsor Finder Report

 **Repository:** {owner}/{repo}
 **Scanned:** {current date}
+**Ecosystem:** {ecosystem} · {package}@{version}

 ---

 ### Summary

- **{total_deps}** dependencies found
- **{resolved}** resolved to GitHub repos ({unresolved} could not be resolved)
+- **{total}** total dependencies ({direct} direct + {transitive} transitive)
+- **{resolved}** resolved to GitHub repos
 - **💜 {sponsorable}** have verified funding links ({percentage}%)
- **{destination_count}** unique funding destinations
+- **{destinations}** unique funding destinations
 - All links verified ✅

 ---

 ### Verified Funding Links

-| Dependency | GitHub Repo | Funding | How Verified |
-|------------|-------------|---------|--------------|
-| {dep_name} | [{owner}/{repo}](https://github.com/{owner}/{repo}) | 💜 [GitHub Sponsors](https://github.com/sponsors/{username}) | FUNDING.yml |
-| {dep_name} | [{owner}/{repo}](https://github.com/{owner}/{repo}) | 🟠 [Open Collective](https://opencollective.com/{slug}) | npm funding field |
-| {dep_name} | [{owner}/{repo}](https://github.com/{owner}/{repo}) | 💜 [GitHub Sponsors](https://github.com/sponsors/{username}) | Web search |
-| ... | ... | ... | ... |
+| Dependency | Repo | Funding | Direct? | How Verified |
+|------------|------|---------|---------|--------------|
+| {name} | [{owner}/{repo}](https://github.com/{owner}/{repo}) | 💜 [GitHub Sponsors](https://github.com/sponsors/{user}) | ✅ | FUNDING.yml |
+| {name} | [{owner}/{repo}](https://github.com/{owner}/{repo}) | 🟠 [Open Collective](https://opencollective.com/{slug}) | ⛓️ | npm funding |
+| ... | ... | ... | ... | ... |
+
+Use ✅ for direct dependencies, ⛓️ for transitive.

 ---

 ### Funding Destinations (by impact)

-| Destination | Dependencies | Link |
-|-------------|-------------|------|
-| 🟠 Open Collective: {name} | {count} deps ({dep1}, {dep2}, ...) | [opencollective.com/{name}](https://opencollective.com/{name}) |
-| 💜 @{username} | {count} deps ({dep1}, ...) | [github.com/sponsors/{username}](https://github.com/sponsors/{username}) |
-| ... | ... | ... |
+| Destination | Deps | Health | Link |
+|-------------|------|--------|------|
+| 🟠 Open Collective: {name} | {N} direct | ⭐ Maintained | [opencollective.com/{name}](https://opencollective.com/{name}) |
+| 💜 @{user} | {N} direct + {M} transitive | ⭐ Maintained | [github.com/sponsors/{user}](https://github.com/sponsors/{user}) |
+| ... | ... | ... | ... |
+
+Sort by total number of dependencies (direct + transitive), descending.

 ---

 ### No Verified Funding Found

-These dependencies don't have discoverable funding pages:
- {package} (corporate-maintained by {company})
- {package} (no FUNDING.yml or funding metadata)
- ...
+| Dependency | Repo | Why | Direct? |
+|------------|------|-----|---------|
+| {name} | {owner}/{repo} | Corporate (Meta) | ✅ |
+| {name} | {owner}/{repo} | No FUNDING.yml or metadata | ⛓️ |
+| ... | ... | ... | ... |
+
+Only show the top 10 unfunded direct deps. If more, note "... and {N} more".

 ---

-### 💜 {percentage}% verified funding coverage · {destination_count} destinations · {sponsorable} dependencies
+### 💜 {percentage}% verified funding coverage · {destinations} destinations · {sponsorable} dependencies
+### 💡 Sponsoring just {N} people/orgs covers all {sponsorable} funded dependencies
 ```

 ### Format notes
- The **How Verified** column shows the data source: `FUNDING.yml`, `npm funding field`, `PyPI metadata`, `Web search`.
- Use 💜 for GitHub Sponsors, 🟠 for Open Collective, ☕ for Ko-fi, 🔗 for other platforms.
- If a dependency has multiple funding sources, show the GitHub Sponsors link preferentially.
- Only include dependencies with **verified** funding links in the main table.
- List unfunded deps separately with a note on why (corporate, no metadata, etc.).
+- **Direct?** column: ✅ = direct dependency, ⛓️ = transitive
+- **Health** column: ⭐ Maintained (7+), ⚠️ Partial (4–6), 💤 Low (0–3) — from OSSF Scorecard
+- **How Verified**: `FUNDING.yml`, `npm funding`, `PyPI metadata`, `Web search`
+- 💜 GitHub Sponsors, 🟠 Open Collective, ☕ Ko-fi, 🔗 Other
+- Prioritize GitHub Sponsors links when multiple funding sources exist
+- The **💡 summary line** tells the user the minimum number of sponsorships to cover everything

 ---

 ## Error Handling

- If `get_file_contents` returns 404 for the repo itself → inform user the repo may not exist or is private.
- If the manifest has no dependencies → report "No dependencies found."
- If a registry is unreachable for a dep → skip it, note in output.
- If FUNDING.yml exists but can't be parsed → attempt to extract any URLs, note "unparseable".
- If rate-limited → report what was completed and note that results are partial.
- If link verification fails → exclude the link, do NOT present unverified URLs.
+- 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

-1. **NEVER present unverified links.** Every funding URL must be fetched and confirmed live before showing it. 5 verified links are better than 20 guessed links.
-2. **NEVER guess from training knowledge.** Don't assume `opencollective.com/{package}` or `github.com/sponsors/{user}` exists — always check.
-3. **Be transparent about verification.** Show the "How Verified" column so users know the data source.
-4. **Always use the GitHub MCP tools** (`get_file_contents`), `web_fetch`, and `web_search` — never try to clone or shell out.
-5. **Be efficient** — batch lookups, deduplicate GitHub repos, respect sampling limits.
-6. **Focus on GitHub Sponsors** — most actionable platform. Show others but prioritize `github` field.
-7. **Deduplicate** — group by maintainer to show actual impact of sponsoring one person.
-8. **Stay in scope** — report on funding availability, not on whether projects "deserve" sponsorship.
+1. **NEVER present unverified links.** Fetch every URL before showing it. 5 verified links > 20 guessed links.
+2. **NEVER guess from training knowledge.** Always check — funding pages change over time.
+3. **Be transparent.** Show "How Verified" and "Direct?" columns so users understand the data.
+4. **Use deps.dev as primary resolver.** Fall back to registry APIs only if deps.dev is unavailable.
+5. **Always use GitHub MCP tools** (`get_file_contents`), `web_fetch`, and `web_search` — never clone or shell out.
+6. **Be efficient.** Batch API calls, deduplicate repos, respect sampling limits.
+7. **Focus on GitHub Sponsors.** Most actionable platform — show others but prioritize GitHub.
+8. **Deduplicate by maintainer.** Group to show real impact of sponsoring one person.
+9. **Show the actionable minimum.** The 💡 line tells users the fewest sponsorships to cover all funded deps.