sponsor-finder

スポンサー検索

プロジェクトの依存関係を支えるオープンソースメンテナーを支援する機会を見つけます。GitHub の owner/repo（例: /sponsor expressjs/express）を受け取り、deps.dev API を依存関係の解決とプロジェクト健全性データに使用し、直接依存関係と推移的依存関係の両方を網羅したわかりやすいスポンサーシップレポートを生成します。

ワークフロー

ユーザーが /sponsor {owner/repo} と入力するか、owner/repo 形式のリポジトリを指定した場合:

1. 入力を解析する — owner と repo を抽出します。
2. エコシステムを検出する — マニフェストを取得してパッケージ名 + バージョンを特定します。
3. 完全な依存関係ツリーを取得する — deps.dev GetDependencies（1 回の呼び出し）。
4. リポジトリを解決する — 各依存関係に対して deps.dev GetVersion → relatedProjects が GitHub リポジトリを返します。
5. プロジェクトの健全性を取得する — 一意のリポジトリに対して deps.dev GetProject → OSSF Scorecard。
6. 資金提供リンクを見つける — npm の funding フィールド、FUNDING.yml、Web 検索をフォールバックとして使用します。
7. すべてのリンクを検証する — 各 URL を取得して有効であることを確認します。
8. グループ化してレポートする — 資金提供先ごとに、インパクトの大きい順に並べます。

---

ステップ 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"

この 1 回の呼び出しで、依存関係ツリー全体（直接依存関係と推移的依存関係の両方）が正確に解決されたバージョンとともに得られます。ロックファイルを解析する必要はありません。

URL エンコーディング

特殊文字を含むパッケージ名はパーセントエンコードする必要があります:

• @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 — 活動状況の指標

Maintained スコアを使用してプロジェクトの健全性をラベル付けします:

• スコア 7〜10 → ⭐ 活発にメンテナンスされている
• スコア 4〜6 → ⚠️ 部分的にメンテナンスされている
• スコア 0〜3 → 💤 メンテナンスされていない可能性がある

効率化ルール

• 一意のリポジトリのみを取得します（パッケージごとではありません）。
• 一度に 10 件のバッチで処理します。
• このステップは任意です — レート制限されている場合はスキップし、出力にその旨を記載してください。

---

ステップ 5: 資金提供リンクを見つける

一意の GitHub リポジトリごとに、次の 3 つのソースを順に使って資金提供情報を確認します:

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: Web 検索フォールバック

資金提供を受けていない上位 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 の確認は 1 回 — そのすべてのリポジトリで結果を再利用します。
• 組織レベルの検索は一度に 10 オーナーのバッチで処理します。

---

ステップ 6: すべてのリンクを検証する（重要）

資金提供リンクを含める前に、それが存在することを検証してください。

各資金提供 URL に対して web_fetch を使用します:

• 有効なページ → ✅ 含める
• 404 /「見つかりません」/「登録されていません」 → ❌ 除外する
• 有効なページへのリダイレクト → ✅ 最終 URL を含める

一度に 5 件のバッチで検証します。検証されていないリンクを決して提示しないでください。

---

ステップ 7: レポートを出力する

出力の規律

データ収集中は中間出力を最小限に抑えます。 各バッチをアナウンスしないでください（「7 件中 3 件目のバッチ…」、「次に資金提供を確認しています…」など）。代わりに:

• 各大フェーズを開始するときに簡潔なステータス行を 1 行表示します（例:「67 件の依存関係を解決しています…」、「資金提供リンクを確認しています…」）
• レポートを作成する前にすべてのデータを収集します。 部分的な表を小出しにしないでください。
• 最終レポートは最後に単一のまとまったブロックとして出力します。

レポートテンプレート

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

レポート形式のルール

• 「🎯 貢献できる方法」から始める — これが主要な出力です。番号付きリストで、カバーされる依存関係の合計数の降順に並べます。
• URL はそのままの形で単独の行に — Markdown のリンク構文で囲まないでください。これにより、あらゆるターミナルエミュレーターでクリック可能になります。
• 依存関係の名前をインラインで — 各スポンサーの下に、カバーされる依存関係の名前をカンマ区切りの行で示し、ユーザーが何に資金を提供しているのかを正確に把握できるようにします。
• ヘルスインジケーターもインラインで — 各宛先の隣に ⭐/⚠️/💤 を表示し、別のテーブル列にはしないでください。
• 「📊 カバレッジ」セクションは 1 つ — 簡潔な統計。独立した「検証済み資金提供リンク」テーブルや「資金提供が見つからない」テーブルは作りません。
• 資金提供のない依存関係は簡単な注記として — 件数 + 主要な名前だけ。ギャップを強調するのではなく、「まだ資金提供の設定がされていない」という形で示します。資金提供がないことでプロジェクトを責めてはいけません — 多くのメンテナーは他の形の貢献を好んでいます。
• 💜 GitHub Sponsors、🟠 Open Collective、☕ Ko-fi、🔗 その他
• 同じメンテナーに複数の資金提供元がある場合は、GitHub Sponsors のリンクを優先します。

---

エラーハンドリング

• deps.dev がパッケージに対して 404 を返す場合 → マニフェストを直接読み取り、レジストリ API 経由で解決する方法にフォールバックします。
• deps.dev がレート制限されている場合 → 部分的な結果であることを明記し、取得できた分で続行します。
• get_file_contents がリポジトリに対して 404 を返す場合 → リポジトリが存在しないかプライベートである可能性があることをユーザーに伝えます。
• リンクの検証が失敗した場合 → そのリンクは黙って除外します。
• 部分的であっても必ずレポートを生成します — 決して黙って失敗しないでください。

---

重要なルール

1. 検証していないリンクを決して提示しない。 表示する前にすべての URL を取得してください。検証済みのリンク 5 件 > 推測のリンク 20 件。
2. トレーニング知識から決して推測しない。 必ず確認してください — 資金提供ページは時間とともに変化します。
3. 常に励まし、決して責めない。 結果を前向きに捉えてください — 資金提供されているものを称え、資金提供のない依存関係は失敗ではなく機会として扱います。すべてのプロジェクトが金銭的なスポンサーシップを必要としたり望んだりしているわけではありません。
4. 行動から始める。 「🎯 貢献できる方法」セクションが主要な出力です — クリック可能な URL をそのままの形で、宛先ごとにグループ化して示します。
5. 主要なリゾルバーとして deps.dev を使用する。 deps.dev が利用できない場合にのみ、レジストリ API にフォールバックします。
6. 常に GitHub MCP ツール (get_file_contents)、web_fetch、web_search を使用してください — 決してクローンしたりシェルに抜けたりしないでください。
7. 効率的に。 API 呼び出しをバッチ化し、リポジトリを重複排除し、各オーナーの .github リポジトリは 1 回だけ確認します。
8. GitHub Sponsors に焦点を当てる。 最も実行しやすいプラットフォームです — 他も示しますが GitHub を優先します。
9. メンテナーごとに重複排除する。 グループ化して、一人をスポンサーすることの実際のインパクトを示します。
10. 実行可能な最小限を示す。 最も多くの依存関係を支えるための最小のスポンサーシップ数をユーザーに伝えます。
11. 中間出力を最小化する。 各バッチを告知しないでください。すべてのデータを収集し、その後 1 つのまとまったレポートを出力します。