review-code

コードレビューワークフロー

現在のブランチの変更を、複数の視点から包括的にレビューします。このスキルは Review Council を有効にし、自動セキュリティスキャンを組み合わせて、問題がプルリクエストに到達する前に検出します。

注意

スコープの境界：このスキルはコードをレビューし、修正をコミットします。プルリクエストの作成、リモートへのプッシュ、マージは行いません。レビューが完了したら、そこで停止し、次に /submit-pr を実行するようユーザーに提案してください。プルリクエストの作成には進まないでください。それは /submit-pr の担当です。

警告

チェックポイントプロトコル。このワークフローが ### CHECKPOINT に到達したら、ユーザーに判断を求めるよう積極的に促す必要があります。情報を提示してそのまま続行するだけではいけません。エージェントの対話型プロンプト機能（例：Claude Code の AskUserQuestion）を使って、明示的な応答を得てから続行してください。これにより、キュー内または処理中のメッセージを承認と誤解することを防ぎます。エージェントに対話型プロンプト機能がない場合は、チェックポイントの内容を出力し、ユーザーが明示的に応答するまですべての作業を停止してください。

Step 1: 現在の変更を分析する

現在のブランチのすべての変更を特定します。

1. git diff origin/main...HEAD を実行して、main との差分を確認します
2. git diff と git diff --cached を実行して、未コミットの作業を確認します
3. git status を実行して、変更、追加、削除されたファイルを確認します

プロジェクトのディレクトリ構成に基づいて、変更されたファイルをレイヤー別に分類します。

• フロントエンド：UI コンポーネント、ページ、スタイル、クライアント側のロジック
• バックエンド：API ルート、サービス、ビジネスロジック、サーバー側のコード
• データベース：スキーマファイル、マイグレーション、シードデータ
• 設定：設定ファイル、CI/CD、コンテナ定義、環境ファイル
• ドキュメント：Markdown ファイル、ドキュメントディレクトリ
• テスト：テストファイル（.test.*、.spec.*）

カテゴリ別に変更されたファイルの概要をユーザーに提示します。

Step 2: フォーマットと Lint のチェックを実行する

Council によるレビューの前に、プロジェクトのフォーマットおよび Lint コマンドを実行して、機械的な問題を早期に検出します。一般的な例：

# Adapt to your project's toolchain
format:check    # Prettier, Black, gofmt, etc.
lint            # ESLint, Ruff, golangci-lint, etc.

フォーマットチェックに失敗した場合は、報告されたファイルに自動フォーマッターを実行して変更をステージし、すぐに修正します。フォーマットの問題は Council によるレビューに含めず、修正だけを行います。

Step 3: 自動セキュリティスキャンを実行する

変更されたすべてのファイルに対して、静的アプリケーションセキュリティテスト（SAST）を実施します。以下をスキャンします。

SAST スキャンのチェックリスト

• すべてのデータベースクエリがパラメーター化されていますか？（SQL／NoSQL インジェクション）
• ユーザー入力はレンダリング前にサニタイズされていますか？（XSS — 反射型、格納型、DOM ベース）
• 状態を変更するエンドポイントは CSRF から保護されていますか？
• ハードコードされたシークレット、API キー、パスワード、接続文字列はありませんか？
• 認証フローは安全なパターンに従っていますか？（認証を迂回できる経路がない）
• エラーメッセージから内部情報が漏れていませんか？（スタックトレース、DB 構造）
• 依存関係に既知の CVE はありませんか？
• ファイルアップロードは検証され、制限されていますか？
• 保護対象のすべてのエンドポイントに認可チェックがありますか？

バックエンドファイルが変更されている場合は、ハードニングレビューも実施します。

• すべてのユーザー向け入力に対して、入力検証は十分に行われていますか？
• 認証および認可のチェックは存在し、正しく機能していますか？
• エラーレスポンスは安全ですか？（内部情報が漏れていない）
• シークレットは安全に管理されていますか？（ハードコードせず、環境変数や Vault を使用）
• セキュリティヘッダーは設定されていますか？（CSP、HSTS、X-Frame-Options）
• 公開エンドポイントにレート制限は設定されていますか？

すべての検出事項を、重大度（Critical、High、Medium、Low、Info）とともにまとめます。

Claude Code の最適化：/security-scanning:security-sast および /security-scanning:security-hardening スキルが利用可能な場合は、強化された自動スキャンのためにそれらを使用してください。利用できない場合は、上記の手動チェックリストに従ってください。

Step 4: アクセシビリティ監査を実施する（フロントエンドに変更がある場合）

変更セットにフロントエンドのファイル（UI コンポーネント、CSS、HTML テンプレート）が含まれている場合は、変更したコンポーネントの WCAG 準拠状況を確認します。

アクセシビリティチェックリスト

• テキストやインタラクティブ要素は、色のコントラスト比の基準を満たしていますか？（通常のテキストは 4.5:1、大きなテキストは 3:1）
• すべてのインタラクティブ要素に、キーボードだけでアクセスし、操作できますか？
• ARIA 属性は正しく使われていますか？（ロール、ラベル、ライブリージョン）
• 動的なコンテンツの変更時（モーダル、ルート遷移）に、フォーカスは適切に管理されていますか？
• セマンティック HTML が使われていますか？（<div onClick> ではなく <button>、<nav>、<main>、<article>）
• 画像やアイコンには、アクセシブルな名前が設定されていますか？（alt テキスト、aria-label）
• フォームの入力項目はラベルと関連付けられていますか？
• スクリーンリーダーで読み上げたとき、ページの内容を順番に理解できますか？

Claude Code の最適化：/ui-design:accessibility-audit スキルが利用可能な場合は、それを使って WCAG 準拠状況の自動チェックを強化します。利用できない場合は、上記の手動チェックリストに従ってください。

Step 5: レビュー評議会を実施する

スキルの councils/review-council.md からレビュー評議会のテンプレートを読み込み、評議会によるレビューを一通り実施します。各評議員について、スキルの agents/ ディレクトリからエージェントの定義を読み込み、指定された複雑度の段階に応じてレビューの深さを調整してください。

セキュリティエンジニア（リード）

• Step 3 の SAST の検出結果をすべて確認する
• 変更したコードに OWASP Top 10 の脆弱性がないか確認する
• 新しいエンドポイントやフォームの入力値がサニタイズされているか検証する
• シークレット管理を確認する（認証情報、API キー、トークンをハードコードしていないこと）
• 認証および認可のロジックを検証する
• 投票：承認／懸念あり／ブロック
• 検出結果：各問題の重大度とファイルの場所を列挙する
• 推奨事項：各検出結果に対する具体的な修正方法

QA リード

• 変更したファイルのテストカバレッジを評価する
• 新機能に対応するテストがあるか確認する
• テストされていないエッジケースや境界条件を特定する
• エラー発生時のシナリオがテストされているか検証する
• テストカバレッジが 80% 超の目標を満たしているか確認する
• 投票：承認／懸念あり／ブロック
• 検出結果：不足しているテスト、カバレッジの不足、未テストのシナリオ
• 推奨事項：追加すべき具体的なテスト

DevX エンジニア

• ユーザー向けの変更に合わせてドキュメントが更新されているか確認する
• コードの読みやすさと複雑なロジックの明確さを確認する
• README やドキュメントに新機能や変更が反映されているか検証する
• パブリック API に適切なドキュメントコメントがあるか確認する
• 投票：承認／懸念あり／ブロック
• 検出結果：ドキュメントの不足、不明瞭なコードの箇所
• 推奨事項：ドキュメントと明確さを改善する方法

ドメインスペシャリスト

変更したファイルに応じて適切なスペシャリストを選択します。

• フロントエンドのファイルが変更されている場合は、フロントエンドスペシャリスト
• バックエンドのファイルが変更されている場合は、バックエンドスペシャリスト
• フロントエンドとバックエンドの両方にまたがる変更の場合は、両方

ドメイン固有のベストプラクティスを確認します。

• コンポーネントのパターン、状態管理、レンダリングのパフォーマンス（フロントエンド）
• フレームワークのパターン、サービスアーキテクチャ、API 設計（バックエンド）
• スキーマ設計、クエリの最適化、マイグレーションの安全性（データベース）
• 投票：承認／懸念あり／ブロック
• 検出結果：パターン違反、アンチパターン、パフォーマンス上の懸念
• 推奨事項：具体的な改善方法

Step 6: レビュー結果をまとめて報告する

重大度別に整理したレビュー全体のレポートを提示します。

重大／ブロッキングの問題

マージ前に必ず修正すべき問題（ブロック票、または SAST の重大な検出結果）。

優先度の高い問題

修正を強く推奨する問題（SAST の重大度が高い検出結果、またはセキュリティ上の懸念を伴う懸念票）。

優先度が中程度の問題

ブロック要因ではないものの、修正が望ましい問題（SAST の重大度が中程度の検出結果、コード品質に関する懸念）。

優先度の低い問題／提案

あると望ましい改善（重大度の低い検出結果、スタイルに関する提案、軽微なドキュメント不足）。

レビュー結果の概要

• 全体のステータス：承認／要修正／ブロック
• 評議会の投票：各メンバーの投票の概要
• 対応項目：優先順位を付けた修正項目のリスト

CHECKPOINT：すべての指摘事項をユーザーに提示します。今すぐ対応する項目を確認します。指示があるまで待ちます。

ステップ 7：修正を適用する

ユーザーが修正を承認した項目ごとに、以下を実行します。

1. 修正を適用する
2. 該当するチェック（lint、テスト、型チェック、またはセキュリティスキャン）を再実行し、修正を検証する
3. 変更をステージングする

ユーザーが一部の指摘事項をスキップするよう求めた場合は、ステップ 9 の保留項目として記録します。

CHECKPOINT：適用した修正をユーザーに提示します。コミットする前に、すべての変更に問題がないことを確認します。

ステップ 8：コミットする

ユーザーが承認した場合：

1. すべての変更をステージングする
2. 適切な Conventional Commit メッセージ（例：fix(security): address SAST findings や refactor: address code review feedback）でコミットする

ステップ 9：保留中の作業を記録する

今回のサイクルで修正されずに保留となったレビューの指摘事項がある場合は、記録しておきます。

保留項目を確認する

以下の情報源を確認し、保留中の作業を特定します。

1. スキップされた指摘事項：レビューレポートからユーザーが対応しないことを選択した項目
2. 優先度の低い提案：低または情報カテゴリに分類され、修正されなかった項目
3. 評議会からの推奨事項：この PR の対象範囲外として評議会のメンバーが提案した改善事項

保留中の作業を記録する

保留項目ごとに、指摘内容、保留にした理由の背景、および必要な対応を記載した課題をプロジェクトの課題管理システムに作成します。

ヒント

すべてのレビューで保留中の作業が発生するとは限りません。すべての指摘事項に対応したか、受け入れた場合は、このステップを完全に省略します。課題を作ること自体を目的に、フォローアップ課題を作成しないでください。

ステップ 10：引き継ぎ — ここで停止する

注意

このスキルの作業は完了です。 プルリクエストの作成、リモートへのプッシュ、マージは続けて行わないでください。これらは、それぞれ独自のワークフローとチェックポイントを持つ別のスキルです。

次のステップを提案し、その後 停止 します。

• PR の準備ができている場合：「/submit-pr を実行してプルリクエストを作成してください」
• さらに作業が必要な場合：「実装を続け、準備ができたら /review-code を再度実行してください」

このスキルの実行中にブランチをプッシュしたり、PR を作成したり、/submit-pr を呼び出したりしないでください。