github-search

GitHub Search

概要

コードを一行でも書く前に、世界の誰かが同じ問題をすでに解決し、その成果を公開していないかを確認してください。すでに行われた作業を見極めることこそ、最も優れたエンジニアリング上の判断です。

基本原則： 新しいものを作る前に、GitHub のリポジトリ、パッケージレジストリ、オープンソースのエコシステムで既存の実装を検索してください。複数のプロジェクトから優れたパターンを取り入れてください。借用したものは明記してください。ライセンスを尊重してください。

例外なし。回避策なし。近道なし。

最優先の指針

NO BUILDING FROM SCRATCH WITHOUT SEARCHING GITHUB FIRST

既存の解決策を求めて公開リポジトリを検索していないなら、すでに解決済みの問題を再発明するために時間を浪費しています。異なる方法で3回検索しても該当するものが見つからなかった場合は、何を検索し、なぜ適合しなかったのかを記録してください。その後で実装してください。

言い訳は無用です：

• 「まずコーディングを始めて、調査は後で」と考えないでください
• 問題が斬新に感じられるという理由だけで、独自性があると思い込まないでください
• 「単純な」機能だからといって調査を省かないでください（単純な機能ほど、既存の実装例が豊富です）
• 不完全だという理由でリポジトリを却下しないでください（価値ある部分を取り入れてください）
• 「実装方法を知っている」ことと「ゼロから実装すべきである」ことは同じではありません

使用する場面

必須の場合：

• 新しい機能やプロジェクトに着手するとき
• オープンソースとして存在する可能性があるものを作るとき
• 複数の実装方針を比較検討するとき
• 実際のシステムからアーキテクチャ上の先例を探すとき
• フレームワーク、ライブラリ、ツールを評価するとき

特に有用な場合：

• 広く使われているパターン（認証、CRUD、ファイル処理、検索、決済）を扱うとき
• ゲームを作るとき（あらゆるジャンルに、膨大なオープンソースの事例があります）
• 既知の問題領域に対応するユーティリティを作るとき
• アルゴリズムや特殊なデータ構造を実装するとき
• インフラストラクチャ（CI/CD、デプロイパイプライン、監視）を構築するとき
• 確立された慣習がある API、スキーマ、プロトコルを設計するとき

着手プロトコル

digraph github_search_gate {
    rankdir=TB;
    start [label="Task: Build something", shape=doublecircle];
    search [label="SEARCH\nGitHub, registries,\nopen-source ecosystems", shape=box];
    found [label="Relevant repos found?", shape=diamond];
    evaluate [label="EVALUATE\nStars, maintenance,\ncode quality, license, fit", shape=box];
    usable [label="Directly usable\nas a dependency?", shape=diamond];
    install [label="INSTALL\nAdd as dependency", shape=box style=filled fillcolor=lightgreen];
    harvestable [label="Harvestable\npatterns?", shape=diamond];
    harvest [label="HARVEST\nExtract patterns, adapt\nto your codebase", shape=box style=filled fillcolor=lightyellow];
    studyable [label="Useful as a\nlearning reference?", shape=diamond];
    study [label="STUDY\nAbsorb architecture,\nthen build your own", shape=box];
    build [label="BUILD FROM SCRATCH\nRecord: searched, nothing fit", shape=box];
    record [label="Document search queries\nand findings", shape=box];

    start -> search;
    search -> found;
    found -> evaluate [label="yes"];
    found -> record [label="no"];
    record -> build;
    evaluate -> usable;
    usable -> install [label="yes - strong fit"];
    usable -> harvestable [label="no - too heavy\nor wrong scope"];
    harvestable -> harvest [label="yes - valuable patterns"];
    harvestable -> studyable [label="no - different paradigm"];
    studyable -> study [label="yes - learn from it"];
    studyable -> build [label="no - genuinely nothing relevant"];
}

何かを作る前に、必ず以下を行ってください：

1. 検索 -- GitHub、パッケージレジストリ、より広範なオープンソースのエコシステムを検索します
2. 評価 -- 候補の品質、関連性、ライセンスとの適合性を評価します
3. 判断 -- 依存関係として利用する、パターンを取り入れる、参考資料として調査する、またはゼロから作る、のいずれかを選びます
4. 記録 -- 見つかったものと、その方針を選んだ理由を記録します
5. その後に限り -- 作り始めます

検索方法

検索先

何も存在しないと結論付ける前に、複数の経路を広く検索してください。

1. GitHub Search: github.com/search (code, repositories, topics)
2. GitHub Topics: github.com/topics/{topic}
3. WebSearch: "github {what you need} {tech stack}"
4. Package registries: npmjs.com, pypi.org, crates.io, rubygems.org, pkg.go.dev
5. Curated lists: awesome-{topic} repositories on GitHub
6. Framework ecosystems: official plugin/extension directories

効果的な検索クエリ

複数クエリを使うこと -- 1回の検索で済ませないでください。

クエリの種類	例	見つかるもの
文字どおりの名前	tetris javascript	概念に完全一致するもの
問題の説明	real-time collaboration websocket	同じ問題を対象とする解決策
技術スタック＋パターン	vue authentication oauth2	特定の技術に基づく実装
類義語の探索	kanban board / task tracker / project manager	用語は異なるが同じ概念のもの
厳選されたコレクション	awesome-react / awesome-python	コミュニティによって評価されたリスト

「何も存在しない」と判断する前の最低基準： 2つ以上の検索経路で、表現を変えた異なるクエリを3つ以上実行してください。

検索対象

digraph search_scope {
    "What am I building?" [shape=diamond];
    "Complete application?" [shape=diamond];
    "Feature or module?" [shape=diamond];
    "Search for full repos" [shape=box];
    "Search for libraries + example repos" [shape=box];
    "Search for code snippets + patterns" [shape=box];

    "What am I building?" -> "Complete application?" [label="assess"];
    "Complete application?" -> "Search for full repos" [label="yes"];
    "Complete application?" -> "Feature or module?" [label="no"];
    "Feature or module?" -> "Search for libraries + example repos" [label="yes"];
    "Feature or module?" -> "Search for code snippets + patterns" [label="no"];
}

リポジトリの評価

見つかったリポジトリを評価する際は、以下の指標を体系的に適用してください。

指標	肯定的な兆候	否定的な兆候
人気度	100 件以上のスター（コミュニティから評価されている）	0～5 件のスター（十分に検証されていない）
メンテナンス状況	6 か月以内にコミットがある	2 年以上更新されていない
コミュニティの健全性	活発な議論、マージ済みの PR	放置された Issue が数百件あり、メンテナーからの応答がない
ライセンス	MIT、Apache 2.0、BSD	GPL（寛容なライセンスが必要な場合）、ライセンスがない
コードの規律	テスト、型、ドキュメント、明快な構成	テストがない、型がない、複雑に絡み合ったコード
依存関係の規模	最小限で、よく知られた依存関係	50 個以上の間接依存関係、無名のパッケージ
ドキュメント	明確なセットアップ手順、使用例	README が空、または古い
関連性	必要なことの 70％以上をカバー	関連性が薄い

最低限満たすべき条件： テストとライセンスがあり、過去 1 年以内に更新され、README に使用方法が説明されています。

クイック評価チェックリスト

For each candidate repository:

1. STARS & FORKS: Gauge community trust (100+ stars is a reasonable floor)
2. LAST COMMIT: Anything older than 18 months is a maintenance risk
3. OPEN ISSUES: High count with no maintainer replies signals abandonment
4. LICENSE FILE: No license means you cannot legally use it
5. TEST DIRECTORY: No tests means no confidence in correctness
6. README QUALITY: Poor docs usually correlate with poor internal structure
7. DEPENDENCIES: Check for bloated or unmaintained transitive deps
8. RELEASE CADENCE: Regular releases indicate ongoing investment

パターンの抽出

リポジトリをそのまま利用できない場合でも、価値のあるパターンが含まれていれば、適切に抽出してください。

フェーズ 1：抽出できる価値を特定する

FROM the repository, extract:
- Architectural patterns (how they organized the project)
- Algorithm implementations (how they solved the hard parts)
- Data models (how they structured domain entities)
- Interface designs (how they shaped the public API)
- Error handling approaches (how they manage edge cases)
- Test strategies (how they verify similar functionality)

フェーズ 2：自分のコンテキストに適応させる

DO NOT copy-paste entire files.
DO extract the pattern and rewrite for your:
- Technology stack
- Naming conventions
- Design system (for UI code)
- Architectural layering
- Internal codebase conventions (use godmode:codebase-research to find them)

フェーズ 3：出典を明記する

In your codebase or documentation, note:
"Approach inspired by github.com/author/repo - [what was adapted]"

ライセンスの互換性

見つかったリポジトリのコードを使用する前に、ライセンスの互換性を確認してください。

プロジェクトのライセンス	互換性のあるソースライセンス
MIT	MIT、BSD、Apache 2.0、ISC、Unlicense
Apache 2.0	MIT、BSD、Apache 2.0、ISC、Unlicense
GPL	任意（GPL は取り込むコードに対して寛容です）
プロプライエタリ	MIT、BSD、Apache 2.0、ISC、Unlicense
任意	絶対に使用しない：ライセンスの記載がないもの、AGPL（完全に遵守する場合を除く）

判断に迷う場合： MIT と Apache 2.0 は、ほぼすべてのプロジェクトで安全に使用できます。GPL を使用する場合、プロジェクトも GPL にする必要があります。ライセンスがない場合、著作権はすべて作者に留保されています。使用しないでください。

複数ソースからのパターン抽出

複雑な機能では、複数のリポジトリからパターンを組み合わせるのが最適な方法であることがよくあります。

Example: Building a real-time collaborative editor

Repo 1 (github.com/x/rich-editor): Polished prosemirror integration
  -> Harvest: Editor initialization pattern, schema definition approach

Repo 2 (github.com/y/crdt-sync): Clean CRDT implementation for text
  -> Harvest: Conflict resolution algorithm, operation transformation logic

Repo 3 (github.com/z/ws-rooms): WebSocket room management
  -> Harvest: Connection lifecycle, reconnection strategy, presence tracking

Result: Your implementation synthesizes the strongest elements from 3 repos,
each designed by specialists in their domain.

ユーザーへの報告：

見つかったものを、リンク付きのラベル付きオプションとして提示してください。推奨するものには星印を付けてください。

I found [N] relevant repositories. Here are the top candidates:

**A)** [repo-name] — [stars] stars, [license]
   Link: [GitHub URL]
   Extractable: [specific patterns/code worth harvesting]
   Fit: [what percentage of your need it covers]

**B)** [repo-name] — [stars] stars, [license]
   Link: [GitHub URL]
   Extractable: [specific patterns/code worth harvesting]
   Fit: [what percentage of your need it covers]

**C)** [repo-name] — [stars] stars, [license]
   Link: [GitHub URL]
   Extractable: [specific patterns/code worth harvesting]
   Fit: [what percentage of your need it covers]

**D) Multi-source harvest** — Best patterns from all three ⭐ Recommended
   From A: [what to extract]
   From B: [what to extract]
   From C: [what to extract]
   Build from scratch: [what is unique to this project]
   Why: Combines battle-tested patterns from [N] production systems

Check out the repos and pick A, B, C, or D.

YoloMode の例外： 参照先とリポジトリの選択は常に対話形式で行います。YoloMode であっても、選択肢を提示し、ユーザーに選んでもらってください。これらの選択は影響が大きいため、自動で決定してはいけません。

認知の落とし穴

正当化	真実
「他人のコードを調べるより、自分で作るほうが早い」	そのコードを無期限にメンテナンスすることにもなります。実績のあるコードは欠陥が少なくなります。
「自分の状況にぴったり合うものは存在しない」	3 種類以上のクエリを試しましたか？一部だけ一致するものにも価値があります。
「オープンソースの品質は信頼できない」	1,000 件以上のスターとテストスイートを備えたリポジトリは、時間に追われて自分で作るものより優れていることがよくあります。
「まず書き始めるほうが早い」	誰かがすでに解決した問題に、何時間も費やすことになります。
「外部依存関係を避けたい」	依存関係を追加せずにパターンを抽出できます。知識は無料です。
「ライセンスは複雑すぎる」	MIT／Apache／BSD なら無料で使用できます。2 秒確認するだけで、同じものを作り直さずに済みます。
「たった 100 行だから、調べるほどの価値はない」	すでに誰かが書いたエッジケースを網羅する 100 行は、それがない自分の 100 行より優れています。
「行き詰まったら調べる」	まず調べてください。行き詰まった時点で、すでに時間を無駄にしています。

ガードレール

禁止事項：

• 最初に検索せず実装を始めること（最低3件の検索）
• すべての検索結果を評価せずに却下すること
• ライセンスとの互換性を確認せずにコードをコピーすること
• ライセンスのないリポジトリを使うこと（法的リスクがあります）
• 自分のソリューションが、実績のあるソリューションを上回ると思い込むこと
• パターンを取り入れる際に帰属表示を省略すること

必須事項：

• 異なる表現のクエリを少なくとも3つ使って検索すること
• 評価基準に照らして候補を評価すること
• コードを利用する前にライセンスとの互換性を確認すること
• 見つけた内容と判断の根拠を記録すること
• 直接利用しないリポジトリからもパターンを取り入れること
• リンク、人気度の指標、抽出する内容とともに調査結果をユーザーに報告すること

クイックリファレンス

SEARCH -> EVALUATE -> DECIDE -> DOCUMENT -> BUILD

Search: 3+ queries across GitHub, registries, and curated lists
Evaluate: Stars, activity, tests, license, relevance
Decide: Use as dependency | Harvest patterns | Study as reference | Build from scratch
Document: What you searched, what you found, why you chose your path
Build: With patterns from research, not from assumptions

統合

以下の場面で呼び出されます：

• godmode:intent-discovery — 「プロジェクトのコンテキストを調査する」フェーズおよび調査フェーズで検索します
• godmode:reference-engine — 外部コードやライブラリの調査に利用します
• godmode:task-planning — 計画タスクでリファレンスリポジトリを参照します
• godmode:system-design — 公開リポジトリからリファレンスアーキテクチャを見つけます

補完的なスキル：

• godmode:codebase-research — 現在のコードベース内を検索し、照合する内部パターン、規約、既存の実装を探します
• godmode:specification-first — 検索結果を正式な仕様に反映します
• godmode:ux-patterns — コードパターンにはリポジトリを、デザインパターンにはUXシステムを利用します
• godmode:design-integration — ブートストラップに使うデザインシステムのリポジトリを探します
• godmode:project-bootstrap — スターターテンプレートやボイラープレートプロジェクトを探します