persona-designer

name	persona-designer
user-invocable	false
description	プロダクトのペルソナ/ユーザー像を、仮説と根拠（観察・調査・制約）で組み立て、意思決定に使える形へ整形する。※会話口調のペルソナ（にゃんこ）とは別物。

Persona Designer Skill

発火条件（適用タイミング）

• 依頼が「ペルソナ」「想定ユーザー」「ターゲット」「JTBD」「課題仮説」「利用シーン」の整理なら適用する。
• doc/input/rdd.md の「想定ユーザー像」「ユースケース」が未確定/曖昧な場合は優先適用する。

このSkillの基本方針（整理軸）

• 基本方針: ペルソナは“キャラ作り”ではなく、設計判断のための「仮説モデル」。
• 根拠重視: 推測で断言しない。事実（観察/既存ログ/ヒアリング/競合）と仮説を分けて書く。
• 運用可能性: 作って終わりではなく、検証と更新ができる形にする。

思想（判断ルール）

1. ペルソナは「代表例」であって「全員」ではない。どこまでを代表させるかを明示する。
2. 行動・目的・制約（時間/予算/スキル/環境）を中心に据える。属性（年齢等）は必要最小限。
3. 競合や代替行動（いまどうやって解決しているか）を必ず含める。
4. “痛み”と“価値”を同時に持つ（何が困り、何が嬉しいか）。
5. 検証可能な仮説に落とす（次に取るべき調査が決まる形）。

進め方（最初に確認する問い）

• 誰が使う？（利用者/購入者/管理者の分離は必要？）
• 何を達成したい？（目的/JTBD）
• どんな制約がある？（時間/頻度/環境/端末/権限）
• いまの代替手段は？（競合/手作業/Excel等）
• 成功/失敗は何で判断する？（KPI/体験/業務）

出力フォーマット（必ずこの順）

1. 前提（事実/仮説/不明点）
2. ペルソナ候補（1〜3名）
3. 各ペルソナの「目的/状況/制約/代替/痛み/価値」
4. 優先順位（どれをMVPで優先するか）
5. 検証計画（次に聞く/見る/測る）

よくある落とし穴

• 属性だけで作って、設計判断に使えない
• “理想ユーザー”しか描かず、現実の制約が抜ける
• 仮説と事実が混ざり、検証できない