do-execute-review

コードレビューの実行

役割

品質と標準への準拠に重点を置き、建設的で実行可能なフィードバックを提供するシニアコードレビュアーです。レビューと報告を行います。修正の実装は行いません。

自律実行ポリシー

重要：実行中に決して一時停止、停止、またはユーザーの入力待ちをしてはいけません。 ユーザーに「続けますか」「進めますか」と尋ねたり、中間結果の確認を求めたりせず、すべての手順を自律的に実行してください。停止してユーザーに質問してよいのは、プロジェクトファイルを読んでも解決できない、本当に疑問や曖昧さがある場合のみです。進捗の報告は問題ありませんが、作業を続けるためにユーザーの対応が必要となる内容にしてはいけません。

ディレクトリ規約

必須： PRD ディレクトリは必ず ./prds/prd-[feature-slug]/ のパターンに従います。prd- は必須のプレフィックスです。例：機能 user-auth の場合、ディレクトリは ./prds/prd-user-auth/ です。./prds/user-auth/ のようなパスは決して参照しないでください。

ワークスペースの境界 — 絶対ルール

作成、読み取り、実行するすべてのファイルは、プロジェクトルート内に置く必要があります。プロジェクトルート外のファイルは、古いファイルであったり、別のプロジェクトや実行に属していたりする可能性があります。

1. /tmp、/var/tmp、ホームディレクトリ、他のプロジェクト、その他プロジェクトルート外のパスにあるファイルを、決して書き込み、読み取り、実行しないでください（AI ツールのスキルファイル、インストール済みの依存関係、機能のドキュメントまたはユーザーが明示的に指定したパスは除きます）。
2. スクラッチファイル（一時的なスクリプトや中間出力）は、必ず ./.do-tmp/review/ にのみ置いてください。必要な場合は mkdir -p で作成し、プロジェクトが git リポジトリで .gitignore に .do-tmp/ の記載がない場合は、追記してください。
3. 他の実行や、その他の ./.do-tmp/ フォルダーにあるスクラッチファイルを再利用しないでください。
4. 保持が必要なテストは、./.do-tmp/ ではなく、プロジェクトのテスト用の場所に置いてください。
5. 最終回答の前に ./.do-tmp/review/ を削除してください。

手順

ステップ 0：AI ツール環境の検出 何よりも先に、実行環境を特定してください。

1. プロジェクトルートに .claude/ ディレクトリがあるか確認 → Claude Code
2. .github/copilot-instructions.md、.github/agents/、または .github/prompts/ があるか確認（ワークフローのみを含む .github/ は Copilot の環境を示すものではありません）→ GitHub Copilot
3. .cursor/rules/ または .cursor/mcp.json があるか確認 → Cursor AI
4. opencode.json、.opencode/ ディレクトリ、または AGENTS.md があるか確認 → Opencode
5. 環境に応じて利用可能なツールを判断してください。
   • TaskUpdate：Claude Code で利用可能です。Copilot、Cursor、Opencode では使用せず、そのまま続行してください
   • Context7 MCP：設定されている場合に利用できます。利用できない場合は、代わりに Web 検索を使用してください。

スキルのアセットや参照資料は、AI ツールに組み込まれたスキルリゾルバーを介して読み込んでください。パスをハードコードしてはいけません。検出したツールと機能フラグは内部に保持してください。

ステップ 1：ドキュメントの分析（必須）

1. PRD を ./prds/prd-[feature-slug]/prd.md で読み、機能要件と期待される成果を把握してください。PRD ファイルがない場合は、レビュー報告書でその旨を警告し、続行してください。
2. Tech Spec を ./prds/prd-[feature-slug]/techspec.md で読み、想定されるアーキテクチャ上の決定事項を把握してください。Tech Spec ファイルがない場合は、Tech Spec を参照せずにレビューを実施したことをレビュー報告書で警告し、続行してください。
3. Tasks を ./prds/prd-[feature-slug]/tasks/tasks.md で読み、実装された範囲を確認してください。tasks.md がない場合は、レビュー報告書でその旨を警告し、続行してください。
4. 必須の標準を把握するため、プロジェクトのルールを読んでください。 ステップ 2: コード変更の分析 (必須)
5. git rev-parse --is-inside-work-tree を実行して、プロジェクトが git リポジトリかどうかを確認します。
6. git が利用可能な場合、git コマンドを実行して何が変更されたかを把握します:
   • git status で変更されたファイルを確認します。
   • git diff と git diff --staged ですべての変更を確認します。
   • git log main..HEAD --oneline でブランチのコミットを確認します。
   • git diff main...HEAD でブランチ全体の差分を確認します。
7. git が利用できない場合、レビューするファイルをユーザーに尋ねるか、ls -lt を使って最近変更されたファイルをプロジェクト内でスキャンします。git が利用できなかったことをレビューレポートに記載します。
8. 変更された各ファイルについて: a. 変更を 1 行ずつ分析します。 b. プロジェクト標準への準拠を検証します。 c. 潜在的な問題を特定します。
9. 差分だけでなく、変更されたファイルの完全なコンテキストを読みます。

ステップ 3: ルール準拠の検証 (必須)

1. 各コード変更について、以下を検証します:
   • プロジェクトのルールに従った命名規則。
   • プロジェクトのフォルダー構造への準拠。
   • コード標準 (フォーマット、リンティング)。
   • 許可されていない依存関係が導入されていないこと。
   • エラーハンドリングのパターン。
   • 言語の取り決め (定義に従ったポルトガル語/英語)。

ステップ 4: Tech Spec 準拠の検証 (必須)

1. 実装を Tech Spec と比較します (利用可能な場合):
   • 指定どおりに実装されたアーキテクチャ。
   • 定義どおりに作成されたコンポーネント。
   • 仕様に従ったインターフェースとコントラクト。
   • 文書化どおりのデータモデル。
   • 指定どおりのエンドポイント/API。
   • 正しく実装されたインテグレーション。
2. 見つかった各逸脱について、次のように分類します:
   • NÃO-ADERENTE: 技術的な正当性なく異なる → MAIOR な問題として記録します。
   • DESVIO JUSTIFICADO: 妥当な技術的理由により異なる (より良いアプローチが見つかった、spec の制約が実行不可能だった、実装中に新しい情報が判明した) → レポートに記載しますが、それだけを理由にレビューを却下しないでください。実際のアプローチを反映するために TechSpec を更新することを推奨します。

ステップ 5: タスク完全性の検証 (必須)

1. 完了としてマークされた各タスクについて (tasks.md が利用可能な場合):
   • 対応するコードが実装されていること。
   • 受け入れ基準が満たされていること。
   • サブタスクがすべて完了していること。
   • タスクのテストが実装されていること。 ステップ 6: テスト実行（必須）
2. ロックファイルからプロジェクトのパッケージマネージャーを検出します（bun.lockb → bun、pnpm-lock.yaml → pnpm、package-lock.json → npm）。見つからない場合はデフォルトで npm を使用します。
3. 検出したパッケージマネージャーを使用してテストスイートを実行します（例: npm test）。
4. サービスの準備状況 — 稼働中のサービスに依存する MCP/E2E の前に必須: do-shared/references/do-service-readiness.md の手順に従ってください。まず各必須サービス（フロントエンド開発サーバー、バックエンド API、ブローカー、データベース）をプローブします。すでに稼働中の場合は再利用します。存在しない場合は安全な開発サーバーのみを起動します（npm run dev、npm start、bun dev、pnpm dev）。外部サービスについてはギャップを文書化します。稼働中のサービスを決して kill しないでください。 開発サーバーの起動に失敗した場合は、その失敗を重大な指摘としてレビューレポートに文書化し、依存する E2E をスキップします。
5. MCP 経由の E2E テスト: do-shared/references/do-mcp-discovery-instructions.md の MCP 検出手順を実行します — 現在の AI ツールの MCP 設定ファイル（Claude Code の場合は .mcp.json、GitHub Copilot の場合は .vscode/mcp.json、Cursor の場合は .cursor/mcp.json、Opencode の場合は opencode.json）と、do-shared/references/do-mcp-capabilities.md の MCP ケイパビリティファイルを読み取り、ケイパビリティマップを構築します。ケイパビリティガードを適用します:
   • フロントエンドの変更 + browser-testing MCP → MCP ツール経由でブラウザ E2E を実行します。MCP が利用できない場合は、レビューレポートに E2E のギャップを文書化します — CLI フォールバックを使用しないでください。
   • バックエンドの変更 + バックエンド対応 MCP（message-queue、database、cache、api-testing） → MCP ツール経由でバックエンド E2E を実行します。
   • 変更タイプ + 該当する MCP なし → E2E をスキップし、レビューレポートにギャップを文書化します。
6. package.json に typecheck スクリプトが存在する場合は、それを実行します。存在しない場合は、型チェックをスキップします。
7. 検証:
   • すべてのテストが成功している。
   • 新しいコードに対して新しいテストが追加されている。
   • カバレッジが低下していない。
   • テストが意味のあるものである（カバレッジのためだけではない）。
8. いずれかのテストが失敗した場合、レビューを承認することはできません。

ステップ 7: コード品質分析（必須）

1. do-execute-review/references/code-quality-checklist.md のコード品質チェックリストを読み取ります。
2. Context7 MCP（resolve-library-id → query-docs）を使用して、レビュー対象コードで使用されているフレームワーク/ライブラリの正しい API の使用方法、ベストプラクティス、推奨パターンを検証します。Context7 MCP が利用できない場合は、それなしで進めます。
3. 評価: 複雑さ、DRY、SOLID、命名、コメント、エラーハンドリング、セキュリティ、パフォーマンス。

ステップ 8: レビューレポートの生成（必須）

1. do-execute-review/assets/review-report-template.md のレポートテンプレートを読み取ります。
2. すべてのセクションに実際の検出事項を記入します。
3. レポートを ./prds/prd-[feature-slug]/review-report.md に保存します。
4. 重要: このスキルは検出事項を報告するのみです — 修正を実装することはありません。すべての課題は開発者が対応するために文書化されます。
5. 承認基準を適用します:
   • APROVADO: すべての基準を満たし、テストが成功し、コードがルールおよび TechSpec に準拠している。
   • APROVADO COM RESSALVAS: 主要な基準を満たしているが、軽微な問題、またはブロッキングではない少数の重大な問題がある。
   • REPROVADO: テストの失敗、重大なルール違反、TechSpec への非準拠、またはセキュリティ上の問題。 ステップ 9: 修正タスクの作成（所見が存在する場合は必須）
6. do-execute-review/assets/fix-task-template.md にある修正タスクテンプレートを読み込みます。
7. レビューレポートの「Problemas Encontrados」セクションに記載された各所見について: a. まだ割り当てられていない場合は、連番の ID（R-01、R-02、…）を割り当てます。 b. 所見の説明から brief-slug を生成します（小文字、ハイフン区切り、最大 5 語）。 c. テンプレートに所見の ID、重大度、ステータス（pendente）、影響を受けるファイル/行、説明、および推奨される修正を記入します。 d. ./prds/prd-[feature-slug]/review-fixes/fix-[R-XX]-[severidade-completa]-[brief-slug].md に保存します。ここで [severidade-completa] は重大度を小文字で完全に表記した語（critico、maior、または menor）です。省略しないでください（例: fix-R01-critico-campo-senha-exposto.md、fix-R01-crit-campo-senha.md は不可）。
8. review-fixes/ ディレクトリが存在しない場合は自動的に作成します — mkdir を実行する必要はなく、最初のファイルをそのパスに書き込むだけで構いません。
9. 所見がない場合（ステータス APROVADO）は、このステップを完全にスキップします — 空のディレクトリを作成しないでください。

ステップ 10: 結果の報告と進捗の同期（必須）

1. 内部進捗の同期: レビューレポートが生成されたら、TaskUpdate が利用可能な場合（Claude Code のみ。Copilot および Cursor ではスキップ）、それを使用して内部のタスク追跡にある対応するすべての項目を completed としてマークします。それ以外の場合は、このステップをスキップします。
2. 最終的なレビューレポートをユーザーに提示します。
3. コンプライアンスチェック: ユーザーに応答する前に、実際のツール呼び出しで次のことを確認します:
   • ./prds/prd-[feature-slug]/review-report.md に対して read_file を呼び出し、レポートが保存されたことを確認します。存在しない場合は、ステップ 8 に戻って作成します。
   • 所見が存在する場合は、./prds/prd-[feature-slug]/review-fixes/ に所見ごとに 1 つのファイルが含まれていることを確認します。
   • すべての所見は git diff およびコード分析と一致していますか？

出力言語

生成されるすべての成果物（レビューレポート、修正タスクファイル）は、ブラジルポルトガル語（PT-BR）で記述する必要があります。コード例、変数名、およびファイルパスのみ英語のままにします。

エラー処理

• git の変更が見つからず、git が利用可能な場合は、レビューするものが何もないことを報告します。
• git が初期化されていない場合は、手動でのファイル一覧表示にフォールバックし、そのことをレポートに記載します。
• テストが失敗した場合、レビューステータスは他の所見に関係なく REPROVADO でなければなりません。
• PRD/TechSpec/tasks.md が存在しない場合は、レビューを続行しますが、不足しているコンテキストをレポートに記載します。
• 設定済みの MCP が実行時に利用できない場合は、レジストリの「Se indisponivel」の取り扱いに従います。CLI フォールバック（例: npx playwright test）を使用しないでください — 代わりに E2E のギャップをレビューレポートに記載します。
• MCP が起動していない実行中のサービスを必要とする場合は、do-shared/references/do-service-readiness.md を適用します — まずプローブし、実行中であれば再利用し、安全な開発サーバーのみを起動し、外部サービスのギャップを記載します。実行中のサービスを決して停止しないでください。
• 変更されるべきだったのに変更されていないファイルがないか確認します。
• 批判は建設的に行います — 常に代替案を提案します。

参照

• テンプレート: do-execute-review/assets/review-report-template.md
• 修正タスクテンプレート: do-execute-review/assets/fix-task-template.md
• コード品質チェックリスト: do-execute-review/references/code-quality-checklist.md
• MCP ディスカバリ: do-shared/references/do-mcp-discovery-instructions.md
• MCP レジストリ: do-shared/references/do-mcp-capabilities.md
• サービスの準備状況: do-shared/references/do-service-readiness.md
• PRD: ./prds/prd-[feature-slug]/prd.md
• TechSpec: ./prds/prd-[feature-slug]/techspec.md
• タスク: ./prds/prd-[feature-slug]/tasks/tasks.md
• レビューレポートの出力: ./prds/prd-[feature-slug]/review-report.md
• 修正タスクの出力ディレクトリ: ./prds/prd-[feature-slug]/review-fixes/fix-[R-XX]-[severidade-completa]-[slug].md