GitHub 先行実装リサーチ

目的に合う先行実装を見つけ、何を参考にできるかと未確認点を短く報告する。通常は候補発見と README・公開メタデータの軽い確認で完了する。

進め方

1. 依頼と手元の文脈から、作りたい機能、技術・実行環境、参考にしたい範囲（設計、UI、アルゴリズム等）、ライセンスの許容範囲を整理する。未指定なら暫定条件を明示して探索を進め、採用判断を変える不明点だけ確認する。
2. 次の二経路をそれぞれ試し、結果を統合する。
   • 定番起点: 機能名・同義語・技術名・topics で探し、star 順などで広く使われる候補を拾う。star 数だけで定番や適合性を確定しない。
   • 作者起点: 関連分野の既存 OSS の作者・主要貢献者、公開プロフィールや技術記事から作者を見つけ、その人や組織の公開リポジトリを star の下限なしで探す。作者の人気だけでなく、今回の分野に関係する OSS や主要貢献のリンクを根拠にする。所有者と実際の作者・貢献者を同一視しない。
3. 残す候補の README、対応環境、利用例・デモ、公開状態、star 数、更新状況、ライセンス表示を軽く確認する。作者起点では既存の関連実績も少数の公開資料で確認する。用途を具体的に説明できる候補が揃えば止める。片方で有用な候補が出なければ、その旨を残し、枠を埋めるために追加しない。
4. 候補ごとに「どこを参考にするか」と選定理由を示す。コードの採用・コピー・依存導入に進む際は、対象版の実 LICENSE と必要な NOTICE・個別ファイルの条件を確認する。検索結果のライセンス名だけで利用可否を確定しない。

判断とツール

• gh CLI の検索・メタデータ取得を優先する。作者の専門分野の実績や紹介記事は Web 検索で補い、一次資料へ辿る。GitHub コネクターやブラウザが適していれば使う。CLI が使えない場合も、利用できる公開情報で進めて制限を示す。
• 検索・閲覧は public repo に限定する。認証済みでも private/internal のコード・メタデータを収集・報告せず、非公開情報や秘密を外部検索語・ツール入力に含めない。リポジトリを明示し、カレントリポジトリの暗黙参照を避ける。
• star 閾値、候補数、更新日の足切りは調整可能な例であり、固定要件にしない。低スターを一律除外しない。古い実装や archived repo も、設計・アルゴリズム等の参考用途なら残し、現行環境への適用は未確認とする。
• 作者の評判や投入労力を直接検索する qualifier はない。初回公開・bot の依存更新・大量のコードや commit は、努力や品質の証明にしない。設計説明・利用例・実際の利用報告等を手掛かりにし、労力が不明なら不明とする。全候補に履歴監査を課さない。
• README の主張、コードを読んで確認した事実、実行して確認した事実を区別する。未読コードの実装品質や、未実行の動作・性能を断言しない。

通常の出力

最初に要件・暫定条件を一言で示し、各候補を短い箇条書きか表で比較する。

• 候補名と公開 URL、発見経路、選定理由、何を参考にできるか。
• star 数と確認日（変動値）、作者の関連実績を裏付けるリンク。未確認ならその旨。
• ライセンス表示と実 LICENSE 確認の有無、用途への適用で残る未確認点。

末尾に主要な検索語と、優先して読む候補・箇所を短く添える。通常は履歴・PR・テストの精密調査やクローン・実行まで広げない。

必要なときだけ読む資料

• 検索式・引数・JSON フィールドを組むとき: 検索例と制約。Users と Repositories の followers は別の対象を数える。
• ユーザーが深掘りを依頼したとき、または特定候補の重要な不明点を解消するときだけ: 任意の深掘り。常時ロードや通常工程への組み込みは不要。