charted-review

コンテキスト

• designDocPath: $ARGUMENTS[0]

目標

${designDocPath} にある設計ドキュメントを、4 人の専門サブエージェントを並行して呼び出してレビューし、そのフィードバックを実行可能な単一のレビューにまとめます。

ステップ 1 - エージェントを設定する

ステップ 2 のサブエージェントがまだ設定されていない場合は、インストールするよう私に依頼してください。 私が承諾した場合、Cursor を使用しているなら、サブエージェントを ./assets/agents フォルダーから {workspaceRoot}/.cursor/agents フォルダーにコピーしてください。Cursor を使用していない場合は、パスを適宜変更してください。

ステップ 2 — 専門家による並行レビュー

次の 4 つのサブエージェントを同時に起動してください（すべて 1 つのメッセージで）。各エージェントには設計ドキュメントの全内容を渡し、構造化されたレビューを返すよう指示してください。

サブエージェントの種類	注目領域
accessibility-expert	提案された UI のアクセシビリティ — ARIA、キーボードナビゲーション、スクリーンリーダー対応、色のコントラスト、フォーカス管理、セマンティック HTML。
security-analyst	セキュリティへの影響 — 入力検証、インジェクションのリスク、認証／認可の不足、データ漏えい、安全なデフォルト設定。
ux-expert	ユーザビリティ — インタラクションパターン、エラー／空／読み込み状態、情報アーキテクチャ、レスポンシブ対応、認知負荷。
xp-coach	エンジニアリングプラクティス — テスト容易性、段階的なリリース、PR 計画の品質、シンプルさ、YAGNI、リファクタリングの機会。

各サブエージェントへのプロンプトには、次の内容を含めてください。

1. 設計ドキュメントの全内容。
2. 次のセクションだけで構成されるレビューを返す指示：
   • Praise — 設計の優れた点（簡潔にまとめる）。
   • Concerns — 番号付きリスト。各懸念には、短いタイトル、説明、具体的な提案を含める。
   • Verdict — 次のいずれか：approve、request-changes、needs-discussion。

ステップ 3 — 統合と競合の検出

4 件のレビューを集め、ユーザーに概要表を提示してください。

専門家	判定	懸念の数

続いて、すべての懸念を専門家ごとにまとめて列挙してください。

列挙後、競合、つまり 2 人以上の専門家が矛盾する指針を示している箇所を特定してください（例：一方が「確認ダイアログを追加する」とし、もう一方が「操作手順を減らす」としている場合や、一方が「PR をさらに分割する」とし、もう一方が「すでに PR が多すぎる」としている場合）。

ステップ 4 — 対立点の確認（競合がある場合）

競合ごとに、次を行ってください。

1. 意見の相違を、関係する両方の専門家に明確に説明します。
2. 競合する各サブエージェントを再度起動し、次の内容を渡します。
   • 元の設計ドキュメント。
   • そのエージェント自身の元のレビュー。
   • そのエージェントの見解と矛盾する、相手の専門家の懸念。
   • 立場を修正するか、より強い根拠を示して擁護するよう指示します。
3. 互いに独立した競合ペアは並行して実行します。

確認後、専門家の意見が一致したかを確認してください。

ステップ 5 — 解決

• すべての競合が解決した場合：合意された変更を反映した、最終的な統合レビューを提示してください。
• 解決していない競合が残る場合：残っている意見の相違を、ユーザーにわかりやすい形式で提示してください。

未解決：{短いタイトル}

{専門家 A} の主張：{立場の要約}

{専門家 B} の主張：{立場の要約}

どちらを採用しますか？

未解決の競合それぞれについてユーザーの判断を待ってから、最終的な統合レビューを作成してください。

ステップ 6 — 最終出力

以下を含む統合レビューを作成します。

1. 総合判定 — 集約された結果に基づく approve、request-changes、または approve-with-nits。
2. 対応項目 — 設計ドキュメントに加える具体的な変更を、優先度順に並べた番号付きチェックリスト。
3. 解決済みの相違点 — 各相違点をどのように解決したか（専門家の譲歩またはユーザーの判断）を簡潔に記載します。