Sponsor-Finder

# 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:

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: 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]` | 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: 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`** — activit