Sponsor Finder
Map a GitHub repo’s dependency tree to verified GitHub Sponsors and funding links with OSSF health context.
Overview
Sponsor Finder is an agent skill most often used in Operate (also Grow lifecycle) that lists sponsorable GitHub dependencies for a repo using deps.dev and verified funding links.
Install
npx skills add https://github.com/github/awesome-copilot --skill sponsor-finderWhat is this skill?
- Invoke with /sponsor owner/repo after parsing GitHub coordinates
- Resolves trees via deps.dev across npm, PyPI, Cargo, Go, RubyGems, Maven, and NuGet
- Pulls OSSF Scorecard health via deps.dev GetProject for unique repos
- Funding sources: npm funding metadata, FUNDING.yml, verified web search fallbacks
- Reports direct and transitive dependencies with live-link verification
- Dependency resolution across seven ecosystems: npm, PyPI, Cargo, Go, RubyGems, Maven, and NuGet
- Eight-step workflow from parse input through grouped sponsorship report
Adoption & trust: 8.5k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You ship on dozens of transitive packages but have no consolidated, verified list of which maintainers accept GitHub Sponsors or other funding.
Who is it for?
OSS maintainers and product builders who want a repeatable dependency-to-sponsor map before budgeting or public thank-you posts.
Skip if: Repositories with no published package manifest deps.dev can resolve, or teams that need license compliance scanning instead of funding discovery.
When should I use this skill?
User runs /sponsor followed by a GitHub owner/repo (e.g. /sponsor expressjs/express) or provides owner/repo format.
What do I get? / Deliverables
You get a structured sponsorship report covering direct and transitive deps with OSSF Scorecard context and confirmed funding URLs.
- Sponsorship report for direct and transitive dependencies
- Verified funding URLs and OSSF Scorecard summaries per repo
- Ecosystem detection and grouped findings for action
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate/iterate because maintainers run this after shipping when assessing dependency risk and sustainable funding. Sponsor discovery supports ongoing maintenance decisions—who to fund and which transitive deps matter—not initial ideation.
Where it fits
Quarterly review of transitive deps to decide which maintainers to sponsor after a major upgrade.
Publish a transparency post listing verified sponsor links for libraries powering your shipped product.
Before release, attach funding awareness to critical transitive packages surfaced in the report.
How it compares
Funding-and-health discovery over deps.dev—not a generic vulnerability scanner or npm audit substitute.
Common Questions / FAQ
Who is sponsor-finder for?
Solo builders and maintainers of GitHub projects who want to support upstream OSS with accurate sponsor links and health signals.
When should I use sponsor-finder?
In Operate when reviewing dependency sustainability, and in Grow when planning community support posts or sponsor budgets for libraries you rely on.
Is sponsor-finder safe to install?
It performs outbound API and URL checks—review the Security Audits panel on this page and avoid piping private repo secrets into prompts.
SKILL.md
READMESKILL.md - 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 th