analyze

分析

タスク、アイデア、チケット、PR、またはレビュー修正のバックログを調査し、根拠に基づくメモをチャットで返します。Linear や GitHub には書き込みません。

次の場合に読む

• 変更対象のユーザーフロー、画面上のアクション、または UX に関する苦情を調査していますか？コントロールを提案する前に、user-experience.md を開き、現在の開始地点、コンテキスト、継続方法、既存のデザインを確認してください。バックエンドのみの作業では不要です。
• 単一ファイルの依頼に見える場合でも、調査を始めようとしていますか？code-quality.md、code-structure.md、doctrine.md、および実行コンテキストを開いてください。これらを読まないと、ルールに反する修正をメモで提案してしまいます。
• 広範囲に検索したり、大きなファイルを読んだりしようとしていますか？main-context.md を開いてください。これを読まないと、生の検索結果に分析が埋もれてしまいます。
• ユーザーに何かを尋ねようとしていますか？ユーザーへの質問を開いてください。これを読まないと、リポジトリですでに答えがわかることを質問してしまいます。

契約

• リポジトリ、チケット、PR、差分に関する事実を、最新の情報源から改めて確認します。
• ユーザーの判断、ルール、領域、昇格状態（この分析をビルドやチケットに変えることをユーザーが承認したかどうか。詳しくは Apply を参照）は実行コンテキストで明示し、コードではなくユーザーから確認します。
• 分析メモはチャットでのみ返し、状態は実行コンテキストに保持します。
• ユーザーが明示的に依頼し、保存先を承認した場合にのみ、メモを保存します。

仕組みまたは理由のみ

ユーザーが仕組み（ウォークスルー、各レイヤーの担当、レイヤー間の連携方法）だけを知りたい場合は、ここで止めて /how に従います。理由だけを知りたい場合は、ここで止めて /why に従います。バグ、アイデア、影響、またはビルドの種は、引き続きここで扱います。

プロセス

1. 関連する実行コンテキストを確立または更新し、依頼内容を整理します。 親がすでに「完了条件」と維持すべきルールを確定している場合は、プロダクトの意図を再度問いたださず、それらを再利用します。
2. doctrine の調査ルールに従い、影響を受けるフローを調査します。デザインを提案する前に、事実、確定済みの判断、通常の実装者に委ねられる判断、未解決のトレードオフを分けます。
   • 重要な機能変更や境界の変更、または観測されたアーキテクチャ上の摩擦がある場合は、公開境界の調査を適用します。契約を維持する小さな変更では不要です。
   • 境界について独立した不確実性がある場合は、範囲を限定した調査を使います。
   • 既存の仕組みや履歴によって分析が変わる可能性がある場合は、その限定的な質問について /how または /why を使い、結論、情報源、不確実性をメモに引き継ぎます。どちらも新しいデザインを選んだり、別の聞き取りを始めたりはしません。
   • 親の配下にある場合は、ネストされた機能に従い、標準のメモは作成せず、事実、結論、情報源への参照、不確実性を返します。
3. 単独で実施する場合は、doctrine のメモを投稿します。Mermaid の図から始めます。 作業をビルド可能な場合は、インラインの実行シードを含めます。

レビュー修正

アクティブなオーケストレーターが、修正の「今すぐ修正」対象として指定された行の分析を求めた場合にのみ、このモードを使います。安定した各指摘 ID に対応付けて、根本原因、最小限の修正、変更対象範囲、不確実性、検証方法を返します。指摘の追加、プロダクトの調査、フォローアップは行いません。オーケストレーターが一度だけ裁定して割り当てます。分析によって、実装への昇格や実装ライフサイクルの開始は行いません。

親がすでに次のステップを管理している場合

ネストされた機能に従います。範囲を限定した根拠と提案を返します。親がすでに実装を承認している場合も含め、準備、昇格、次のステップはすべて親が管理します。

これがユーザーの単発の依頼の場合

実際に不明な点をまとめて質問し、doctrine.md に記載されている明示的な引き継ぎの選択肢（Done / Sharpen / Promote / Write ticket / Promote + start）を提示します。ユーザーが次のステップをすでに指定している場合を除き、これらの質問をし、親ブリーフなしで作業します。

アンチパターン

• メモの代わりに、検索結果をそのまま列挙する
• 純粋な「方法」や「理由」の質問に、このメモで回答する
• チケットを作成する、コードを実装する、またはテストを書く