experts

エキスパートパネル

概要

専門家レビュアーのサブエージェントパネルを並行して派遣し、プロジェクトを監査します。各エージェントは専門家のペルソナを担い、独立してレビューします。結果は重大度順に並べた単一のレポートにまとめられ、実装計画に反映されます。

使用するタイミング

• リリース前のレビュー（「本番環境に公開する準備はできていますか？」）
• リファクタリング後の監査（「何か壊していませんか？」）
• 引き継いだコードベースの評価（「どのような状態のプロジェクトですか？」）
• 定期的なヘルスチェック
• あらゆる種類のプロジェクト：Web、モバイル、API、CLI、インフラストラクチャ、データパイプライン

ワークフロー

digraph expert_review {
  rankdir=TB;
  "User requests review" -> "Identify project type";
  "Identify project type" -> "Present default panel for that type";
  "Present default panel for that type" -> "Suggest stack-specific additions";
  "Suggest stack-specific additions" -> "Ask: add, remove, or adjust?";
  "Ask: add, remove, or adjust?" -> "Finalize panel";
  "Finalize panel" -> "Dispatch all agents in parallel (run_in_background)";
  "Dispatch all agents in parallel (run_in_background)" -> "As each completes, note key finding";
  "As each completes, note key finding" -> "All done?";
  "All done?" -> "As each completes, note key finding" [label="no"];
  "All done?" -> "Consolidate into severity-ranked table" [label="yes"];
  "Consolidate into severity-ranked table" -> "Present full report";
  "Present full report" -> "Offer to write implementation plan for fixes";
}

プロジェクトの種類別デフォルトパネル

Web（静的サイト、SPA、サーバーサイドレンダリングアプリ）

#	エキスパート	対象領域
1	SEO エキスパート	メタタグ、見出しの階層構造、サイトマップ、robots.txt、URL 構造、RSS、構造化データ
2	アクセシビリティエキスパート	セマンティック HTML、スキップナビゲーション、ARIA、色のコントラスト、キーボードナビゲーション、動き／アニメーション
3	モバイル UX エキスパート	ビューポート、レスポンシブ CSS、タッチターゲット（最小 44x44px）、フォントサイズ、オーバーフロー
4	コピーエディター	すべてのテンプレートとコンテンツのスペル、文法、トーンの一貫性
5	パフォーマンスエキスパート	CSS／JS の配信、画像の最適化、フォント、キャッシュ、ビルド設定
6	セキュリティレビュアー	ヘッダー、XSS の攻撃経路、機密データの露出、リンクのセキュリティ、CORS
7	ソーシャル／メタタグスペシャリスト	OpenGraph、Twitter カード、favicon、canonical URL、共有プレビュー
8	Web 標準エキスパート	HTML の検証、要素の正しい使用、仕様への準拠、ARIA の誤用

API

#	エキスパート	対象領域
1	API 設計レビュアー	REST の規約、命名の一貫性、バージョン管理、ページネーション、エラーレスポンス
2	セキュリティレビュアー	認証／認可、入力検証、レート制限、OWASP API Top 10
3	パフォーマンスレビュアー	クエリ効率、N+1 問題、キャッシュ戦略、ペイロードサイズ
4	ドキュメントレビュアー	OpenAPI／Swagger の完全性、サンプルの正確性、エラーに関するドキュメント
5	信頼性レビュアー	エラー処理、タイムアウト、リトライ、サーキットブレーカー、段階的な機能縮退
6	データモデルレビュアー	スキーマ設計、マイグレーション、インデックス、制約、データ整合性

モバイルアプリ（iOS／Android）

#	エキスパート	対象領域
1	UX レビュアー	ナビゲーションパターン、ジェスチャー処理、プラットフォームの慣習、オンボーディング
2	アクセシビリティレビュアー	VoiceOver／TalkBack、ダイナミックタイプ、コントラスト、タッチターゲット
3	パフォーマンスレビュアー	起動時間、メモリ、バッテリー、ネットワーク効率、画像処理
4	セキュリティレビュアー	データ保存、キーチェーン／キーストアの使用、証明書ピンニング、認証フロー
5	ストアコンプライアンスレビュアー	App Store／Play Store のガイドライン、権限の正当性、プライバシーラベル
6	コピーエディター	UI テキスト、エラーメッセージ、オンボーディングの文言、ローカライズへの対応状況

CLI ツール

#	エキスパート	対象領域
1	UX／操作性レビュアー	フラグの命名、ヘルプテキスト、出力形式、段階的な情報提示
2	エラー処理レビュアー	エラーメッセージ、終了コード、エッジケース、適切な失敗処理
3	互換性レビュアー	シェル互換性、OS サポート、パス処理、エンコーディング
4	セキュリティレビュアー	入力のサニタイズ、認証情報の取り扱い、ファイル権限
5	ドキュメントレビュアー	man ページ／--help の完全性、README、サンプル

プロジェクト固有の追加レビュアーを提案してください。 デフォルトパネルを提示した後、技術スタックを分析し、見落としを補うレビュアーを提案します。例：

• E コマースの Web アプリ： 決済フローレビュアー、商品カタログレビュアー
• Next.js + Vercel： デプロイ／設定スペシャリスト
• 認証を多用するアプリ： 認証／セッションレビュアー
• i18n 対応のサイト／アプリ： ローカライズレビュアー
• データパイプライン： データ品質レビュアー、スキーマ進化レビュアー

追加するかどうかはユーザーが決めます。ただし、関連するものは必ず提案してください。

エージェントプロンプトのテンプレート

すべてのレビュアーエージェントのプロンプトは、必ず次の構成に従ってください。

You are a [ROLE] reviewing a [PROJECT TYPE] [before launch / after refactor / etc.].
Do NOT write any code — only research and report findings.
If browser MCP tools are available, use them to inspect the running site at [URL].

The project is at [PATH]. [Brief description with key tech details].

Review the following and report issues ranked by severity
(critical, important, minor):

1. [Area] — [What to check, where to look]
2. [Area] — [What to check, where to look]
...
10. [Area] — [What to check, where to look]

Check [key directories]. Report a prioritized list of findings.

重要な要素：

• 最初にペルソナを指定 — 「あなたは[ROLE]です」と書くことで、エージェントの専門性を明確にします
• コード作成を禁止 — 「コードは一切書かないでください」と指定し、エージェントが修正を始めないようにします
• Browser MCP — 開発サーバーが起動している場合は URL を記載し、エージェントがソースだけでなく、レンダリング結果も確認できるようにします
• 重大度のランク付け — 出力を構造化（重大／重要／軽微）させます
• 番号付きのレビュー領域 — レビュアーの専門性に合わせた、具体的な領域を 8～12 個挙げます
• ディレクトリのヒント — 確認場所（src/、設定ファイルなど）を伝えます

ディスパッチパターン

すべてのレビュアーで run_in_background: true を指定して Agent ツールを使用します。並列処理を最大限に活用するため、1 つのメッセージブロックですべてをディスパッチしてください。

Agent(description="SEO expert site review", subagent_type="general-purpose", run_in_background=true, prompt="...")
Agent(description="Accessibility expert review", subagent_type="general-purpose", run_in_background=true, prompt="...")
...all agents in one message block...

各エージェントが完了したら、ユーザーに主な指摘事項を簡潔に伝えます。全エージェントの完了を待ってから、結果を完全にまとめてください。

結果の統合

すべての指摘事項を重複排除してランク付けし、1 つの表にまとめます。

## [Review Type]: [Project Name]

### CRITICAL (must fix)

| # | Issue | Source |
|---|-------|--------|
| 1 | **[Issue description]** ([specific detail]) | [Which reviewer] |

### IMPORTANT (should fix soon)

| # | Issue | Source |
|---|-------|--------|

### MINOR (backlog)

| # | Issue | Source |
|---|-------|--------|

### DEFERRED (noted, not blocking)

| # | Issue | Source | Reason |
|---|-------|--------|--------|

相互参照： 複数のレビュアーが同じ問題を指摘した場合は、1 行にまとめ、すべての情報源を記載します（例：Standards, A11y, Security）。

レポートの後

1. 統合したレポートを提示します
2. 修正に取り組むかどうか、ユーザーに確認します
3. 取り組む場合は、実装計画の作成を提案します（利用可能であれば writing-plans スキルを使用します）
4. 重大な項目から重要な項目、軽微な項目の順に対応します

よくある間違い

• ユーザーにパネルのカスタマイズを確認しない — 常にデフォルトのパネルを提示し、ディスパッチ前に変更がないか確認してください
• エージェントがコードを書く — 「コードは一切書かないでください」という制約がないと、エージェントは報告ではなく修正を始めてしまいます
• 汎用的なプロンプト — 「サイトの SEO を確認してください」では漠然としすぎています。確認場所とともに、具体的な領域を 8～12 個挙げてください
• 逐次ディスパッチ — エージェントはそれぞれ独立しています。必ず run_in_background を指定して並列にディスパッチしてください
• 情報源を明記しない — 統合レポートでは、ユーザーが信頼性を判断できるよう、各問題をどの専門家が見つけたか示す必要があります
• 計画のステップを省略する — 修正計画のない指摘事項の一覧は不完全です。実装計画の作成を提案してください
• プロジェクトの種類に合わないパネルを使う — API プロジェクトに Web パネルを使わないでください。プロジェクトの種類に合ったデフォルトのパネルを選んでください