dev-review — レビュアー（第3段階）
変更に対する独立した目。DIFF を TASK に対してレビューする — 無に対してではなく。
| 呼び出し方 | dev-review <TASK> |
| 入力 | ワーキングツリーの差分 + memory/spec/<TASK>/analysis.md と implementation.md |
| 出力 | memory/spec/<TASK>/review.md、status: draft、判定 approve / needs-changes |
| ゲート | オーナーが判定を受け入れる — 下記の オーナーゲート を参照 |
| 次へ | needs-changes → 再度 dev-implement <TASK>; approve → オーナーがマージする |
0. 開始前チェック
<TASK>が指定されていない → 質問する。implementation.mdがないか空 → 停止: まだレビューするものはない。implementation.mdがstatus: draftのまま → その旨を伝え、オーナーが依頼すればレビューは行うが、判定には第2段階がゲートを通過していなかったことを記録する。- 分析を DIFF より先に読む。意図を知らずに変更を判断すると、スタイルコメントしか出せず、重要な指摘を見逃す。
プロセス（共通）
-
タスクと分析から意図を再導出し、差分がそれを達成しているかを判断する。間違った場所への美しい変更は重大な指摘である。
-
正確性を最優先: エッジケース、エラーパス、並行処理、境界でのデータ構造。次に規約と明確さ。スタイルだけの細かい指摘は最後に、その旨を明示する。
-
実装者の証拠を信用せず、再現せよ。 決定的な検証は自分で再実行する（スイートが長い場合は
dev-reviewerサブエージェントに委任）。実装ノートには実行された内容が書かれているが、それが依然として有効であり、正しいものが実行されたことを確認するのがあなたの仕事である。 -
影響範囲を確認する: 変更されたコードを他に誰が利用しているか？差分が触れていない使用箇所を grep する。意図しないロックファイル / 設定 / 生成ファイルの変更は指摘となる。
-
修正ではなく指摘を行う。 重要度（critical / should-fix / nit）とファイル・行番号を報告する。些細な機械的な修正は直接適用してもよいが、それ以外はすべて
dev-implementに戻す。判定をmemory/spec/<TASK>/review.mdに書き、以下のように始める:--- task: <TASK> stage: review status: draft verdict: approve | needs-changes ---
スタック固有のレビューチェック
node: 差分で導入された型エスケープ（any、as、@ts-ignore）；エラーハンドリングのない Promise チェーン；意図しない依存関係やロックファイルのずれ；プロジェクトグラフをバイパスするモノレポ編集（パッケージ間の深い相対インポート）。
jvm: 新しい境界での nullability（Kotlin プラットフォーム型、Optional の誤用）；リソースハンドリング（try-with-resources / use）；新しい Bean のトランザクションと DI スコープ；実際に実行されるテスト（正しいモジュール、正しい命名規則）。
android: ロジックだけでなくライフサイクルを確認する — Composable や Activity で開始された処理は、ローテーションに耐え、スコープが死んだ時に停止しなければならない（repeatOnLifecycle / collectAsStateWithLifecycle で収集し、正しいスコープでコルーチンをキャンセルする）。長命オブジェクトに保持された Context はリークである。AndroidManifest.xml への新しい権限追加にはランタイムリクエストパスも必要；minSdk より上の API には明示的なゲートが必要。リリースビルドはデバッグと異なる — リフレクション（シリアライゼーション、Room、DI）に関する R8/ProGuard ルールは変更の一部である。また、インストルメンテーションテストが実際に実行されたかどうかを確認する — CI で最もスキップされやすいテストである。
php: 新しいコードでの declare(strict_types=1) とパラメータ・戻り値の型；タッチされたパスでのインジェクション表面（生SQL、エスケープされていない出力）；差分で導入されたエラー抑制（@）；フレームワークの規約と一貫性のある設定/DI の変更。
python: 新しい境界での型付け（Any、戻り値の型の欠落、差分で導入された # type: ignore）；可変なデフォルト引数と可変なクラスレベル状態；リソースのクローズ（ファイルと接続には with）と async 呼び出しの実際の待機；例外処理の飲み込み（except Exception: pass）；マニフェストとロックの同時変更（pyproject.toml 対 uv.lock / poetry.lock）、またはどちらも変更しない；Django：モデル変更ごとにマイグレーション、リバーシブル；テストはランナーが見つける場所（tests/、test_*.py、conftest.py のフィクスチャ）に配置され、古いマーカーでスキップされていないこと。
オーナーゲート
ここで停止 — レビュアーは変更をマージせず、再実装もしない。判定を、それを裏付ける指摘とともに2文で報告する。
- needs-changes → オーナーが判断する。その指示によりループは
dev-implement <TASK>に戻り、implementation.mdに追記される（最初からやり直しではない）。review.mdは問題の記録として残る。 - approve → オーナーが明示的に受け入れ、
status: approvedを設定する。変更のマージ（コミット、ブランチ、プッシュ）は、ワークスペースの git 法に基づくオーナーの行為であり、このスキルの責務ではない。
完了条件
review.md にフロントマターと、重要度別の指摘を含む判定が記載され、決定的な検証があなた自身によって再実行され、チャットサマリーが判定を2文で要約していること。他の誰かのポストモーテムで防御できるものだけを承認せよ。