review-work

作業のレビュー

計画ドキュメントとコードベースのみを使用して、実装結果を独立して検証します。実行プロセスから情報を受け取ることはありません。

基本原則

レビュー担当者は実行担当者とメモリを共有しません。判断の根拠となるのは、計画に記載された目標と現在のコードベースの状態、この2つのみです。

厳格なゲート

1. 実行コンテキストを受け取らないでください。 run-plan のログ、ワーカーの出力、差分、タスク完了の要約、会話履歴は受け取りません。入力は計画ファイルのパスのみです。
2. 計画ドキュメントを直接読みます。 要約や転送された説明ではなく、ディスク上の計画ファイルを読みます。
3. すべてのテストを自分で実行します。 以前の実行結果を信用しないでください。テストスイート全体と、計画に指定されたすべての検証コマンドを実行します。
4. 判定は PASS または FAIL の二択で、すべてのレベルで適用します。 各成功基準と各タスクの受け入れ基準を個別に達成／未達成で判定し、それらすべての AND を最終判定とします。条件付きの合格、「ほぼ完了」、部分点はありません。
5. 判定は目標の契約のみを評価します。 判定の入力は、計画対象のファイルが存在すること、受け入れ基準を満たしていること、テストに合格すること、リグレッションがないこと、計画の成功基準を満たしていることです。それ以外のすべて（プレースホルダー／デバッグコード、コミットメッセージの不一致、スタイルなど）は参考情報として報告し、判定を左右しません。二択のシグナルは、見た目の問題に左右されない場合にのみ有用です。
6. レビュー文書をファイルに保存します。 レビュー結果は構造化されたドキュメントとして保存してください。口頭での報告だけで終えてはいけません。
7. コードを変更しないでください。 このスキルは読み取り専用です。問題が見つかった場合は報告し、修正はしないでください。

使用する場合

• run-plan の実行完了後
• ユーザーが「作業をレビューして」「実装を検証して」「計画どおりに実装されたか確認して」と依頼した場合
• 実装は完了しているが、独立した検証が必要な場合

使用しない場合

• run-plan がまだ実行中の場合
• 計画ドキュメントが存在しない場合（まず plan-crafting を使用してください）
• 目的が一般的なコードレビューの場合（このスキルは「計画に対する実装」を検証します）

入力

このスキルへの入力は計画ファイルのパスのみです。

docs/engineering-discipline/plans/YYYY-MM-DD-<feature-name>.md

以下を入力として渡してはいけません。

• run-plan の実行ログやタスク完了の要約
• ワーカーのサブエージェントからの出力や差分
• バリデーターのサブエージェントからの検証結果
• 実行セッションの会話履歴

プロセス

フェーズ 1：計画ドキュメントの読み込みと分析

1. 入力として計画ファイルのパスを受け取ります
2. ディスクから計画ドキュメントを直接読みます
3. 以下を抽出します。
   • 目標： この計画で実装する内容
   • 作業範囲： 対象範囲／対象外
   • タスクリスト： 各タスクの名前、受け入れ基準、対象ファイル
   • ファイル構成の対応： 作成または変更するファイルの完全な一覧
   • コミット構成： 計画で指定されたコミットメッセージと範囲
   • テストコマンド： 計画で指定されたすべてのテスト実行コマンド

計画に ## Plan Amendment Log（計画の不備が実行中に見つかった際に run-plan が追記するもの）が含まれている場合、レビューでは修正後の計画を基準とします。このログは実行コンテキストではなく、計画の一部です。計画の目標と比べて基準を弱める修正は、それ自体が FAIL の指摘事項です。

抽出した内容をレビュー文書の基礎として使用します。

フェーズ 2：コードベースの検査

計画で指定されたファイルに照らして、コードベースを検査します。

1. ファイルの存在確認： 計画で指定されたすべてのファイルが実際に存在することを確認します
2. 内容の整合性確認： 各ファイルの内容が計画の要件（関数シグネチャ、型定義、ロジックなど）に合致しているかを検査します
3. 残存アーティファクトの確認（参考情報 — 判定への入力ではありません）：
   • プレースホルダーコード（TODO、FIXME、「後で実装」、スタブ関数）
   • デバッグコード（console.log、print によるデバッグ、コメントアウトされたコードブロック）
   • 計画の範囲外にある予期しない変更 これらは参考情報として記録します。例外：受け入れ基準で動作するコードが求められている箇所にプレースホルダーがある場合、その基準は不合格です。判定を変えるのはアーティファクトではなく、基準そのものです。
4. タスクごとに受け入れ基準を確認します。 計画に記載された各基準をひとつずつ確認し、達成／未達成を記録します。各基準の判定は二択で、部分点はありません。

フェーズ 3：テストの実行

1. 計画で指定された個別のテストコマンドをすべて実行します
2. 回帰がないことを確認するため、テストスイート全体を実行します
3. 各テストの結果（PASS／FAIL）を記録します
4. テストが失敗した場合は、エラーメッセージを記録します

フェーズ 4：Git 履歴の確認（参考情報）

1. 計画に記載されたコミット構成と、実際の git log を比較します
2. コミットメッセージや範囲に不一致があれば記録します（無関係な変更がひとつのコミットに混在している場合など）

ここでの指摘は参考情報のみです。計画でコミットメッセージを正確に予測できることはまれであり、作業者が正当な理由で調整した可能性もあります。不一致はレビュー文書に記録しますが、判定には一切影響しません。

フェーズ 5：判定とレビュードキュメント

判定はゴール契約のみに基づいて算出します。対象となるのはフェーズ 2（基準）とフェーズ 3（テスト）です。

PASS の条件（すべて満たす必要があります。判定は AND です）：

• 計画で指定されたすべてのファイルが存在する
• 各タスクの受け入れ基準が満たされている（二択で各基準を判定）
• 計画で指定されたすべてのテストが成功する
• テストスイート全体で回帰がない
• 計画の成功基準が満たされている

上記の条件がひとつでも満たされない場合は FAIL です。条件付きの PASS はありません。

判定に使用してはならない項目（参考情報のみ）：

• プレースホルダーまたはデバッグコード（基準を未達成にする場合を除く）
• コミットメッセージまたはコミット構成の不一致
• スタイル、命名、コード品質に関する所見

判定を出したら、レビュードキュメントを作成して保存します。

レビュードキュメント

保存場所

docs/engineering-discipline/reviews/YYYY-MM-DD-<feature-name>-review.md

（レビュー場所に関するユーザーの希望は、このデフォルトより優先されます。）

ドキュメントの構成

# [Feature Name] Review

**Date:** YYYY-MM-DD HH:MM
**Plan Document:** `docs/engineering-discipline/plans/YYYY-MM-DD-<feature-name>.md`
**Verdict:** PASS / FAIL

---

## 1. File Inspection Against Plan

| Planned File | Status | Notes |
|---|---|---|
| `path/to/file` | OK / Missing / Mismatch | Details |

## 2. Test Results

| Test Command | Result | Notes |
|---|---|---|
| `pytest tests/...` | PASS / FAIL | Error details if failed |

**Full Test Suite:** PASS / FAIL (N passed, M failed)

## 3. Acceptance Criteria

| Task | Criterion | Met |
|---|---|---|
| Task 1 | [criterion verbatim from plan] | PASS / FAIL |

## 4. Advisory Findings (not verdict inputs)

- [ ] No placeholders
- [ ] No debug code
- [ ] No commented-out code blocks
- [ ] No changes outside plan scope

**Findings:**
- (Describe with file path and line number)

**Git history (informational):**

| Planned Commit | Actual Commit | Match |
|---|---|---|
| `feat: add X` | `abc1234 feat: add X` | OK / Mismatch |

## 5. Overall Assessment

(Summary of the overall judgment. If FAIL, describe specifically which items failed and why.)

## 6. Follow-up Actions

- (If FAIL: list of items that need to be fixed)
- (If PASS: record improvement suggestions if any)

中止する場合

次の状況では直ちに作業を中止し、ユーザーに知らせてください。

• 計画ファイルが存在しない、または読み取れない
• テスト実行環境が整っていない（依存関係がインストールされていない場合など）
• 計画ドキュメントの形式を解析できない

判断に迷った場合は推測せず、ユーザーに確認してください。

アンチパターン

アンチパターン	問題点
run-plan の実行ログを読んで検証する	情報分離の違反です。実行者の見解に引きずられます
テストを実行せず、以前のテスト結果を信頼する	実行後に環境が変わっている可能性があります。独立した検証になりません
問題を見つけて直接修正する	レビュアーと実装者の役割分担に違反します
「ほぼ問題ないので PASS」と判定する	条件付きの PASS はありません。基準を満たしていなければ FAIL です
見た目の問題（コミットメッセージ、TODO、スタイル）を理由に FAIL とする	二択の判定が損なわれ、些細な点をめぐる再試行ループが発生します。見た目に関する指摘は参考情報です
レビュー結果を口頭で伝え、文書を保存しない	検証記録が残らず、追跡できません
計画にない基準で評価する	レビュアーは計画の基準だけで評価します。独自の基準を追加することは禁止されています
計画の要約を受け取り、それに基づいて検証する	要約の過程で情報が失われます。必ず元の計画を直接読んでください

最小限のチェックリスト

レビュー完了時に自己確認します。

• 計画書をディスクから直接読み込みました
• run-plan の実行結果を入力として受け取っていません
• すべてのテストを自分で実行しました
• 計画内のすべてのタスクを確認しました
• 判定は PASS または FAIL のいずれかです
• レビュードキュメントをファイルに保存しました

移行

レビュー完了後：

• PASS → 結果をユーザーに報告し、次のステップ（PR 作成、デプロイなど）を提案します
• FAIL → 問題点をユーザーに報告します。修正が必要な場合は、run-plan または systematic-debugging スキルへの移行を提案します
• 計画自体に問題がある場合 → 計画を修正するため、plan-crafting スキルに戻ることを提案します

このスキル自体は、次のスキルを呼び出しません。レビュードキュメントを保存して結果を報告し、次のステップはユーザーに判断してもらいます。