reviewing-design-docs

エンジニアリング設計ドキュメントのレビュー

入力

• リクエストには、1つの設計ドキュメントのパスが指定されています。
• URLまたは貼り付けられたテキストの場合は、リポジトリ外のスクラッチファイルに Markdown として保存し、そのパスをレビューしてください。取得に失敗した場合は、URLとエラーを報告してください。
• リクエストにドキュメントの指定がない場合、ディレクトリが指定されている場合、または読み取り可能なファイルが指定されていない場合は、パスを尋ねて待機してください。決して推測しないでください。

レビュアー

• このセッションには作成者との会話が含まれるため、ドキュメントをレビューできません（独立レビューのルール）。
• 設計レビュアー向けブリーフを、各観点につき1回ずつ、それぞれ新しいコンテキストのサブエージェントで実行してください。この会話をフォークしたものは使わず、読み取りと検索のツールのみを使ってください。観点は順に、naive-reader、decisions、readiness、accuracyです。すべてのドキュメントに対して、すべての観点を実行してください。
• 各観点の実行には、ドキュメントの絶対パス、観点名、およびレポート形式と指摘事項の形式のパスを渡してください。これらはすべての実行で読み取ります。また、設計テンプレートのパスも渡してください。これはreadinessが読み取ります。さらに、意思決定記録のルールのパスも渡してください。これはdecisionsが読み取ります。
• 各観点のレポートがすべて判定行のチェックに合格した後、統合担当向けブリーフを、新しいコンテキストのサブエージェントで実行してください。この会話をフォークしたものは使わず、読み取りと検索のツールのみを使ってください。ドキュメントの絶対パス、各観点のレポート全文（観点名を明記）、およびレポート形式と指摘事項の形式のパスを渡してください。
• 作成者とのやり取りは渡さず、他の観点のレポートを各観点に渡さないでください。
• そのようなサブエージェントを実行できない場合は、いずれの観点の実行も開始せず、実行できない旨を伝えてください。インラインでレビューしてはいけません。

判定と提示

• 各観点のレポートと統合レポートに、この判定行のチェックを適用してください。
• レポートの1行目は、必ず**Verdict: APPROVE**、**Verdict: REQUEST CHANGES**、または**Verdict: COMMENT**のいずれかと完全に一致させてください。
• このチェックはモデルが行います。セッションがレポートを提示するためにすでに読み取っている1行と照合します。
• レポートがチェックに不合格の場合は、不合格となったチェックを伝え、同じ入力で新しいサブエージェントを1つ実行してください。統合担当の再実行では、同じ各観点のレポートを再利用し、各観点の実行はやり直しません。
• いずれかの観点のレポートが2回不合格となった場合は、他のすべての観点の実行と、その各1回の再試行が完了するまで待ち、統合担当を実行しないでください。統合レポートが2回不合格となった場合は、直ちに停止してください。
• どちらの場合も、各レポートの最新の試行結果を全文で出力し、観点名またはmergedを明記してラベル付けしてください。最初の不合格結果は出力しません。不合格となったチェックを明記し、判定に至らなかったことを伝えて停止してください。判定を自分で修正してはいけません。
• 統合レポートを全文で出力してください。
• いずれかのサブエージェントの読み取り専用制限が、ツールの権限ではなくプロンプトに基づいていた場合は、統合レポートの後、または停止時に出力するレポートの後に、1行でその旨を伝えてください。
• ドキュメントを修正してはいけません。REQUEST CHANGESの場合、対応方法はユーザーが決めます。
• スクラッチコピー以外のファイルを書き込んではいけません。