From persona-creation
Creates UX/marketing user personas via 5-agent discussions on design, research, narrative, bias review, and validation. Outputs Markdown sheets; supports iterative sessions with context files.
npx claudepluginhub sean-sunagaku/claude-code-plugin --plugin persona-creationThis skill uses the workspace's default tool permissions.
5つの専門エージェントがディスカッション型でチーム議論し、UX/マーケティング向けのユーザーペルソナを作成する。
Creates detailed user personas from research data to guide product design, feature prioritization, marketing messaging, and team alignment.
Generates 2-4 user personas from research data with demographics, goals, frustrations, behaviors, scenarios, and design implications for UX design teams.
Generates user journey maps across 5 phases for multiple user types using 6 agent teams, with research, Markdown outputs, cross-analysis, dev roadmaps, and Pencil visualizations.
Share bugs, ideas, or general feedback.
5つの専門エージェントがディスカッション型でチーム議論し、UX/マーケティング向けのユーザーペルソナを作成する。 data-critic がライブモデレーターとして矛盾検出・収束判定を行い、品質を担保する。 コンテキストファイルで過去のセッションを引き継ぎ、反復的にペルソナを改善できる。
Step 1: ヒアリング（必須情報 + 調査設定の合意）
Step 2: チーム作成・エージェント起動
Step 3: Phase 1 ディスカッション → Gate 1 → Phase 2 ディスカッション → Gate 2
Step 3.5: ファイル書き込み検証
Step 4: 最終レポート作成
Step 5: ユーザーへの最終報告
Step 6: クリーンアップ
.claude/persona-creation/{YYYY-MM-DD}_{project}/
├── context.md <- 全体コンテキスト（プロダクト情報・学びの蓄積）
├── SUMMARY.md <- 全ラウンドを横断するサマリー
├── personas/
│ ├── persona-01.md <- ペルソナプロファイル
│ ├── persona-02.md
│ └── ...
└── round-{N}/
├── context.md <- このラウンドの目的・制約
├── log.md <- このラウンドの議事録
├── segments.md <- ユーザーセグメントと評価結果
├── research-data.md <- リサーチデータ（出典付き）
├── bias-review.md <- バイアスレビュー結果
└── critique.md <- data-critic の Gate 結果・検証記録
AskUserQuestion でユーザーから情報を収集する。不明な項目は推測せず必ず質問する。
AskUserQuestion で以下を確認:
「作業の進め方を確認させてください」
TeamCreate で persona-creation チームを作成。以下5エージェントを 1つのメッセージで並列に Agent ツールで起動する。
| name | 役割 | 主な手段 |
|---|---|---|
persona-architect | ペルソナ設計・セグメント定義・JTBD フレームワーク策定 | 分析 |
user-researcher | 市場調査・ユーザー行動リサーチ・データ裏付け | WebSearch |
persona-writer | ペルソナナラティブ・プロファイル執筆 | Write/Edit |
bias-reviewer | バイアス・ステレオタイプ・多様性チェック | 分析 |
data-critic | ライブモデレーション・矛盾検出・Gate 運営・コンテキスト管理 | WebSearch/Write |
各エージェントは agents/ ディレクトリにサブエージェントとして定義済み。
TaskCreate で以下を作成:
Phase 1（初回に全て作成）:
1. data-critic: コンテキストファイルの初期作成 + モデレーション開始
2. persona-architect: セグメント設計・JTBD フレームワーク策定（addBlockedBy: ["1"]）
3. user-researcher: 市場・ユーザー行動リサーチ（addBlockedBy: ["1"]）
- リサーチ結果を round-01/research-data.md に書き出す
4. bias-reviewer Phase 1: セグメントのバイアスチェック（addBlockedBy: ["1"]）
5. Gate 1: セグメント確定 + ユーザー確認（addBlockedBy: ["2","3","4"]）
- data-critic が Gate 合意形成を主導。チームリーダーはユーザーへの中継を担当
Phase 2（Gate 1 PASS 後にチームリーダーが作成）:
6. persona-writer: ペルソナプロファイル執筆
- セグメント確定後すぐに執筆開始。リサーチデータは届き次第取り込む
7. Gate 2 + 統合レポート（addBlockedBy: ["6"]）
- data-critic が Devil's Advocate + Independent Validation を運営
重要: タスク 6-7 は Gate 1 PASS 後に TaskCreate で追加する。初回に全て作らない。
subagent_type: "persona-architect" # agents/ で定義済み
team_name: "persona-creation"
mode: "bypassPermissions"
run_in_background: true
プロンプトに含める情報（全エージェント共通）:
init.sh が出力する絶対パスをそのまま使う
/Users/babashunsuke/.claude/persona-creation/2026-02-21_miravy/.claude/... のような相対パスは動作しないpersona-01.md, persona-02.md, ... のゼロ埋め2桁。persona-1.md 形式は禁止）[チームリーダーへ] ❓ 形式で SendMessage すること全フェーズで以下の3ステップサイクルを繰り返す。data-critic がライブモデレーターとして常時監視する:
┌─────────────────────────────────────────────────┐
│ Step A: 独立調査・設計 │
│ persona-architect がセグメントを設計 │
│ user-researcher が WebSearch で市場調査 │
│ bias-reviewer がセグメントをレビュー │
│ data-critic が全メッセージを監視・矛盾を検出 │
│ │
│ Step B: 共有 + 批判 │
│ 各エージェントが主要発見を SendMessage で全員に共有 │
│ 他エージェントが矛盾・疑問を指摘（批判テンプレート） │
│ data-critic が議論を促進・矛盾をフラグ │
│ │
│ Step C: 防御 / 修正 + 追加調査 │
│ 批判を受けたエージェントが根拠を提示して防御 │
│ または追加調査・修正してファイルを更新 │
│ data-critic が収束条件をチェック │
│ │
│ → data-critic が収束を宣言するまで Step B-C を繰り返す│
└─────────────────────────────────────────────────┘
[CHALLENGE] → {対象エージェント名}
主張: {相手の主張を要約}
問題: {矛盾・疑問の具体的内容}
根拠: {自分のデータ/ロジック}
提案: {修正案 or 追加調査すべき点}
[DEFEND] ← {批判元エージェント名}
批判: {受けた批判の要約}
回答: {根拠を提示して防御 / 批判を受け入れて修正}
修正: {ファイルを修正した場合の変更点}
✅ 全エージェントの主要発見が共有済み
✅ 全ての [CHALLENGE] に対する [DEFEND] が完了
✅ 新しい批判が2巡連続で出なくなった
✅ 未解決の矛盾が明示的に記録されている
→ data-critic が収束を宣言し、Gate に進む
persona-architect、user-researcher、bias-reviewer が並列起動。data-critic が並行してモデレーション。
[persona-architect]
→ 全員に: ユーザーセグメント案（3〜5セグメント）+ JTBD 定義を送信
→ user-researcher: 「各セグメントの市場規模やトレンドを調査してください」
→ bias-reviewer: 「セグメント設計のバイアスチェックをお願いします」
[user-researcher]
→ persona-architect に: リサーチ結果・データ裏付け（データ信頼度スコア付き）
→ データがセグメント仮説を否定する場合: [CHALLENGE] テンプレートで指摘
→ 全員に: 市場トレンド・ユーザー行動データ（ファイル出力 + 要約メッセージ）
[bias-reviewer]
→ persona-architect に: セグメント設計のバイアスチェック結果（即座に）
→ 問題があれば [CHALLENGE] テンプレートで指摘
[data-critic]（ライブモデレーション）
→ 矛盾検出: エージェント間の主張が矛盾していたら即座に全員にフラグ
→ 議論促進: 異論が出ていない主張にも根拠を問う
→ 議事録を log.md にリアルタイム記録
→ 収束条件チェック → 収束宣言
主要なディスカッション軸:
persona-architect ←→ user-researcher（セグメント仮説 vs リサーチデータ）
persona-architect ←→ bias-reviewer（セグメント設計のバイアス）
user-researcher ←→ bias-reviewer（リサーチデータ自体のバイアス）
data-critic → 全員（矛盾検出・議論促進・収束判定）
data-critic が収束を宣言したら、以下の流れで進行:
[全員へ] Gate 1: セグメント合意確認
以下のセグメント案で合意しますか？
（セグメント一覧を提示）
→ 各自、合意/反対/修正案 を SendMessage で回答してください。
PASS/FAIL 基準:
| 基準 | PASS 条件 |
|---|---|
| セグメント数 | 3〜5個 |
| データ裏付け | 各セグメントに Tier 1 or 2 のデータあり |
| バイアスチェック | bias-reviewer スコア B 以上 |
| エージェント合意 | 3/4 以上が合意 |
| MECE | セグメント間の重複なし |
[チームリーダーへ] Gate 1 結果: {PASS/FAIL}
{合意サマリー・投票結果・残存リスク}
→ ユーザーへの中間報告をお願いします。
## Gate 1: セグメント案の中間確認
### 提案セグメント一覧
（セグメント名 + 定義 + JTBD + 推定規模 + プロダクトとの関係を表形式で）
### 採用の根拠
（なぜこのセグメントを選んだか。データに基づく説明）
### 検討して棄却したセグメント案
（何を検討してなぜ採用しなかったか）
### リサーチデータサマリー
（主要なデータポイントと出典、データ信頼度スコア）
### バイアスチェック結果
（主な指摘と対応状況）
### ディスカッションの論点
（主要な [CHALLENGE]/[DEFEND] とその結論）
### 不確実な点
（自信度が低い判断は正直に明記）
AskUserQuestion: 「セグメント案が出揃いました。このまま進めますか？」
調査設定が「一気に最後まで」の場合は自動で Phase 2 に進む。
Gate 1 PASS 後、persona-writer を起動。他エージェントが並行してサポート。data-critic が引き続きモデレーション。
[persona-writer]
→ セグメント確定後すぐに執筆開始（リサーチデータは届き次第取り込み）
→ 1体完成ごとに全員に共有
[user-researcher]
→ persona-writer に: セグメント別の詳細データをプロアクティブに提供
→ ペルソナのデータ整合性チェック（年齢・職業・収入の組み合わせが現実的か）
[bias-reviewer]
→ 1体完成ごとにストリーミングレビュー → persona-writer に [CHALLENGE] or フィードバック
→ インターセクショナリティ（交差性）チェックも実施
[persona-architect]
→ 1体完成ごとにフレームワーク準拠チェック → persona-writer にフィードバック
[data-critic]（ライブモデレーション継続）
→ ペルソナ間のデータ整合性を監視
→ 年齢×職業×収入の非現実的な組み合わせを検出してフラグ
→ bias-reviewer スコア C 以下のペルソナに注意喚起
全ペルソナが揃ったら、data-critic が Gate 2 を主導:
[全員へ] 🎭 Devil's Advocate ラウンド開始
全ペルソナに対して「このペルソナはなぜ現実的でないか」「このセグメント設計のどこが甘いか」を
批判的な視点で指摘してください。テンプレートで送信してください。
各エージェントが以下テンプレートで提出:
[DEVILS_ADVOCATE]
対象: {ペルソナ名 or セグメント名}
批判: {なぜ問題か}
根拠: {データ/ロジック}
最悪シナリオ: {この批判が正しければ何が起きるか}
深刻度: Fatal / Major / Minor
data-critic がまとめて処理:
data-critic が自ら WebSearch で以下を独立検証:
| 基準 | PASS 条件 |
|---|---|
| Fatal 指摘 | 全て解消済み |
| ペルソナ品質 | 全ペルソナに bias-reviewer B 以上 |
| データ裏付け | 各ペルソナの主要属性に出典あり |
| 独立検証 | 重大な矛盾なし |
FAIL の場合は修正指示 → 再検証（最大2回。3回目の FAIL は「Low Trust」として受け入れ、レポートに明記）。
チームリーダーは、エージェントの議論をユーザーのメインチャットにリアルタイムで中継する。
中継のタイミング:
中継のフォーマット:
## {エージェント名} の {作業名}
### 結論
（何を決めたか）
### 思考プロセス
- 検討した選択肢: A, B, C
- A を採用した理由: ...
- B を棄却した理由: ...
- 根拠となったデータ: ...
### 不確実な点
（自信度が低い判断は正直に明記）
エージェントが判断に迷ったとき、チームリーダーへ質問を委ねる。
エージェントからのリクエスト形式:
[チームリーダーへ] ❓ 判断を仰ぎたい点があります:
質問: {具体的な質問}
選択肢A: {案A}
選択肢B: {案B}
推奨: {推奨案とその理由}
→ ユーザーへの確認が必要であれば、お願いします。
チームリーダーは内容に応じて自己判断するか、AskUserQuestion でユーザーに確認する。
[全員へ] ⚠️ 緊急: {問題の概要}
理由: {具体的理由}
→ {対応すべきエージェント}: {具体的なアクション}を実施してください。
各エージェントはデータ不足を検知したらチームリーダーに「Tier {N} で進行します」と報告する。 チームリーダーはユーザーにフォールバック状況を共有する。
全エージェントのタスクが completed になった後、最終レポート作成の前に以下を検証する。テンプレートのままや空のファイルは「書き込み失敗」と判断する。
# 検証対象ファイル（全て実体があること）
.claude/persona-creation/{date}_{project}/
├── context.md <- data-critic が書き込み
├── SUMMARY.md <- data-critic が書き込み
├── personas/
│ ├── persona-01.md <- persona-writer が書き込み（内容があること）
│ ├── persona-02.md
│ └── ...
└── round-01/
├── context.md <- data-critic が書き込み
├── log.md <- data-critic が書き込み
├── critique.md <- data-critic が書き込み
├── segments.md <- persona-architect が書き込み
├── research-data.md <- user-researcher が書き込み
└── bias-review.md <- bias-reviewer が書き込み
検証手順:
personas/*.md のファイル数を確認（期待するペルソナ数と一致するか）全ファイルを Read で全文読み込み、PERSONAS_REPORT.md に統合する。テンプレートは references/report-template.md を参照。
重要: 数字だけのサマリー表は不十分。各判断に「なぜそう考えたか」の根拠を必ず添える。
最終レポート作成後、ユーザーとの対話で改善点が見つかった場合に実施する追加ラウンド。 チームを再起動せず、チームリーダーが直接ペルソナファイルを Edit で修正する。
PERSONAS_IMPROVEMENT_TODO.md（プロジェクトルート）にリスト化するround-01/improvement-log.md に記録| カテゴリ | 例 |
|---|---|
| セクション追加 | 代替手段、乗り換えシナリオ、無料→有料の転換点 |
| 解像度向上 | 特定セグメントの具体的つまずきポイント、チャネル追加 |
| データ統合 | 市場トレンド（例: コンテキストエンジニアリング）のペルソナへの反映 |
| 成長パス | セグメント間の移行ジャーニーの具体化 |
| インタビューガイド | 仮説検証用の質問リスト作成 |
## TODO {N}: {改善テーマ} ✅
### {ペルソナ名}
**変更箇所**: {セクション名}
- {具体的な変更内容}
**根拠**: {なぜこの改善が必要だったか}
統合レポート完成後、チームリーダーは全ソースファイルを Read し、根拠と思考プロセスを含む詳細な最終報告をユーザーに直接提示する。
提示する最終報告の構成:
## 最終レポート
### 1. 作成ペルソナ一覧
- 名前 / セグメント / 年齢 / 職業 / プロダクトとの関係 / データ信頼度の表
### 2. セグメント設計
- 採用セグメントと根拠（データ裏付け付き）
- JTBD（Jobs-to-be-Done）定義
- 検討して棄却した案とその理由
- ディスカッションの主要論点（どこで合意し、どこで意見が分かれたか）
### 3. リサーチデータサマリー
- 主要データポイントと出典
- データ信頼度スコア（High/Medium/Low）
- データ不足があった場合のフォールバック状況
### 4. 各ペルソナの概要と設計意図
（1体ごとに：キャラクター概要 + なぜこの人物像にしたか）
### 5. バイアスレビュー結果
- 個別スコア（A/B/C/D）と主な指摘
- 全体の多様性評価
### 6. データ品質評価
- 領域別信頼度スコア（data-critic 評価）
- Tier 2/3/4 で進行した領域の詳細
### 7. Devil's Advocate の結果
- 主要な批判とその対処
- 残存リスク（Major 以上）
### 8. Independent Validation の結果
- data-critic の独立検証で発見した点
### 9. 活用ガイド
- UXデザイン / マーケティング / プロダクト開発での具体的な活用方法
### 10. 次のステップ
AskUserQuestion: 「ペルソナが完成しました。次のステップについて相談させてください。」
shutdown_request を送信TeamDelete でチーム削除bash scripts/init.sh <project-name>
# 例
bash scripts/init.sh miravy
# -> .claude/persona-creation/2026-02-20_miravy/ を作成
bash scripts/new-round.sh <project-dir>
# 例
bash scripts/new-round.sh ~/.claude/persona-creation/2026-02-20_miravy
# -> round-02/ を作成