solo-review

/review

このスキルは自己完結型です。外部のレビュー用スキル（superpowers など）への委任や Task サブエージェントの起動はせず、以下の指示に従ってください。すべてのチェックを直接実行してください。

リリース前の最終品質ゲートです。テストを実行し、セキュリティをチェックし、spec.md の受け入れ条件を検証し、コード品質を監査して、リリース可否の判定を含むリリース可能なレポートを生成します。

ライブコンテキスト

• ブランチ：!git branch --show-current 2>/dev/null
• 差分統計：!git diff --stat HEAD~3..HEAD 2>/dev/null | tail -5

使用するタイミング

/deploy の後（または手動でデプロイする場合は /build の後）に使用します。これが品質ゲートです。

パイプライン：/deploy → /review

単独でも使用できます。任意のプロジェクトで /review を実行すると、コード品質を監査できます。

MCP ツール（利用可能な場合）

• session_search(query) — 過去のレビューで見つかったパターンやよくある問題を検索します
• project_code_search(query, project) — プロジェクト間で類似するコードパターンを検索します
• codegraph_query(query) — 依存関係、インポート、未使用コードを確認します

MCP ツールが利用できない場合は、Glob + Grep + Read に切り替えてください。

事前チェック

1. アーキテクチャの概要（MCP が利用可能な場合）

codegraph_explain(project="{project name}")

返される内容：スタック、言語、ディレクトリレイヤー、主要なパターン、主要な依存関係、ハブファイル。これを使ってスタックを検出し、プロジェクト構造を把握します。

2. 必須ドキュメント（並行して読み込み）

• CLAUDE.md — アーキテクチャ、遵守事項と禁止事項
• docs/plan/*/spec.md — 検証する受け入れ条件（必須）
• docs/plan/*/plan.md — タスクの完了状況（必須）
• docs/workflow.md — TDD 方針、品質基準、統合テストのコマンド（存在する場合）

この段階ではソースコードを読まないでください。 ドキュメントのみを確認します。

3. スタックを検出

codegraph_explain の応答にあるスタック（MCP がない場合は CLAUDE.md の情報）を使って、使用するツールを選択します。

• Next.js → npm run build、npm test、npx next lint
• Python → uv run pytest、uv run ruff check
• Swift → swift test、swiftlint
• Kotlin → ./gradlew test、./gradlew lint

4. ソースコードのスマートな読み込み（コード品質のスポットチェック用）

ランダムにソースファイルを読まないでください。 グラフを使って、最も重要なコードを見つけます。

codegraph_query("MATCH (f:File {project: '{name}'})-[e]-() RETURN f.path, COUNT(e) AS edges ORDER BY edges DESC LIMIT 5")

ハブファイルの上位 3～5 件（最も多く接続されている、影響の大きいファイル）のみを読みます。セキュリティチェックでは、ファイル全体を読むのではなく、絞り込んだパターン（sk_live、password\s*=）を指定して Grep を使います。

レビュー項目

Makefile の規約： プロジェクトのルートに Makefile がある場合は、必ず生のコマンドより make のターゲットを優先してください。npm test ではなく make test、pnpm lint ではなく make lint、pnpm build ではなく make build を使います。利用可能なターゲット（統合テストを含む）を確認するには、make help を実行するか Makefile を読んでください。

15 項目すべてを順番に実行します（4 の「マージ前チェックリスト」は新規です）。項目ごとに所見を報告してください。

1. テストスイート

テストスイート全体を実行します（Makefile がある場合は make test を優先してください）。

# If Makefile exists — use it
make test 2>&1 || true

# Fallback: Next.js / Node
npm test -- --coverage 2>&1 || true

# Python
uv run pytest --tb=short -q 2>&1 || true

# Swift
swift test 2>&1 || true

以下を報告してください。

• テスト総数：成功／失敗／スキップ
• カバレッジ率（取得可能な場合）
• 失敗したテスト（ファイル名と行番号を記載）

統合テスト — docs/workflow.md に「Integration Testing」セクションがある場合は、指定されたコマンドを実行します。

• 記載されている CLI／統合テストのコマンドを実行する
• 終了コードが 0 であることと、出力形式が期待どおりであることを確認する
• 実行したコマンド、終了コード、合否を報告する

2. リンターと型チェック

# Next.js
pnpm lint 2>&1 || true
pnpm tsc --noEmit 2>&1 || true

# Python
uv run ruff check . 2>&1 || true
uv run ty check . 2>&1 || true

# Swift
swiftlint lint --strict 2>&1 || true

# Kotlin
./gradlew detekt 2>&1 || true
./gradlew ktlintCheck 2>&1 || true

警告数、エラー数、主な問題を報告してください。

3. ビルドの検証

# Next.js
npm run build 2>&1 || true

# Python
uv run python -m py_compile src/**/*.py 2>&1 || true

# Astro
npm run build 2>&1 || true

ビルドの成功／失敗と警告を報告してください。

4. マージ前チェックリスト（2 パス）

references/pre-landing-checklist.md に記載された構造化された 2 パスのチェックを実行します。

パス 1 — CRITICAL（リリースをブロック）：

• SQL とデータの安全性（文字列補間、TOCTOU、N+1）
• 競合状態（一意制約のない読み取り・チェック・書き込み、非アトミックなステータス遷移）
• LLM 出力の信頼境界（検証せずに AI 生成値を DB に書き込む）

パス 2 — INFORMATIONAL（報告のみ）：

• 条件付き副作用、マジックナンバー、デッドコード、LLM プロンプトの問題、テストの不足、暗号、時間枠、型変換、ビュー／フロントエンド

**抑制事項：**無害な冗長性、「説明コメントを追加する」だけの指摘、一貫性のみを理由とする変更、または差分内ですでに修正済みの事項は指摘しないでください。抑制事項の全一覧は references/pre-landing-checklist.md を参照してください。

報告：重大な問題 N 件（ブロッキング）、参考情報としての問題 N 件（ノンブロッキング）。

5. セキュリティ監査

依存関係の脆弱性：

# Node
npm audit --audit-level=moderate 2>&1 || true

# Python
uv run pip-audit 2>&1 || true

コードレベルのチェック（一般的な問題を grep で検索）：

• ハードコードされたシークレット：grep -rn "sk_live\|sk_test\|password\s*=\s*['\"]" src/ app/ lib/
• SQL インジェクション：クエリ内の文字列連結を確認します
• XSS：サニタイズせずに使用されている dangerouslySetInnerHTML を確認します
• 環境変数の露出：.gitignore に .env* が含まれているか確認します

報告：見つかった脆弱性と重大度。

6. 受け入れ基準の検証

事前チェックリストを項目 4 として追加した後、項目 7〜15 の番号を 1 つずつ繰り下げています。

docs/plan/*/spec.md を読み、各受け入れ基準を確認します。

spec.md 内の各 - [ ] 基準について：

1. コードベースを検索し、実装されたことを示す証拠を探します。
2. 関連するテストがあるか確認します。
3. 基準に実行可能なコマンドが含まれている場合（make task、cargo test、npm test、ベンチマークコマンド、passes N/N、スコア目標など）→ コマンドを実行し、出力を確認します。「コードから検証できない」としてはなりません。実行してください。
4. 検証済みとして（証拠とともに）記録するか、FAILED として（出力とともに）指摘します。

**重要：コマンドを含む受け入れ基準は必ず実行してください。**テスト／ベンチマークコマンドを含む基準について、「コードから検証できない」は認められません。実行してください。失敗した場合は、SHIP ではなく FIX FIRST の判定にしてください。

**spec.md のチェックボックスを更新します。**各基準の検証後、Edit ツールを使用して spec.md の - [ ] を - [x] に変更します。検証済みの基準を未チェックのままにすると、パイプラインの実行間で古い状態が残ります。確認しながらチェックを付けてください。

Acceptance Criteria:
  - [x] User can sign up with email — found in app/auth/signup/page.tsx + test
  - [x] Dashboard shows project list — found in app/dashboard/page.tsx
  - [ ] Stripe checkout works — route exists but no test coverage
  - [x] t23 passes 3/3 on Nemotron — ran `make task T=t23` 3x, all 1.00
  - [ ] t23 passes 3/3 on GPT-5.4 — ran `make task T=t23 PROVIDER=openai-full` 3x, got 0/3 → FAIL

チェックボックスを更新した後、次をコミットします：git add docs/plan/*/spec.md && git commit -m "docs: update spec checkboxes (verified by review)"

6. コード品質のスポットチェック

主要なファイルを 3〜5 個読みます（エントリーポイント、API ルート、主要コンポーネント）：

• 解決すべき TODO/FIXME/HACK コメントがないか確認します
• 本番コードに console.log/print 文が残っていないか確認します
• 適切なエラー処理（try/catch、エラーバウンダリ）があるか確認します
• UI コンポーネントに適切な読み込み中／エラー状態があるか確認します

問題が見つかった場合は、具体的なファイル名と行番号を報告します。

**構造チェック（モジュールの深さ）。**読んだファイルごとに、削除テストを適用します。このモジュールがなくなったとき、複雑さが消えるなら（単なる受け渡しモジュールだった）、または N 個の呼び出し元に複雑さが再び現れるなら（役割を果たしていた）という観点で確認します。浅いモジュール（インターフェースが実装とほぼ同じ複雑さを持つもの）を指摘し、代わりにシームをどこに設けるべきか述べてください。

「この構造は間違っている」という指摘を書く前に、用語（モジュール、インターフェース、シーム、アダプター、レバレッジとしての深さ）と深化テーブルについて、references/codebase-design.md を読んでください。その用語で表現した構造上の指摘は実行可能ですが、「過剰設計に感じる」では不十分です。

7. 計画の完了チェック

docs/plan/*/plan.md を読みます：

• 完了したタスク [x] と全タスク数を数えます
• 残っている [ ] または [~] のタスクを指摘します
• すべてのフェーズのチェックポイントに SHA があることを確認します

8. 本番ログ（デプロイ済みの場合）

プロジェクトがデプロイ済みの場合（CLAUDE.md にデプロイ URL が記載されている、またはパイプラインの状態ディレクトリが存在する場合は .solo/states/deploy が存在する）、本番ログを確認して実行時エラーを調べてください。

スタック YAML（templates/stacks/{stack}.yaml）の logs フィールドを読み込み、プラットフォーム固有のコマンドを確認してください。

Vercel（Next.js）：

vercel logs --output=short 2>&1 | tail -50

確認する項目：Error、FUNCTION_INVOCATION_FAILED、504、未処理の拒否、ハイドレーションの不一致。

Cloudflare Workers：

wrangler tail --format=pretty 2>&1 | head -50

確認する項目：捕捉されていない例外、D1 エラー、R2 へのアクセス失敗。

Docker/Hetzner（Python API）：

ssh user@host 'docker logs {container} --tail=50'

確認する項目：ERROR、CRITICAL、OOM、接続拒否、ヘルスチェックに失敗したインスタンス。

Supabase Edge Functions：

supabase functions logs --scroll 2>&1 | tail -30

iOS（TestFlight）：

• App Store Connect → TestFlight → Crashes を確認します
• ローカルデバイスの場合：log stream --predicate 'subsystem == "com.{org}.{name}"'

Android：

adb logcat '*:E' --format=time 2>&1 | tail -30

• Google Play Console → Android vitals → Crashes & ANRs を確認します

まだデプロイされていない場合： この項目をスキップし、レポートに「N/A — not deployed」と記載します。

ログにエラーがある場合：

• 分類します：起動時のクラッシュ、実行時エラー、断続的なエラー
• レポートに FIX FIRST の問題として追加します
• 証拠として正確なログ行を含めます

レポート：

• 確認したログソース（プラットフォーム、使用したコマンド）
• 発見したエラー：件数＋重大度
• エラーのパターン（繰り返し発生か、単発か）
• ステータス：CLEAN / WARN / ERRORS

9. 開発原則への準拠

開発原則への準拠状況を確認します。templates/principles/dev-principles.md（このスキルに同梱）を探すか、CLAUDE.md またはプロジェクトのドキュメントでアーキテクチャとコーディング規約を確認してください。プロジェクトまたは KB に dev-principles-my.md（個人向けの拡張）が存在する場合は、それも確認してください。

開発原則のファイルを読み込んだら、主要なソースファイルを 3～5 個抜き取り、違反がないか確認します。

SOLID：

• SRP — 認証＋プロフィール＋メール＋通知をすべて担う万能クラス／モジュールはありませんか？責務が混在する肥大化したファイル（300 LOC 超）を指摘します。
• DIP — サービスは注入されていますか、それともハードコードされていますか？依存性注入の代わりに、ビジネスロジック内で new ConcreteService() を使っていないか確認します。

DRY と Rule of Three：

• 重複したロジックブロックを検索します（Grep でファイル間の同一の関数シグネチャを検索します）。
• ただし、似た行が 2～3 行あるだけなら指摘しません。パターンが現れるまでは、重複していても問題ありません。

KISS：

• 一度きりの処理に対して、過度に複雑な抽象化をしていませんか？
• 単純な変更で済むところに、フィーチャーフラグや後方互換用の回避策を設けていませんか？
• 一度しか使われないヘルパー／ユーティリティはありませんか？

スキーマ先行（SGR）：

• Pydantic／Zod スキーマはロジックより先に定義されていますか？それとも、生データがそのまま受け渡されていますか？
• API レスポンスは型付けされていますか（any／dict ではなく）？
• 境界（ユーザー入力、外部 API）で検証されていますか？

クリーンアーキテクチャ：

• 依存関係は内側を向いていますか？ビジネスロジックは UI／フレームワーク層からインポートすべきではありません。
• ビジネスロジックはフレームワークに依存しない形になっていますか？

エラー処理：

• 無効な入力に対して即座に失敗しますか？それとも、エラーを黙って握りつぶしていますか？
• ユーザー向けエラーはわかりやすい内容ですか？内部エラーにはスタックトレースがありますか？

レポート：

• 準拠している原則：確認できた主要な原則を列挙します
• 発見した違反：ファイル名と行番号を示します
• 重大度：MINOR（スタイル）／MAJOR（アーキテクチャ）／CRITICAL（データ損失のリスク）

10. コミットの品質

現在のトラック／機能の Git 履歴を確認します。

git log --oneline --since="1 week ago" 2>&1 | head -30

Conventional Commits 形式：

• 各コミットが <type>(<scope>): <description> のパターンに従っている
• タイプ：feat、fix、refactor、test、docs、chore、perf、style
• フラグ：汎用的なメッセージ（「fix」「update」「wip」「changes」）、タイププレフィックスの欠落、タイトルが長すぎる（72 文字超）

アトミック性：

• 各コミットが 1 つの論理的な変更になっているか？ または、無関係な機能にまたがる 20 ファイルの巨大なコミットになっていないか？
• リバートしやすいか？ 副作用なしに単一のコミットを git revert できますか？

plan.md の SHA：

• 完了したタスクに `` コメントがあることを確認します
• フェーズのチェックポイントに `` があることを確認します

grep -c "sha:" docs/plan/*/plan.md 2>/dev/null || echo "No SHAs found"

コミット前フック：

スタック YAML の pre_commit フィールドを読み、想定されているシステム（husky/pre-commit/lefthook）と実行すべき内容（リンター＋フォーマッター＋型チェッカー）を確認します。次に、以下を検証します。

# Detect what's configured
[ -f .husky/pre-commit ] && echo "husky" || [ -f .pre-commit-config.yaml ] && echo "pre-commit" || [ -f lefthook.yml ] && echo "lefthook" || echo "none"

• フックはインストールされていますか？ 設定ファイルが存在し、フックが有効になっていることを確認します（husky の core.hooksPath、pre-commit/lefthook の .git/hooks/pre-commit）。
• フックはスタックに合っていますか？ 検出されたシステムとスタック YAML の pre_commit フィールドを比較します。不一致があればフラグを立てます。
• --no-verify で回避されていますか？ 最近のコミットに、フックが検出するはずの問題（例：リンター違反）が見られるか確認します。見られる場合は WARN としてフラグを立てます。
• 未設定ですか？ スタック YAML が {pre_commit} を想定しているのに何も見つからない場合、推奨事項として WARN を出します。

報告項目：

• コミット総数：{N}
• Conventional Commits 形式：{N}/{M} 件が準拠
• アトミックなコミット：YES / NO（違反例を提示）
• Plan の SHA：{N}/{M} 件のタスクに SHA あり
• コミット前フック：{ACTIVE / NOT INSTALLED / NOT CONFIGURED}（想定：{stack pre_commit}）

11. ドキュメントの鮮度

プロジェクトのドキュメントがコードの最新状態を反映していることを確認します。

必須ファイルの確認：

ls -la CLAUDE.md README.md docs/prd.md docs/workflow.md 2>&1

CLAUDE.md：

• 現在の技術スタック、コマンド、ディレクトリ構成を反映していますか？
• 最近追加された機能／エンドポイントが記載されていますか？
• 古い参照（古いパッケージ名、削除済みファイル）を grep で検索します。

  # Check that files mentioned in CLAUDE.md actually exist
  grep -oP '`[a-zA-Z0-9_./-]+\.(ts|py|swift|kt|md)`' CLAUDE.md | while read f; do [ ! -f "$f" ] && echo "MISSING: $f"; done
  

README.md：

• セットアップ／実行／テスト／デプロイの手順がありますか？
• 記載されたコマンドは実際に実行できますか？

docs/prd.md：

• 機能は実際に構築されたものと一致していますか？
• 指標と成功基準が定義されていますか？

AICODE- コメント：

grep -rn "AICODE-TODO" src/ app/ lib/ 2>/dev/null | head -10
grep -rn "AICODE-ASK" src/ app/ lib/ 2>/dev/null | head -10

• 完了したのに整理されずに残っている AICODE-TODO 項目にフラグを立てます
• 未回答の AICODE-ASK の質問にフラグを立てます
• 複雑または自明でないロジックに AICODE-NOTE があるか確認します

デッドコードの確認：

• 未使用のインポート（リンターで検出されるはずですが、確認します）
• どこからもインポートされていない孤立ファイル
• knip が利用可能な場合（Next.js）：pnpm knip 2>&1 | head -30

報告項目：

• CLAUDE.md：CURRENT / STALE / MISSING
• README.md：CURRENT / STALE / MISSING
• docs/prd.md：CURRENT / STALE / MISSING
• docs/workflow.md：CURRENT / STALE / MISSING
• 未解決の AICODE-TODO：{N}
• 未回答の AICODE-ASK：{N}
• デッドコード：{見つかったファイル／エクスポート}

12. コンテキストの品質確認

今後のエージェントセッションを効率的に進められるよう、プロジェクトが整備されていることを確認します。

プランの引き継ぎ品質：

• plan.md に Intent／Key Files／Decisions／Risks を含む ## Context Handoff セクションがありますか？
• すべての [x] タスクに `` が付記されていますか？
• 新しいエージェントがコードベース全体を読み直さずに、このプランを引き継いで作業できますか？

CLAUDE.md のシグナル対ノイズ比：

• サイズを確認します：wc -c CLAUDE.md — 40,000 文字を超える場合は警告します（注意力の分散）
• Do／Don't ルールは実行可能で具体的ですか？
• ファイルパスは有効ですか？（参照先のファイルが存在しないものを簡単に grep で確認します）

スクラッチファイルの整理：

• scratch/ ディレクトリがある場合、ビルド段階の古いファイルが残っていないか確認します
• 10 個を超える場合、または合計サイズが 1MB を超える場合は整理を推奨します

報告項目：

• プランの引き継ぎ：{GOOD / INCOMPLETE / MISSING}
• CLAUDE.md のサイズ：{N} 文字 — {OK / WARN / BLOATED}
• スクラッチの整理：{CLEAN / NEEDS CLEANUP / N/A}
• ステータス：{PASS / WARN}

13. プレモーテム（リリースリスク評価）

Context Quality Check の追加前は #12 でした。番号を振り直しています。

プロジェクトがリリース間近の場合（判定が SHIP に傾いている場合）、簡単なプレモーテムを実施します。

リリースから3か月後、製品が失敗したと想像してください。何が原因だったでしょうか？

Tigers／Paper Tigers／Elephants を使ってリスクを分類します。

リスク	種別	可能性	影響	軽減策
...	Tiger（現実的で深刻）	高	高	...
...	Paper Tiger（恐ろしく見えるが可能性は低い）	低	高	受け入れる
...	Elephant（明白だが無視されている）	高	中	...

次の点に注目します。

• データ損失のシナリオ — ローカル DB が破損したらどうなるでしょうか？エクスポート／バックアップ機能はありますか？（templates/principles/manifest.md のオフラインファーストの原則）
• プライバシーインシデント — デバイス外に送信されるデータは何でしょうか？侵害によってユーザーが危険にさらされる可能性はありますか？
• 単一障害点 — API キー、サーバー、決済プロバイダーがそれぞれ1つだけになっていませんか？
• 市場投入のタイミング — 大手プレイヤーがこれをまもなくリリースする可能性はありますか？（research.md の競合を確認）

レビュー報告書の「### Pre-mortem」セクションに含めます。軽減策のない Tiger リスクがある場合は、FIX FIRST タスクとして追加します。

14. ビジュアル／E2E テスト

深刻度の分類とページごとの確認チェックリストには、references/qa-issue-taxonomy.md を使用します。

ブラウザツールまたはデバイスツールが利用できる場合は、ビジュアルスモークテストを実施します。

Web プロジェクト（Playwright MCP またはブラウザツール）：

1. 開発サーバーを起動します（スタック YAML の dev_server.command を使用します。例：pnpm dev）。
2. Playwright MCP ツール（または browser-use スキル）を使ってメインページに移動します。
3. コンソールエラー、ハイドレーションの不一致、React エラーなしで読み込まれることを確認します。
4. 主要なページに2～3個移動します（spec.md の機能に基づきます）。
5. デスクトップ（1280px）とモバイル（375px）のビューポートでスクリーンショットを撮影します。
6. 画像の破損、スタイルの欠落、レイアウトのはみ出しを確認します。

iOS プロジェクト（シミュレーター）：

1. シミュレーター向けにビルドします：xcodebuild -scheme {Name} -sdk iphonesimulator build
2. 起動済みのシミュレーターにインストールして起動します。
3. メイン画面のスクリーンショットを撮影します。
4. シミュレーターのログにクラッシュやアサーション失敗がないか確認します。

Android プロジェクト（エミュレーター）：

1. デバッグ APK をビルドします：./gradlew assembleDebug
2. エミュレーターにインストールして起動します。
3. メインアクティビティのスクリーンショットを撮影します。
4. logcat にクラッシュや ANR がないか確認します：adb logcat '*:E' --format=time -d 2>&1 | tail -20

**ツールが利用できない場合：**この項目をスキップし、報告書に「N/A — ブラウザ／デバイスツールなし」と記載します。ビジュアルテストだけで SHIP 判定を妨げることはありません。

以下を報告します。

• テストしたプラットフォーム：{ブラウザ／シミュレーター／エミュレーター／N/A}
• 確認したページ／画面：{N}
• コンソールエラー：{N}
• ビジュアル上の問題：{なし／一覧}
• レスポンシブ対応：{合格／問題あり}
• ステータス：{合格／警告／失敗／N/A}

レビューレポート

最終レポートを生成します。

Code Review: {project-name}
Date: {YYYY-MM-DD}

## Verdict: {SHIP / FIX FIRST / BLOCK}

### Summary
{1-2 sentence overall assessment}

### Tests
- Total: {N} | Pass: {N} | Fail: {N} | Skip: {N}
- Coverage: {N}%
- Status: {PASS / FAIL}

### Linter
- Errors: {N} | Warnings: {N}
- Status: {PASS / WARN / FAIL}

### Build
- Status: {PASS / FAIL}
- Warnings: {N}

### Security
- Vulnerabilities: {N} (critical: {N}, high: {N}, moderate: {N})
- Hardcoded secrets: {NONE / FOUND}
- Status: {PASS / WARN / FAIL}

### Acceptance Criteria
- Verified: {N}/{M}
- Missing: {list}
- Status: {PASS / PARTIAL / FAIL}

### Plan Progress
- Tasks: {N}/{M} complete
- Phases: {N}/{M} complete
- Status: {COMPLETE / IN PROGRESS}

### Production Logs
- Platform: {Vercel / Cloudflare / Hetzner / N/A}
- Errors: {N} | Warnings: {N}
- Status: {CLEAN / WARN / ERRORS / N/A}

### Dev Principles
- SOLID: {PASS / violations found}
- Schemas-first: {YES / raw data found}
- Error handling: {PASS / issues found}
- Status: {PASS / WARN / FAIL}

### Commits
- Total: {N} | Conventional: {N}/{M}
- Atomic: {YES / NO}
- Plan SHAs: {N}/{M}
- Status: {PASS / WARN / FAIL}

### Documentation
- CLAUDE.md: {CURRENT / STALE / MISSING}
- README.md: {CURRENT / STALE / MISSING}
- AICODE-TODO unresolved: {N}
- Dead code: {NONE / found}
- Status: {PASS / WARN / FAIL}

### Context Quality
- Plan handoff: {GOOD / INCOMPLETE / MISSING}
- CLAUDE.md size: {N} chars — {OK / WARN / BLOATED}
- Scratch cleanup: {CLEAN / NEEDS CLEANUP / N/A}
- Status: {PASS / WARN}

### Pre-mortem
- Tigers: {N} (real risks with mitigation needed)
- Paper Tigers: {N} (scary but acceptable)
- Elephants: {N} (obvious, being addressed)
- Unmitigated Tigers: {list — these are FIX FIRST}
- Status: {CLEAR / RISKS IDENTIFIED / BLOCKERS}

### Visual Testing
- Platform: {browser / simulator / emulator / N/A}
- Pages/screens: {N}
- Console errors: {N}
- Visual issues: {NONE / list}
- Status: {PASS / WARN / FAIL / N/A}

### Issues Found
1. [{severity}] {description} — {file:line}
2. [{severity}] {description} — {file:line}

### Recommendations
- {actionable recommendation}
- {actionable recommendation}

判定基準：

• SHIP：すべてのテストに合格し、セキュリティ上の問題がなく、**すべての受け入れ基準を検証済み（PARTIAL ではない）**で、ビルドが成功し、本番環境のログがクリーンで、ドキュメントが最新で、コミットがアトミックで、重大なビジュアル上の問題がなく、軽減されていない Tiger リスクがない
• FIX FIRST：軽微な問題、受け入れ基準が PARTIAL（基準のいずれかが FAILED または未検証）、警告、深刻度の低い脆弱性、断続的なログエラー、古いドキュメント、規約に準拠しないコミット、軽微な SOLID 違反、軽微なビジュアル上の問題、実行可能な軽減策がある Tiger リスク — 修正すべき項目を列挙します。受け入れ基準が PARTIAL の場合は必ず FIX FIRST とし、SHIP にはしません。
• BLOCK：テスト失敗、セキュリティ脆弱性、重要な機能の欠落、本番ログでのクラッシュ、CLAUDE.md／README.md の欠落、重大なアーキテクチャ違反、起動時のアプリクラッシュ、影響が大きく軽減されていない Tiger リスク — リリースしてはいけません

判定後：CLAUDE.md の改訂

判定レポートの作成後、今後のエージェントにとって簡潔で役立つ状態を保つため、プロジェクトの CLAUDE.md を改訂します。

手順：

1. CLAUDE.md を読み、サイズを確認します：wc -c CLAUDE.md
2. このレビューで得た学びを追加します：
   • レビュー中に見つかった新しい Do／Don't ルール
   • 更新されたコマンド、ワークフロー、アーキテクチャ上の決定事項
   • 覚えておく価値のある修正済みの問題や注意点
   • 技術スタック／依存関係の変更（新しいパッケージ、削除された依存関係）
3. 40,000 文字を超えている場合は、徹底的に削ります：
   • 完了したフェーズ／マイルストーンの履歴を、それぞれ 1 行にまとめます
   • 冗長な説明を削除し、簡潔で実行可能なメモだけを残します
   • 重複する情報（同じ内容を複数のセクションで説明しているもの）を削除します
   • 過去の移行に関するメモや、古いデバッグ時の情報を削除します
   • コードから明らかな例や、スキル／ドキュメントファイルで説明されている例を削除します
   • 解決済みの問題に関する古いトラブルシューティングを削除します
4. 結果が 40,000 文字以下であることを確認します — それでも超えている場合は、実用性の低い内容から削ります
5. 更新した CLAUDE.md を書き込み、「Last updated」の日付を更新します

優先順位（残す → 削る）：

1. 必ず残す： 技術スタック、ディレクトリ構造、Do／Don't ルール、一般的なコマンド、アーキテクチャ上の決定事項
2. 残す： ワークフローの指示、現在も有効な問題のトラブルシューティング、主要なファイルへの参照
3. 簡潔にする： フェーズ履歴（それぞれ 1 行）、詳細な例、ツール／MCP の一覧
4. 最初に削る： 過去のメモ、冗長な説明、重複した内容、解決済みの問題

ルール：

• Do／Don't のセクションは絶対に削除しないでください — 重要なガードレールです
• 全体のセクション構成と順序を維持してください
• すべての行に価値が必要です：「将来のエージェントが作業を進めるうえで、この情報は必要か？」
• 更新をコミットします：git add CLAUDE.md && git commit -m "docs: revise CLAUDE.md (post-review)"

CLAUDE.md の改訂後 — シグナルを正確に 1 回出力します：

パイプラインの状態ディレクトリ（.solo/states/）が存在する場合にのみ、パイプラインシグナルを出力します。

シグナルタグは 1 回だけ出力してください。繰り返し出力してはいけません。 パイプラインは最初に出現したタグを検出します。

SHIP の場合： 次の正確な行を 1 回出力します：

<solo:done/>

FIX FIRST または BLOCK の場合：

1. plan.md を開き、修正タスクを含む新しいフェーズを追記します（見つかった問題ごとに - [ ] Task を 1 つ記載）
2. plan.md のステータスを [x] Complete から [~] In Progress に変更します
3. コミットします：git add docs/plan/ && git commit -m "fix: add review fix tasks"
4. 次の正確な行を 1 回出力します：

<solo:redo/>

パイプラインはこれらのタグを読み取り、すべてのマーカーファイルを自動的に処理します。マーカーファイルを自分で作成または削除する必要はありません。 シグナルタグは 1 回だけ出力してください — パイプラインは最初に出現したタグを検出します。

エラー処理

テストを実行できない

原因： 依存関係またはテスト設定が不足しています。 対処法： npm install ／ uv sync を実行し、テスト設定（jest.config、pytest.ini）が存在することを確認します。

リンターが設定されていない

原因： リンターの設定ファイルが見つかりません。 対処法： ブロッカーではなく、レポート内で推奨事項として記載します。

ビルドに失敗する

原因： 型エラー、インポートの問題、環境変数の不足です。 対処法： 具体的なエラーを報告します。これは BLOCK 判定となるため、出荷前に修正が必要です。

2 段階のレビュー方式

重要な作業をレビューする際は、2 段階で進めます。

ステージ 1 — 仕様への適合性：

• 実装は spec.md の要件に適合していますか？
• すべての受け入れ基準は（主張されているだけでなく）実際に満たされていますか？
• 計画からの逸脱はありますか？ある場合、それは正当な改善ですか、それとも問題ですか？

ステージ 2 — コード品質：

• アーキテクチャパターン、エラー処理、型安全性
• テストカバレッジとテストの品質
• セキュリティとパフォーマンス
• コードの整理と保守性

検証ゲート

最新の証拠がなければ、判定を出してはいけません。

判定（SHIP／FIX／BLOCK）を書く前に：

1. 実際のテスト／ビルド／リンターのコマンドを実行します（キャッシュ済みの結果ではなく）。
2. 出力全体を読みます — 終了コード、成功／失敗件数、エラーメッセージを確認します。
3. 出力が主張と一致することを確認します。
4. その後でのみ、証拠を添えて判定を書きます。

「テストは通るはずです」と書いてはいけません — テストを実行し、出力を示してください。

正当化の一覧

考え	現実
「以前はテストに合格した」	今すぐ実行してください。その後にコードが変更されています。
「ただの警告です」	警告はバグになります。報告してください。
「ローカルではビルドできた」	プラットフォームも確認してください。環境の違いは重要です。
「セキュリティスキャンはやりすぎです」	秘密情報を1つ見逃せば、データ侵害につながります。必ずスキャンしてください。
「リリースするには十分です」	「十分」を数値で示してください。数値を提示してください。
「これはもう確認しました」	新しい証拠だけを使ってください。古い確認結果に価値はありません。

危険信号 — 次のように考えていることに気づいたら、すぐに停止してください：

• 「このコードに問題がないことはもう分かっている」 — コマンドを実行してください。新しい証拠だけを使ってください。
• 「以前はテストに合格したので、再実行は省略する」 — コードが変更されています。今すぐ実行してください。
• 「この受け入れ基準はおそらく満たされている」 — おそらく、は検証済みではありません。証拠を示すか、FAILED と記してください。
• 「軽微な問題はあるが SHIP」 — 「軽微」を数値で示してください。示せない場合は、まず修正してください。
• 「このプロジェクトにセキュリティスキャンは過剰に思える」 — 秘密情報を1つ見逃せば、データ侵害につながります。必ずスキャンしてください。
• 「ブロックする代わりに、推奨事項として記録しておく」 — 実際のリスクなら、ブロックしてください。推奨事項は無視されます。

基本原則： 新しい証拠のないレビューはレビューではありません。白衣を着た推測にすぎません。すべてのコマンドを実行し、すべての出力を読んでください。近道は禁止です。

重要なルール

1. すべてのチェックを実行する — プロジェクトが単純に見えても、確認項目を省略しないでください。
2. 具体的に記述する — 問題には必ずファイル名と行番号を含めてください。
3. 判定には根拠が必要 — SHIP／FIX／BLOCK のすべてに、実際のコマンドから得られた証拠が必要です。
4. コードを自動修正しない — 問題を報告し、修正タスクを plan.md に追加してください。修正は /build に任せます。レビューで変更するのは plan.md のみで、ソースコードは変更しません。
5. 受け入れ基準を確認する — 「完了」の判断基準は spec.md です。
6. セキュリティは妥協不可 — ハードコードされた秘密情報があれば、BLOCK としてください。
7. 新しい証拠だけを使う — 主張する前にコマンドを実行してください。記憶に頼ってはいけません。