review-code

review-code — 呼び出しごとに1つの観点

変更を1つのレビュー観点で監査し、指摘事項を報告します。その観点のリファレンスのみを読み込みます。

入力

$ARGUMENTS には、観点と任意の対象範囲を指定します。例：dimension=code-bugs、code-bugs src/foo.ts。ゲート判定を依頼する呼び出し元は、評価対象の主張と、意図的に指定する重大度、カテゴリ、承認ポリシーも提示します。Manifest ゲートには主張と情報源の権威性が含まれ、Evidence には観点が示されます。観点が指定されていない場合は、利用可能な観点を列挙して、どれを使うか尋ねます。1回の呼び出しにつき、観点は1つです。尋ねる相手がいない場合は、観点が指定されていないため BLOCKED と報告してください。観点を指定すれば解決します。

観点

プロジェクトの変更をレビューする前に、プロジェクトのコンテキストファイルにある原則スキルへのポインターを確認してください。原則スキルとは、プロジェクトのメンバーが各領域の作業をどのように進めたいかを定めた、<area>-principles という名前のプロジェクトスキルです。変更が関わる領域ごとに、そのスキルを読み込みます（../setup-project/references/PRINCIPLES_SKILLS.md → Using one）。依頼された観点の references/<dimension>.md を読み込み、その指示に従ってください。そこに記載された基準は、意見を含むデフォルトです。ユーザーがセッションまたはコンテキストファイルで示したルール、読み込んだ原則スキルにある原則、あるいはプロジェクトが明示または文書化している規約（コードで繰り返されているだけのパターンは除く）と異なる場合は、そのルールが優先されます。そのルールに従った変更については指摘を挙げず、適用したルールをレポートに明記してください。ただし、以下の重大度基準における Critical の指摘は例外で、適用したルールを明記したうえで報告します。指摘は影響に基づいて分類します。受け入れのしきい値と対応方針は、呼び出し元が決定します。

観点	リファレンス	役割
change-intent	references/change-intent.md	欠陥検出
code-bugs	references/code-bugs.md	欠陥検出
contracts	references/contracts.md	欠陥検出
type-safety	references/type-safety.md	欠陥検出
defect-class	references/defect-class.md	欠陥検出
operational-readiness	references/operational-readiness.md	アドバイザリー
code-design	references/code-design.md	アドバイザリー
code-maintainability	references/code-maintainability.md	アドバイザリー
code-simplicity	references/code-simplicity.md	アドバイザリー
code-testability	references/code-testability.md	アドバイザリー
test-quality	references/test-quality.md	アドバイザリー
docs	references/docs.md	アドバイザリー
prose-value	references/prose-value.md	アドバイザリー
context-file-adherence	references/context-file-adherence.md	アドバイザリー

役割は、何を確認するかを定めます。欠陥検出では、逸脱、欠陥、契約の不一致、型の穴を、明示したトリガーとともに報告します。アドバイザリーでは、製品や品質上の不足を評価します。どちらの役割も共通の重大度基準を使いますが、どの指摘に対応すべきかを決めるのは、いずれの役割でもありません。

条件付きで適用される観点もあります。適用するかどうかは、依頼する前に呼び出し元が判断します。変更が API サーフェスまたは永続的なデータ契約に関わる場合の contracts、型付きコードに対する type-safety、そして変更が欠陥を修正する場合の defect-class です。defect-class は、出力として欠陥を検出するのではなく、入力として欠陥を受け取る唯一の観点です。修正が実証されたメカニズムをどれだけ防ぐかを、影響を受ける箇所も考慮して判定します。そのため、何も修正しない変更には入力がなく、判定対象もありません。それでも defect-class を依頼することは問題ありません。対象範囲に修正が見つからないと報告し、指定された受け入れポリシーを適用します。

スコープの決定（すべての観点で共通）

フォローアップの依頼では、依頼者から以前に評価した状態と基準、指摘事項、サポートされている処置、確認済みの修正、およびその評価以降の変更が提示されます。該当する情報を使用してください。その評価以降に基準が変更されている場合は、以下のとおりスコープを定めて新たにレビューします。以前の基準では対象にならなかった作業は、一度もレビューされていないためです。そうでない場合は、未解決の指摘事項と、途中の変更によって生じた、または明らかになった問題を報告し、以前の指摘事項のうち修正されたものについては根拠を示してください。必要に応じて広くコンテキストを読み取ってください。変更された行に以前からの問題があっても、その行が変更されたというだけで新たな問題になるわけではありません。必要な以前の状態が欠けている場合は、それを復元するか、不足している情報を示して BLOCKED と報告してください。変更全体を黙って再レビューしてはいけません。新しい ID や同じ主張の繰り返しによって、根拠をもって下された処置が再び未解決になることはありません。ただし、コード、基準、主張、または根拠が変わった場合はその限りではありません。以前のレビュアーとの一致を求めず、独立して根拠を評価してください。

新規レビュー（以前の報告がある場合の新たな単独レビューを含む）では、次のようにスコープを決定してください。

1. 依頼者がファイル／パスを指定している場合 → その対象だけをレビューします。
2. それ以外の場合 → 変更全体をレビューします。PR のターゲット、またはリポジトリのリモート既定ブランチから比較の基点を決定します。どちらも特定できない場合に限り質問し、質問できる相手がいなければ、特定できなかった基点を明示して BLOCKED と報告します。コミット済みの変更は git diff <base>...HEAD、ステージ済みの変更は git diff --cached、未ステージの変更は git diff で確認し、関連する新規ファイルは git ls-files --others --exclude-standard で確認します。新規ファイルはそれぞれ内容を読み取ってください。パスの一覧だけでは差分になりません。
3. 差分が空、またはレビューできない場合 → 依頼者にスコープの明確化を求めます。質問できる相手がいない場合は、「決定されたスコープにはレビュー可能な変更がなく、レビュー可能な変更を含むスコープを指定すれば解決する」と示して BLOCKED と報告します。

スコープ内にとどまり、明示的に依頼されない限り、プロジェクト全体を監査してはいけません。生成されたコピー、ロックファイル、ベンダー依存関係、バイナリは対象外とします。リポジトリの所有関係やビルドルールを確認して、どのファイルが生成物かを特定してください。dist/ や build/ という名前のディレクトリにも、レビューが必要なソース管理対象のファイルが含まれている場合があります。

読み取るスコープ ≠ 報告するスコープ。 差分は報告対象を限定します（既定では、変更によって生じた、または明らかになった問題のみ）。読み取る対象は限定しません。仕組みを必要な限り追跡し（既存の呼び出し元、共有状態、上流の書き込み元など）、変更されたコードと変更されていないコードの境界にある問題も見逃さないようにしてください。広く読み、狭く報告します。決定されたスコープ内では、読み込んだ参照資料に記載されたすべてのカテゴリに照らして、各ファイルを漏れなく調べてください。手を抜いたり、領域を飛ばしたりしてはいけません。報告基準（実行可能性フィルター、または欠陥クラスの場合は受け入れルール）を満たす指摘事項のみを報告してください。

既存の問題の一覧（依頼された場合のみ）。 新規の全体確認で依頼者が求めた場合は、## Pre-existing セクションを追加してください。ここには、変更のために読み取ったコード内で気づいたもので、読み込んだ観点の対象であり、変更によって生じたものでも明らかになったものでもなく、スコープ以外の実行可能性基準を満たす問題を記載します。欠陥検出の観点では明示されたトリガー、アドバイザリーの観点で Medium とする場合は明示されたコストが必要です。依頼者が指定した重大度とカテゴリを尊重してください。この一覧への対応は依頼者が判断します。これらは指摘事項ではなく、判定やサマリーの件数には決して含めません。依頼されない限りこのセクションを追加せず、フォローアップでは依頼された場合でも追加しないでください。フォローアップのスコープは、未解決の指摘事項と、途中の変更によって生じた、または明らかになった問題に限られます。

このスキルは読み取り専用です。リポジトリのファイルを変更してはいけません。分析用の成果物は、リポジトリ外のホストの一時領域にのみ書き込んでください。修正は作者があなたの報告に基づいて実施します。

重大度の基準（共通）

• Critical — データ損失、破損、セキュリティ侵害、またはすべてのユーザーに影響する完全な障害が発生し、回避策がありません。
• High — 正確性、安全性、破られた約束、または誤った動作に関する問題です。発生頻度が低いこと、特殊な前提条件が必要なこと、回避策があることを理由に、実質的な不具合を磨き込みの問題として扱ってはいけません。
• Medium — 注意深いレビュアーならリリース前に修正を求める、明確なプロダクトまたは品質上の欠落です。具体的なコストを明示してください。
• Low — スタイル、命名、構成、その他あらゆる種類の磨き込みや些細な問題です。

確信度や頻度ではなく、結果の重大さに基づいて評価してください。各観点の例にもこの基準を適用し、重大度を引き下げてはいけません。正確性や安全性の失敗、または拘束力のある約束への違反が、根拠に照らして Low として報告されていた場合は、呼び出し元によるフィルタリングの前に再評価してください。拘束力のある要件は、スタイル、命名、構成に関するものでもかまいません。重大度によって、指摘に対応するか、投稿するか、ブロッキングとするかは決まりません。これらは呼び出し元のポリシーであり、Low の定義には含まれません。

呼び出し元のポリシー

受け入れ可否はマニフェストまたは他の呼び出し元が決定します。主張に基づくゲートでは、証拠が、その主張または適用されるソースの義務に対する具体的な違反を裏付けている場合に、指摘はそのゲートを不合格にします。これには、成果物がサポートする用途や想定される保守における、重大な品質コストも含まれます。重大度は結果の重大さを示すものであり、その論拠の代わりにはなりません。基準が欠けていても、要求された成果やソースの義務がなくなるわけではありません。カバレッジの不足も報告してください。根拠のない改善の好みを、新たな義務に変えてはいけません。

明示的に指定された重大度またはカテゴリのポリシーがある場合も、それに従ってください。同じ Low の指摘でも、ある呼び出し元の Low を含むゲートでは不合格になり、別の呼び出し元の Medium 以上を対象とするゲートでは合格することがありますが、重大度は変わりません。Low に対応することを決めても、その重大度を引き上げてはいけません。ゲートが要求されていない場合は、判定を付けずに分類を報告してください。主張または明示的な取り扱い指示から受け入れポリシーを特定できないのに判定を求められた場合は、確認を求めるか、BLOCKED と報告してください。しきい値を独自に設定してはいけません。まとめ方、修正範囲、最終的な指摘の処置は呼び出し元が決めます。呼び出し元による、理由に基づいた却下があっても、評価対象の主張は変わりません。フォローアップでは、新たな証拠によって再検討されない限り、根拠のある処置として扱います。主張そのものが誤りであることを示す証拠は、主張の所有者である呼び出し元に報告し、変更してもらいます。実際の失敗や、必要な証拠の不足は未解決のままです。

報告形式（共通）

# Code Review — <dimension>

**Dimension**: <dimension>
**Acceptance policy**: [caller-supplied, for a requested gate]
**Status**: PASS | FAIL | BLOCKED [requested gates only]
**Files analyzed**: [...]

## Prior findings (follow-ups only)
- [prior finding]: repaired | rejected with support | unresolved — [evidence; new evidence that reopens it, if any]

## Findings
### Finding #1: [title]
- **Location**: `file:line`
- **Severity**: Critical | High | Medium | Low
- **Description**: [what's wrong]
- **Acceptance basis**: [the claim or source obligation contradicted, or the concrete quality cost; identify a proposed improvement as such]
- **Trigger**: [the condition under which the defect manifests — the concrete input, state, or sequence that produces the failure, or for a static mismatch such as a contract or signature divergence, the call or consumer path that reaches it — required on defect-finder dimensions]
- **Impact**: [what it breaks / why it matters — a Medium finding must name the concrete cost that earns that grade: the future change it makes harder, the reader or operator task it defeats, or the condition under which behavior degrades]
- **Recommended fix**: [specific change]

## Pre-existing (only when the caller asked, on a fresh full look)
- [title] — `file:line` — [the issue, with its trigger or cost] — [recommended fix]

## Summary
- Critical: N | High: N | Medium: N | Low: N
- Verdict (requested gates only): apply the caller's acceptance policy to the classified findings.

空の報告も、妥当で想定される結果です。報告を埋めるために指摘をでっち上げてはいけません。

検証者との契約（PASS / FAIL / BLOCKED）

呼び出し元の受け入れポリシーに基づくゲートとして実行する場合は、最後に次のいずれかの判定を付けてください。

• PASS — 証拠が、未解決の矛盾する指摘や重大な不確実性がない状態で、呼び出し元のポリシーに基づく評価対象の主張を裏付けています。
• FAIL — 証拠が、そのポリシーに基づく失敗を立証しています。満たされなかった主張、または明示的に要求されたしきい値を示してください。指摘は呼び出し元が評価するための証拠であり、新たな要件を追加する権限ではありません。
• BLOCKED — 必要な証拠または権限が不足しています（例：変更箇所を特定できない、必要な外部文書にアクセスできない）。未検証の内容と、何があれば確認できるかを示してください。指摘リストが空であることだけでは、主張の裏付けにはなりません。

注意点

• 参照は1つだけです。 要求された観点の参照だけを読み込んでください。複数を読み込むと、段階的開示の効果が損なわれ、各観点が隣接する観点との間に定める直交性の境界が曖昧になります。
• ポリシーを適用する前に分類してください。 Low のラベルを付けても、正確性や安全性の問題、あるいは破られたバインディングの約束が解消されるわけではありません。呼び出し側のポリシーを適用する前に、その影響を確認してください。
• 報告対象となるかは、信頼度ではなく、明示されたトリガーで決まります（欠陥の発見者）。欠陥が顕在化する条件を示してください。「X の場合に必ず失敗する」とし、X を具体的に記述します。欠陥が逐次的ではなく静的な場合、つまり、すべての呼び出しで誤りとなる契約やシグネチャの不一致の場合は、その欠陥に到達する呼び出しまたはコンシューマーの経路がトリガーになります。トリガーを示せない指摘は、どれほど強く疑っていても報告対象にはなりません。「バグかもしれない」「脆弱そうだ」「負荷がかかると壊れる可能性がある」は、いずれもこの基準を満たしません。指摘だけを読む人が、この基準を満たしているかどうか判断できなければなりません。これにより、読む人によって基準が変わるのではなく、レビュー担当者全員で基準を一定に保てます。明示されたトリガーは必要条件であって十分条件ではありません。そのうえで、各観点固有の報告基準（実行可能性のフィルター、または欠陥クラスの場合は受け入れルール）も適用されます。
• Medium は、感情の強さではなく、明示されたコストです（すべての観点）。指摘にはコストを記述してください。変更が難しくなること、タスクが達成できなくなること、または動作が劣化する条件を、指摘だけを読む人がその評価に値する理由を判断できる程度に具体的に示します。「もっときれいにできる」「違和感がある」「理想的ではない」といった点に根拠を置く指摘は、コストを示していないため、Low にとどまります。そのうえで、各観点固有の基準も適用されます。
• 読み込んだ観点の範囲内にとどめてください。 各参照には、その観点が扱う内容と、隣接する観点に属する内容が記載されています。保守性の懸念はバグではなく、型の不備は設計への批評ではありません。読み込んだ観点が扱う内容だけを報告し、残りは他の観点のレビューに委ねてください。