review

レビュー

出力言語： 回答および成果物は、ユーザー自身の言語で記述してください（リポジトリの履歴ではなく、ユーザーのメッセージに合わせます）。

概要

次のタスクに進む前、またはコミットしてプッシュする前に、成果物が合意内容に照らして妥当かを厳しく確認します。レビュー対象は必ずしもコードの差分とは限りません。仕様書（write-spec）、計画書（write-plan）、構造上の決定（solid）も、それぞれ固有の反証方法を用いて個別にレビューします。

基本原則：記憶している意図ではなく、成果物をレビューします。

宣言：「レビューを使って <spec|plan|solid|code> をレビューします……」

使用するタイミング

• 各計画タスクの後（write-planを実行する場合）
• 大規模な機能の作業単位の後
• PR/MR を開く前、または更新する前
• 仕様書／計画書／構造上の決定が完成し、後続の作業がそれに依存して進む前に厳しく確認したいとき
• 行き詰まったとき（前提を新たな視点で見直します）

使用しないタイミング： 差分が空の場合、ユーザーが明示的にレビューを不要とした場合。

絶対的な原則

1. Critical and Important findings BLOCK progress until fixed or explicitly deferred by the human with reason. The **transition gate** at each skill's Hand-off is where that deferral happens — review surfaces findings, the human decides proceed / fix / adjust at the gate.
2. EVERY review carries a claim→case table — the design-level analog of a test suite. No claim→case table, no LGTM.
3. EVERY review checks the artifact against its DIRECT upstream (child must faithfully narrow the parent).
4. NEVER claim "LGTM" without reading the actual artifact (diff, tests, spec text, plan tasks, boundary decisions).
5. Findings are written in the user's conversational language, plain words, no metaphor-for-decoration; each finding says the scene, what someone hits, and where in the artifact.

振り分け

レビュー対象を特定し、該当する参照資料を開いて、そのルーブリックだけを適用します。

レビュー対象	タイミング	参照資料	主張→ケースの表の作成元
code	差分／実装の作業単位	references/code.md	差分内の主張（動作とテストへの期待）
spec	設計／仕様書（write-spec の出力）	references/spec.md	仕様書内の主張（シナリオ、In/Out、メカニズム、受け入れ条件）
plan	実装計画書（write-plan の出力）	references/plan.md	計画書内の主張（タスクごとのテスト可能性、追跡可能性）
solid	構造／境界に関する決定	references/solid.md	構造上の主張（ユニットの目的、依存の矢印、見せかけがないこと）

複合的な対象（例：仕様書とその最初の実装を同時に含む PR）の場合は、各対象の参照資料を適用します。対象ごとに主張→ケースの表を1つずつ作成し、レポートは1つにまとめます。

ワークフロー

1. コンテキストを収集する（セッションの雰囲気ではなく、具体的な情報を使います）。
   • 対象の種類を特定し、該当する参照資料を開きます
   • 成果物そのものと、その直接の上流成果物（計画書のレビューでは仕様書、コードのレビューでは計画書、仕様書のレビューではグリルでの決定事項、構造上の決定のレビューでは仕様書に記載された境界）
   • コードの場合：git diff ／ BASE...HEAD
2. 参照資料のルーブリックを適用する — 主張→ケースの表は必須の出力です（下記参照）。可能であれば、新たなサブエージェント／レビュアーを使用します。そうでない場合は、同じルーブリックを使って自己レビューします。
3. 重要度別に報告する： Critical／Important／Minor — 各指摘を、状況 → 発生する問題 → 成果物内の該当箇所、の3要素を含む平易な言葉で記述します。
4. 対応する： Critical と Important は修正し、Minor は記録します。誤った指摘には、根拠を示して異議を申し立てます。
5. 再検証する — 修正が入った場合は、該当する主張→ケースの表の部分を再実行します。コードの場合はテストを再実行します（debug の検証ゲート／tdd）。
6. 引き継ぐ： 提出時は commit-and-push に引き継ぎます。

claim→case テーブル（必須）

反証されていない主張は、レビューされていません。 テストスイートと同様に、claim→case テーブルでは、成果物に含まれる反証可能な主張をそれぞれ行にし、シナリオを適用して判定を割り当てます。

各行について：

• 主張： 成果物に含まれる反証可能な主張を1つ記載します（仕様の受け入れ項目、プランのタスクにある「テストで Z を検証する」、確固たる「ドメインは IO に依存しない」、コードの動作など）。
• 適用するシナリオ（最低2つ。意外に感じなくなるまで追加します）：
  • 正常系
  • 少なくとも1つの境界条件（空、ゼロ、最大値、範囲をわずかに超える値、最初／最後の要素、期限、クォータなど）
  • 少なくとも1つの極端なケース（負荷100倍、上流の欠落、権限拒否、ネットワーク切断、入力破損、怒っているユーザー、日付変更時のロールオーバーなど）
  • 実例があれば、実際のケース（過去のインシデント、ユーザーからの苦情、すでに発生したリグレッション）。実際のケースをそのまま適用します。成果物はこれに耐えなければなりません。
• 判定： PASS / WATCH / BLOCK。
  • PASS — 適用したシナリオでも成立します。
  • WATCH — 正常系では成立しますが、境界条件／極端なケース／実際のケースに対応していない、記述されていない、または曖昧です。
  • BLOCK — シナリオが成果物と直接矛盾します（スコープが暗黙に追加されている、タスクを追跡できない、境界条件の担当者がいない、受け入れ条件をデモできない）。

出力形式 — すべてのレポートに含める固定セクション：

### claim→case table
| Claim | Scenarios injected | Verdict |
|-------|--------------------|---------|
| …     | happy; boundary; extreme; real case   | PASS/WATCH/BLOCK |

小規模な成果物ではテーブル全体を記載します。大規模な成果物では、すべての WATCH / BLOCK 行を記載し、「残りの行を確認済み。異常なし」の1行を追加します。明示的な確認メモなしに行を省略してはいけません。

実際のケースの適用： 実際のケースがある場合（インシデントのテキスト、失敗する再現手順、ユーザーの正確な発言がある場合）は、考案したシナリオより優先します。まず、そのケースで成果物を検証しなければなりません。

レポート形式

## Review
**Object:** spec | plan | solid | code (BASE...HEAD or paths)
**Upstream checked:** <path or "none — WATCH noted">
**Verdict:** proceed | blocked

### Strengths
- …

### Critical
- …

### Important
- …

### Minor
- …

### claim→case table
| Claim | Scenarios injected | Verdict |
|-------|--------------------|---------|

合理化テーブル

言い訳	実態
「小さな変更だから」	小さな変更でも本番環境に障害を起こします。それでもルーブリックを実行してください。
「テストが通った＝問題なし」	テストは見せかけの場合があります。claim→case テーブルが主張を網羅しているか確認してください。
「ただのプラン／仕様だから、テストするものはない」	プラン／仕様にも反証可能な主張があります。そのために claim→case テーブルがあります。
「ユーザーは技術に詳しいから、平易な言葉は不要」	指摘事項は、その場にいなかった次の担当者が読んでも理解できなければなりません。平易な言葉はその人のためにあります。
「あとで PR の UI からレビューする」	今見つけましょう。あとに回すほど問題は膨らみます。
「レビュアーは間違っているから無視する」	根拠を示して異議を唱えてください。Critical を黙殺してはいけません。

危険信号

• 成果物を開かずに出荷する（差分、仕様テキスト、プランのタスク、境界条件の決定）
• claim→case テーブルの PASS を示さずに「LGTM」とする
• Critical / Important が未解決のまま進める
• 対象の成果物だけをレビューし、直接の上流を確認しない
• 専門用語だけで指摘事項を書き、具体的な状況や「誰が影響を受けるのか」を示さない

チェックリスト

• 対象を特定し、対応する参照資料を開いた
• 成果物と直接の上流資料を確認した（上流資料がない場合 → WATCH の指摘事項）
• claim→case テーブルを記入し、すべての主張を反証または確認済みにした
• 指摘事項を平易な言葉で3つの要素（状況 → 影響を受ける人が直面すること → 場所）に沿って記載した。飾りの比喩は使わない
• 重要度を割り当て、ブロッカーを修正するか、人間が免除した
• 修正を反映した場合、検証を再実行した
• 出荷時にコミットしてプッシュできる状態にした

引き継ぎ

移行ゲート — レビューレポートが完成したら、出荷前にユーザーに確認します（AskUserQuestion を1回実行し、未解決のブロッカーがあるレポートを自動で出荷してはいけません）。

A) Recommended: Proceed → commit-and-push (clean, or Critical/Important fixed or waived with reason)
B) Fix open Critical/Important first — back to debug / tdd, then return to this gate
C) Adjust — re-review a narrower object / different slice, then return to this gate
D) Something else (I will type it)

• コードに関する指摘 → debug / tdd
• 構造上の問題 → solid
• 仕様／プランにおけるプロダクトの曖昧さを再検討 → grill
• 出荷 → commit-and-push