explaining-architecture

アーキテクチャの説明

「X はどのように動作しますか？」という質問には、見慣れないサブシステムで作業を始めるためにシニアエンジニアが必要とするメンタルモデルを示します。アーキテクチャ、処理の流れ、注意すべき点を説明し、注釈付きのソースコードにはしません。

質問が仕組みではなく、動機、却下された代替案、経緯について尋ねている場合は、Skill ツールを使って investigating-design-rationale を呼び出してください。そのスキルがインストールされていない場合は、そのことを伝え、仕組みだけを回答してください。Skill ツールがない場合は、 スキルの呼び出しルールに従ってください。

このスキルは読み取り専用です。ファイルへの書き込みや状態の変更は行いません。ドキュメントに書かれていることではなく、コードが実際に行うことを説明し、食い違いがあればドキュメントとコードのルールに従って報告してください。

入力

リクエストには、サブシステム、機能の処理フロー、または配置に関する質問（「このバリデーションはどこに配置すべきか」など）が指定されます。何も指定されていない場合や曖昧な場合は、会話の文脈から対象を推測し、調査を始める前にその解釈を一行で述べてください。最初に質問を返してはいけません。

説明

実装を読み、ファイル名や関数名から動作を推測してはいけません。各処理の流れを、きっかけから結果までたどってください。つながりをたどれない箇所は、作り上げずにその旨を伝えてください。コードに関する主張には file:line を付け、処理の各ステップでは実行される関数名を示してください。

質問に合わせて回答し、必要なセクションだけを使ってください。

• 概要：それが何で、何を行い、なぜ存在するのかを、1〜2段落で説明します。
• 主要な概念：以降の説明を理解するために必要な抽象概念です。
• 動作の仕組み：きっかけ、手順、データの流れ、判断箇所を文章で説明します。複数のコンポーネントをまたぐ処理の流れに限り、Mermaid の図を追加します。
• 関連ファイル：作業を始めるために必要なファイルの概要であり、すべてのファイルを列挙するものではありません。
• 注意点：意外な動作、過去の名残、注意すべき点です。

複雑な仕組みには、その理由も説明してください。調査方法、質問で求められていない背景、説明の繰り返しは省いてください。

批評

リクエストで問題、課題、改善点が尋ねられている場合に限り実施してください。まず説明を終えてから、批評モードに従ってください。