巨人之肩 (Giants' Shoulders)
「もし私が遠くを見渡せたとしたら、それは巨人の肩の上に立っているからです。」 — アイザック・ニュートン、1675年
概要
何か新しいものを作る前に、誰かがすでに似たものを構築していないか調べてください。 ほとんどのアイデアはすでに試されています。うまく解決されたもの、ひどく解決されたもの、教訓的な理由で放棄されたもの、そしてごく一部は本当に未解決のものです。目標はコピーすることではなく、白紙の状態ではなく現在のフロンティアから始めることです。つまり、実証済みのアプローチを再利用し、既知の行き止まりを回避し、タスクが実際に既存のものとどこで分岐しているのかを明確に把握することです。
エージェント非依存：Web検索が可能なあらゆるエージェント（Claude Code、Codex、Cursor、TRAE、その他）で動作します。ホストが提供する任意のWeb検索/取得ツールを使用してください。このスキルはタスクの開始時、設計やコーディングの前に実行し、比例的に行ってください。文献レビューではなく、短いスキャンです。
実行すべき時とスキップすべき時
実行すべき時：タスクが何か新しいものを作成する、またはアプローチを選択する場合。ツール/スクリプト/ライブラリ/CLI/スキル/プラグイン/エージェント/ワークフロー/統合/プロトタイプ/製品の構築、アーキテクチャの設計、フレームワーク/ライブラリ/アルゴリズムの選択など。
スキップすべき時：些細なタスク（1行の翻訳、変数名の変更、時刻の確認）や、外部の先行事例が存在しないタスク（ユーザー自身のプライベートファイル/データの編集）。価値があるかどうかわからない場合は、一文で尋ねてください：「要不要我先花一两分钟看看有没有现成方案？」
ワークフロー
1. 問題を一行で言い換える
タスクを中核の問題にまで削り、平易な言葉で表現します。ユーザーが選んだ解決策ではありません。例：「CSVの重複排除スクリプトを構築する」→ 中核問題 =「表形式データの行重複排除」。フレーミングが広すぎてツールカテゴリ全体に一致する場合は、検索前にちょうど1つの明確化の質問をしてください（アンケートではなく、最大3つの例示的な次元を提案として提供します）。
2. 検索前に語彙を生成する
異なるコミュニティは同じものに対して異なる言葉を使います。クエリを実行する前に、異なる視点から問題の6～10のフレーミングを書き出し、各検索クエリを1つのフレーミングにマッピングしてください。これにより、最も一般的な失敗モード（5つのクエリすべてが同じ意味上の近隣に着地する）を防ぎます。少なくとも以下をカバーしてください：
- 構築者のフレーミング — ユーザー自身の言葉
- ツール利用者のフレーミング — これを探している人が入力するであろう言葉
- 学術/研究のフレーミング — 該当する場合
- インフラ/実装のフレーミング — 低レベルの名称
- 隣接コミュニティのフレーミング — 隣接分野で先に解決されている可能性が高いもの
少なくとも1つの英語フレーミングを含めてください。ほとんどの先行事例やリポジトリは英語でより良く表面化します。
3. 開発者が実際に公開する場所を検索する
ホストのWebツールを使用します（まず検索し、次に有望なヒットを取得します）。異なるフレーミングとソースにわたって3～6のターゲットクエリを実行してください。1つの汎用クエリを実行して止まらないでください。
| ソース | 見つかるもの | 方法 |
|---|---|---|
| Web検索 | 製品、比較、「最高のX for Y」、ブログ記事 | ホスト検索ツール |
| コードホスト | 実際の実装、ライブラリ、「awesome-*」リスト | site:github.com <問題>、GitLab；gh search repos/code "<キーワード>"（gh CLIが存在する場合） |
| パッケージレジストリ | 既存のライブラリ | npm、PyPI、crates.io、pkg.go.dev、Hugging Face (ML) |
| 製品/コミュニティ | リリースされた製品、体験談 | Product Hunt、Hacker News「Show HN」、関連するsubreddit |
| Q&A/フォーラム | 落とし穴、アプローチが失敗する理由 | Stack Overflow、HNスレッド |
| ドメインの場 | 標準的な方法 | 公式ドキュメント、RFC/標準、arXiv、モデルカード |
一次ソース（リポジトリ、Show HNスレッド、プロジェクトのホームページ）を、アグリゲーターのリスト記事よりも優先してください。200スターのGitHubリポジトリは、Mediumのリスト記事に勝ります。
4. 直接一致したものについて、1層下までトレースする
ここがスキャンの最も頻繁な失敗ポイントです。1層早く止まってしまうことです。プロジェクトのドキュメントに「X上に構築」、「Yをラップ」、「Zの公式ハーネス」、または「Wを通じて実行」と書かれている場合、その名前付きのものがしばしば真の既存ソリューションであり、見つけたプロジェクトは薄いラッパーです。直接一致した中のすべての名前付き依存関係を検索リードとして扱い、結論を出す前に専用のクエリで追跡してください。最初に見つけた（おそらく小さな）プロジェクトに答えを固定しないでください。
5. 発見結果を4つのバケットに分類する
生の結果をそのまま出力しないでください。グループ化してください：
- 直接一致 — 同じ問題、同じアプローチ
- 隣接解決策 — 同じ問題、異なるアプローチ
- 部分解決策 — サブセットを解決
- 放棄/陳腐化 — 存在したが、現在は停止（最終コミット日を記録し、可能であればなぜ停止したのかを記録 — これが最も教訓的な先行事例であることが多い）
6. 標準パターンを抽出する
一致した結果にわたって、何が繰り返し現れるか？共通のアーキテクチャ、ライブラリ、設計上の決定、命名、価格モデル。それが、タスクが構築または競合することになるデフォルトのプレイブックです。
7. タスクの角度を正直にベンチマークする
1段落で、ユーザーの特定のフレーミングと既存のものを比較してください。本当の差別化要因を挙げるか、それが存在しないことを認めてください。良い印象を与えるために新規性をでっち上げたり、網羅的に見せるために競合を捏造したりしないでください。
8. 判断を下し、その後続行する
1つの判断を選び、それを先頭に置いてください（正確な出力形式については references/report-template.md を参照）：
- 既存を利用 — すでにうまく解決されている；最良の選択肢を挙げる
- フォーク/拡張 — 最も近いプロジェクト + 具体的に何を追加するか
- 貢献 — その機能は上流に属する；提案する場所を示す
- 新規構築 — 真のギャップ；差別化要因が明確で防御可能
- 事前調査 — 誰かが試して放棄した；時間を費やす前に理由を理解する
その後、見つけた情報に基づいて実際のタスクに移行してください。発見事項がスコープを実質的に変更する場合（例：成熟したツールがすでにこれを正確に行っている）を除き、承認を求めたりせずに進めてください。その場合はそれを提示して尋ねてください。
予算とガードレール
- タイムボックスを設定する。 合計で最大10クエリを目指し、3～4クエリ後に状況が明確で、かつ少なくとも1つのクエリで依存関係を1層下までトレースした場合（ステップ4）は早めに停止してください。これは実際の作業に先行するものであり、それを支配してはいけません。
- 正直に報告する。 「直接の先行事例は見つかりませんでした」は有効で価値のある結果です。弱い一致や偽の競合で埋めるのではなく、どこを調べたかを述べてください。
- 良いものが存在するのに「新規構築」を推奨しない。 カスタム構築には日常的なメンテナンスコストがかかり、それは過小評価されがちです。何も適合しない場合を除き、デフォルトで利用/適応/貢献を選択してください。
- スター数だけでなくメンテナンス状況を確認する。 最近のコミット、問題への応答、リリースの頻度、バスファクターはスター数よりも多くを明らかにします。安定した500スターのツールは、トレンドの50kスターのツールに勝る可能性があります。
- ライセンスを尊重する。 再利用を提案する際は、プロジェクトのライセンスを記載してください。
- 出典を明記する。 名前を挙げたすべてのアイテムにはリンクを付けて、発見事項が検証可能であるようにしてください。
- ネットワークがない場合？ その旨を伝え、スキャンをスキップしたことを記録し、自分が知っているものにフォールバックしてください。それが記憶ベースであり、古くなっている可能性があることをフラグ付けした上で、先に進んでください。
- 列挙するだけでなく、統合する。 価値は比較（再利用 vs. ギャップ）にあり、リンクの山にはありません。
参考ファイル
references/report-template.md— 正確な出力構造と実例。ブリーフを作成する際に読んでください。
オプション：デフォルトルールにする
デフォルトでは、このスキルはその説明がタスクに一致する場合にのみトリガーされます。スクラッチからの構築タスクの前に自動的に実行されるようにするには、ホストエージェントのインストラクションファイルにルールを追加してください。一度実行します（オプトイン、冪等的、再実行しても安全）：
scripts/install.sh
これにより、Giants' Shoulders をデフォルトルールにするかどうか尋ねられ、はいと答えた場合、見つかったエージェントのインストラクションファイル（Codex/TRAE/Cursor の AGENTS.md、Claude Code の CLAUDE.md）にマーカーでラップされたルールブロックを追加します。拒否した場合は何も書き込まれません。GIANTS_SHOULDERS_ASSUME_YES=1 を設定すると、非対話的にインストールできます。