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、ウェブ検索フォールバック。
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"

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

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 リポジトリごとに 1 回だけ ルックアップし、そのオーナーのすべてのリポジトリで結果を再利用します。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 以外のエコシステムでスキップ。
• リポジトリを重複排除 — 各リポジトリを 1 回だけチェック。
• 一意のオーナーごとに 1 つの {owner}/.github チェック — そのオーナーのすべてのリポジトリで結果を再利用。
• オーガニゼーションレベルのルックアップを 10 個のオーナーずつバッチで処理します。

---

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

ANY ファンディングリンクを含める前に、存在することを確認してください。

各ファンディング URL で web_fetch を使用：

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

5 個ずつバッチで検証します。未検証のリンクは決して提示しないでください。

---

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

出力の厳密性

データ収集中の中間出力を最小化してください。 各バッチを発表しないでください（「バッチ 3/7…」、「ファンディングをチェック中…」）。代わりに：

• 各主要フェーズの開始時に1 行の簡潔なステータスを表示（例：「67 個の依存関係を解決中…」、「ファンディングリンクをチェック中…」）
• すべてのデータを収集した後、レポートを作成してください。 部分的な表を段階的に提示しないでください。
• 最終レポートを終了時に 1 つの統一されたブロックとして出力。

レポートテンプレート

## 💜 Sponsor Finder レポート

**リポジトリ：** {owner}/{repo} · {ecosystem} · {package}@{version}
**スキャン日時：** {date} · {total} deps（{direct} direct + {transitive} transitive）

---

### 🎯 還元方法

わずか {N} 人/オーガニゼーションをスポンサーすることで、{total} 個の依存関係のうち {sponsorable} 個をサポート — プロジェクトが依存しているオープンソースに投資する素晴らしい方法です。

1. **💜 @{user}** — {N} direct + {M} transitive deps · ⭐ 積極的に保守中
   {dep1}, {dep2}, {dep3}, ...
   https://github.com/sponsors/{user}

2. **🟠 Open Collective: {name}** — {N} direct + {M} transitive deps · ⭐ 積極的に保守中
   {dep1}, {dep2}, {dep3}, ...
   https://opencollective.com/{name}

3. **💜 @{user2}** — {N} direct dep · 💤 低活動
   {dep1}
   https://github.com/sponsors/{user2}

---

### 📊 カバレッジ

- **{sponsorable}/{total}** 個の依存関係にファンディングオプションがあります（{percentage}%）
- **{destinations}** 個のユニークなファンディング先
- **{unfunded_direct}** 個の直接依存がまだファンディングをセットアップしていません（{top_names}, ...）
- すべてのリンク検証済み ✅

レポート形式ルール

• 「🎯 還元方法」でリード — これがプライマリ出力です。番号付きリスト、カバーする依存関係の総数でソート（降順）。
• bare 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. アクションでリード。 「🎯 還元方法」セクションがプライマリ出力です — bare でクリック可能な 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. メンテナーによって重複排除。 グループ化して 1 人をスポンサーすることの実際の影響を示します。
10. 実行可能な最小限を表示。 ユーザーに最も多くの依存関係をサポートするための最少スポンサーシップを伝える。
11. 中間出力を最小化。 各バッチを発表しないでください。すべてのデータを収集してから、1 つの統一されたレポートを出力。