| name | review-persona-analysis |
| description | Objectively scores a customer-persona analysis / design-decision document (produced by customer-persona-design) on a 100-point, 5-axis rubric (specificity/realism, needs depth, design alignment, segmentation/prioritization, verifiability) by dispatching an independent review agent. Use when the user asks to 'ペルソナ分析をレビューして', 'ペルソナ分析を採点して', or 'persona.md の成果物を評価して'. |
/review-persona-analysis — ペルソナ分析レビュー（エージェント分離実行）
このSkillは別エージェントを起動してレビューを行う。現在のセッションでは直接レビューしない。
作成コンテキスト（分析過程・会話履歴）をレビューエージェントに渡さないことで客観性を確保する。
実行手順
ステップ1: 情報収集（この作成セッションで行う）
以下の事実情報のみを収集する。分析の意図・作成過程の説明は含めない。
収集対象:
1. レビュー対象のペルソナ分析文書の内容（customer-persona-design Skillの出力、または dev/design/persona.md 形式の文書）
2. このプロダクトが解決したい課題（1〜2文。不明なら作成者に確認）
3. ペルソナ分析の根拠データの有無（ユーザーインタビュー・アンケート・アクセス解析等）
4. persona.md のどのPhase（1〜5）まで実施したか
ステップ2: レビューエージェント起動
Agent ツールを使い、以下の設定で別エージェントを起動する:
Agent ツールの設定:
- subagent_type: "general-purpose"
- description: "Review persona analysis objectively"
- prompt: 以下のテンプレートに収集した情報を埋め込む
プロンプトテンプレート（レビューエージェントに渡す内容）:
あなたは作成者とは別の客観的なUXリサーチ責任者です。
以下のペルソナ分析・デザイン方針を、5軸100点満点で評価してください。
## レビュー前の確認事項
- このプロダクトで解決したい課題は何か
- 誰のためのプロダクトか
- persona.md のどのPhaseまで実施したか
- 根拠となるデータ（インタビュー・アンケート・行動データ）の有無
## レビュー対象
[ここにペルソナ分析文書の内容を埋め込む]
## 評価軸（各20点・合計100点）
### 1. ペルソナの具体性・リアリティ (20点)
年齢・職業・ライフスタイルが具体的数値・固有名詞で記述されているか、ステレオタイプでないか、
根拠となる情報源があるか、感情・フラストレーションが生々しく描写されているか。
- 18-20: 実在人物のように具体的、データ裏付けあり
- 14-17: おおむね具体的だが根拠不足
- 10-13: 表面的でステレオタイプ的
- 0-9: 抽象的で人物像が想像できない
### 2. 課題・ニーズの深掘り (20点)
機能的・感情的・社会的ニーズ（Jobs to be Done 3層）が揃っているか、ペインポイントの優先順位付けがあるか。
- 18-20: 3層が揃い、代替手段の不満と優先順位が定量的
- 14-17: おおむね深掘りされているが一部不足
- 10-13: 表面的ニーズのみ
- 0-9: ニーズ分析がほぼない
### 3. デザイン方針との整合性 (20点)
カラー・タイポグラフィ・UXパターンの選定根拠がペルソナ属性から論理的に導出されているか、
WCAGアクセシビリティ基準が考慮されているか。
- 18-20: すべてがペルソナ分析から論理的に導出、根拠明記
- 14-17: おおむね整合しているが一部根拠不足
- 10-13: デザイン方針はあるが論理的接続が弱い
- 0-9: デザイン方針がペルソナ分析と無関係
### 4. セグメント分類・優先順位 (20点)
プライマリ/セカンダリ/エッジケース/アンチペルソナの区別、優先順位の根拠、ペルソナ間比較分析。
- 18-20: 区別が明確、優先順位の根拠と比較分析あり
- 14-17: おおむね分類されているが一部不足
- 10-13: 複数ペルソナはあるが優先順位が不明確
- 0-9: セグメント分類がない
### 5. 検証可能性・活用設計 (20点)
仮説検証の方法（インタビュー・A/Bテスト）、開発チームでの活用形式、更新サイクル、KPI設定。
- 18-20: 検証方法・活用形式・更新計画・KPIが揃い実行可能
- 14-17: おおむね計画されているが一部不足
- 10-13: 検証方法は一部あるが活用設計が欠ける
- 0-9: 検証計画・活用設計がない
## 行動原則
`.claude/skills/_shared/review-rubrics.yaml` の `common_principles`（evidence_based / citation_required / non_destructive）を Read して適用すること。加えて本 skill 固有の原則として:
- Devil's Advocate: 「もっともらしい」ではなく「本当に実在感があるか」を疑う
## 出力フォーマット
構造化されたレビューレポート（総合点/100・判定S〜D・軸別採点表・良かった点・改善提案・
具体的な強化が必要な箇所の表・重要チェック項目・次のアクション推奨）を出力すること。
判定基準は `.claude/skills/_shared/review-rubrics.yaml` の `verdict_scales.rank5_100` を Read して適用すること（S=実装フェーズへ進む準備完了 〜 D=根本的な見直しが必要、点数帯は同ファイルが SoT）。
## 重要な注意事項
レビュワーは元ファイルを絶対に編集してはならない。フィードバックの提供のみを行う。
ステップ3: 結果の報告
レビューエージェントから返却された結果を、そのままユーザーに表示する。
要約や解釈を加えない（レビューの客観性を維持するため）。
注意事項
- 絶対に作成セッション内で直接レビューしない。必ず Agent ツールで別エージェントを起動すること
- レビューエージェントに渡す情報は分析文書の事実内容のみ。作成過程の会話は渡さない
- S/A判定であればデザイン決定サマリーをもとに実装フェーズ（
ibm-carbon-design-system / ui-design-guidelines Skill）へ進むことを推奨する
- B以下の場合は改善提案を反映してから
customer-persona-design Skillで再作成し、再レビューする
出典・関連 Skill
原文: workflows/software-development/design/review-persona.md。レビュー対象の作成元: customer-persona-design。エージェント分離レビューの構造は /review-changes コマンドに準拠。
