不慣れなコードベースを説明する
目標：新人に信頼できるマップを、ファイル参照付きで数ページ以内で提供すること。すべての主張は、自身が読んだファイルを指し示さなければなりません。
この順序で調査する
- 目的とユーザー: README、パッケージ説明、ドキュメントのインデックス。このソフトウェアは誰のどんな問題を解決するのか？
- 実行方法: インストール、実行、テストのコマンドをマニフェスト、Makefile、CI設定から確認する。安価なもの（テスト、リント）は実際に実行して動作を確認し、実行しなかったものは明記する。
- 構造: ディレクトリツリーを2階層まで表示する（
node_modules、ビルド出力、.gitは無視）。言語、フレームワーク、モノレポ構成を記録する。 - エントリポイント:
main、サーバー起動ファイル、CLIエントリ、ルート定義、スケジュールジョブ、イベントハンドラ、binおよびscriptsのエントリ。 - 1つの実際のフローをエンドツーエンドでトレースする: 最も中心的なリクエスト、コマンド、またはイベントを選び、エントリからストレージまたは出力までを追跡し、各ファイルと関数を順にリストする。
- データ: スキーマ、モデル、マイグレーション、設定ファイル、コードが読み取る環境変数（名前のみ、値は絶対に表示しない）。
- 外部接続ポイント: データベース、キュー、サードパーティAPI、認証プロバイダ。
- 品質シグナル: テストの場所とそのカバレッジ、CIチェック、リントルール、TODOが残っている箇所、非常に大きなファイル、最近の変更頻度（
git log --since="3 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head）。
出力形式
# <リポジトリ名> を1ページで
目的: ...
実行方法: <コマンド、検証済みかどうか>
マップ: <ディレクトリ -> 責務、各行1行>
1つのフロー、ステップバイステップ: <ファイル:関数 ...>
データと設定: ...
外部サービス: ...
読み始めるべき場所: <ファイル3つを順に、理由付き>
リスクまたは混乱しやすい領域: <ファイル、理由>
未解決の質問: <判断できなかったこと>
ルール
- 各主張に対して
パス:行番号または最低でもパスを引用する。推測した場合は「推測」とラベル付けする。 - 開いていないコードについては説明しない。ビジネスコンテキストを推測せず、未解決の質問に記載する。
.envファイルや設定から秘密の値を絶対に出力しない。変数名のみをリストする。- 簡潔に保つ：すべてのファイルを巡るツアーではなく、マップであること。