agentforce-persona-generate

エージェントのペルソナ設計

使い方

このスキルでは、Salesforce Agentforce の AI エージェントのペルソナを設計します。4つの順序立てられたフェーズ（DRAFT → REFINE → SCORE → ENCODE）を進めながら、DRAFT の後であればいつでも実行できる5つの分岐（NAME、FILL OUT、ADJUST、CHECKLIST、WORKSHOP）を利用できます。

生成されるもの：

• ペルソナドキュメント（persona/[agent-name]/persona.md） — エージェントの人物像、話し方、決してしないこと
• ダイアログのサンプル（persona/[agent-name]/sample-dialog.md） — ペルソナの実際の例
• 要望に応じた評価レポート（persona/[agent-name]/evaluation.md） — 100点満点の評価基準、ギャップ分析、推奨事項
• 要望に応じた完全性チェックリスト（persona/[agent-name]/checklist.md） — 記入済みの項目と不足している項目
• 要望に応じたワークショップの概要（persona/[agent-name]/workshop-outline.md） — 関係者への質問、次元カード
• 要望に応じたエンコード成果物 — 有効な Agent Script の .agent ファイル、または Agentforce Builder のフィールド値

セッションの再開： フェーズの途中で中断しても、進捗は会話内に保持され、再開できます。

このスキルを使う場面

• 新しい Agentforce エージェントを設計し、構築前に性格を定義する必要がある場合（グリーンフィールド）
• 既存の .agent ファイルでペルソナの一貫性を監査する場合（ブラウンフィールド）
• ブランドガイドラインを構造化されたペルソナに変換する場合
• 設計に関する意見を集めるための、関係者向けワークショップの概要を作成する場合
• 開発前に、エージェントの話し方についてチーム間の認識をそろえる場合

対象範囲の境界： このスキルで定義するのは、エージェントが「誰であるか」です。ダイアログフロー、サブエージェント、アクション、ルーティング、変数は定義しません。これらはエージェント設計の対象です（agentforce-generate を使用してください）。ユースケース A のエンコード出力では、これらの構造にプレースホルダーを含む .agent のスケルトンが生成されます。ユーザーが内容を入力してください。

フレームワークのリファレンス

フレームワーク全体については、references/persona-framework.md を参照してください。次の項目が定義されています。

• アイデンティティ — 中核となる形容詞3～5個＋ネガティブ・アイデンティティ（キャラクターのアンチパターンを2つ以上）
• 14の次元（ペルソナ化＋表現に関する13の次元）：
  • ペルソナ化 — 話すシステム／なじみのあるもの／パーソナルアシスタント
  • レジスター — 従属者／対等な相手／アドバイザー／コーチ
  • 声 — フォーマルさ、親しみやすさ、個性の強さ、読解レベル
  • トーン — 感情的な色合い、共感の度合い（＋トーンの境界、トーンの柔軟性）
  • 伝え方 — 簡潔さ、ユーモア
  • チャットスタイル — 絵文字、書式、句読点、大文字・小文字の使い分け
• ペルソナの成果物 — アイデンティティ（特性＋ネガティブ・アイデンティティ）、表現（トーンの境界＋使用禁止表現＋ガードレール）、言い回し（フレーズ集＋談話標識＋語彙）
• トーンの柔軟性 — 文脈に応じたトーンの変化（サブエージェントごとの調整を含む）
• 語彙 — グローバルおよびサブエージェントごとの語彙（変更不可の用語を含む）
• ガードレール — コンテンツレベルの境界（例：「医療上のアドバイスをしない」）。使用禁止表現とは別のものです。

属性は依存関係の順に並んでいます。アイデンティティ → ペルソナ化 → レジスター → 声 → トーン → 伝え方 → チャットスタイルです。制約に関する注記では自然な組み合わせを推奨していますが、どのような組み合わせも有効です。

このスキルが参照する外部情報源の出典は、references/attributions.md に記載されています。

DRAFT前のトリアージ — グリーンフィールドか、ブラウンフィールドか？

**何よりも先に、**ユーザーにどちらの進め方かを尋ねます。この2つの進め方は、その後の手順が大きく異なります。

ようこそ。このスキルの使い方は2通りあります。

1. 新規に開始する — ブランド情報、対象ユーザーの詳細、チャネルをもとに、ペルソナをゼロから設計します。グリーンフィールド。
2. 既存のエージェントを監査する — すでにある.agentファイルを確認し、改善します。ブラウンフィールド。

どちらにしますか？

状態にmodeフラグを設定します：greenfieldまたはbrownfield。

ブラウンフィールドのトリガー：

• ユーザーが.agentファイルをアップロードする → scripts/parse_agent_yaml.pyを使って読み込みます（読み取り専用）
• ADJUSTスポークをすぐに利用できます（サブエージェントとアクションが存在します）
• SCOREではサブエージェントごと、およびアクションごとのサブスコアリングを行います
• ENCODEでは、注釈付きの新規ファイル案と差分の概要を生成し、構造を決して捏造しません

グリーンフィールドのトリガー：

• ENCODEでは、サブエージェント／アクション／ルーティング用のプレースホルダーを含む、スターター用.agentのスケルトンを生成します
• ADJUSTスポークは最初は利用できません（ユーザーが後からサブエージェントを宣言した場合にのみ提示されます）

---

アーキテクチャ：フェーズとスポーク

フェーズは順番に進みます。順序が重要です。スポークはハブを取り囲み、DRAFT後はいつでも、任意の順序で利用できます。各フェーズまたはスポークを終了するたびに、ハブが表示されます。

SEQUENCED PHASES (linear pipeline):
  DRAFT → REFINE → SCORE → ENCODE
                          ↑
              (loop back via phases or spokes if SCORE finds gaps)

SPOKES (radiate from the HUB; any time after DRAFT):
  ⊙ NAME              — pick or confirm the agent's name
  ⊙ FILL OUT          — phrase book, never-say, lexicon, immutable content
  ⊙ ADJUST            — subagent + action persona calibrations (gated)
  ⊙ CHECKLIST         — "What's filled in?" — completeness gap analysis
  ⊙ WORKSHOP          — stakeholder workshop outline

HUBは次に進むデフォルトの選択肢を提案しますが、直前に終了したフェーズやスポークを再実行することも含め、ユーザーはどれでも選択できます。

---

PHASE 1 — DRAFT

DRAFTでは「小さく始める」を適用し、ディメンションより先にIdentity Traitsに取り組みます。ユーザーは「小さく始める」のチェックポイント後にDRAFTを終了し、後からスポーク経由で戻ることも、DRAFTに再度入ることもできます。

Step 1: Input

どのような入力からでも開始できます。判別の質問はせず、ユーザーが提供するものをそのまま受け入れます。

受け付ける入力：

• ブランドガイドまたはトーン・オブ・ボイスのドキュメント（PDF、テキスト）
• 組織のURL
• 以前のペルソナドキュメント（前のセッションのpersona.md）
• 自由記述の説明（例：「クロコダイル・ダンディーのような話し方をする営業コーチ」）
• 既存のエージェントシステムプロンプトまたは.agentファイル（ブラウンフィールドモード）
• 任意の組み合わせ

ユーザーが何も提供しない場合：

「始めるための情報を共有してください。ブランドガイド、URL、またはご自身の言葉によるエージェントの説明だけでもかまいません。」

Step 2: コンテキスト（必須項目）

次の4項目は必須です。

1. チャネル — 必ず1つだけ選びます。

   • Webチャット（テキスト）
   • モバイルチャット（テキスト）
   • SMS（テキスト — 短文、文字数制限あり、リッチテキストなし）
   • メール
   • 電話（電話での音声 — 音声の選択、AIであることの明示、書式設定の抑制）
   • 音声対応マルチモーダル（チャットUIに加えてエージェントが発話）
   • 埋め込み型／アプリ内
   • その他（自由記述）

   チャネルによって、簡潔さのデフォルト設定（SMS → 簡潔、電話 → コンパクト、Web／モバイルチャット → 標準、メール → 詳細）とリッチテキスト機能が制約されます。複数チャネル＋動的ペルソナはロードマップ項目です。このバージョンでは、チャネルは1つです。

2. 会社／ブランド — 入力から抽出するか、質問します。どのような組織で、何をしているのかを確認します。

3. 対象者 — エージェントの対象者を確認します。従業員、顧客、パートナー、または複数です。

4. ユースケースを1つ以上 — REFINE のサンプルダイアログを作成するために必要です。ユーザーが1つしか挙げられない場合は、それで十分です。

条件付きのコンテキスト — 各ルールを適用し、条件に該当する場合にのみ質問します。

• 主な言語 — 入力から使用言語が明示されておらず、推測もできない場合は質問します（敬語の基準に影響します）。
• ビジネス目標＋成功指標 — 入力に目標や指標が含まれていない場合は、1つ尋ねます（積極性、文体、共感の度合いに役立ちます）。
• 法務／コンプライアンス — 入力に医療、金融、保険、法律、その他の規制対象分野への言及がある場合、または法務チームが作成したような文言が含まれている場合は、regulated_industry = true に設定し、法務／コンプライアンス上の制約について質問します。

収集しない項目： サブエージェント、アクション、ルーティング構造、エージェント名（NAME は独立したスポークです）。

仮のタイトルの検出： ユーザーが入力内でエージェントを仮のタイトル（「見積もりエージェント」「Flex 2.0」など）で呼んでいる場合は、これを状態の display_name_placeholder として保存します。NAME スポークでは、これをデフォルトとして使用します。

質問する前に抽出： 質問する前に、入力からコンテキストの手がかりを解析します。「Buc-ee's 向けの社内営業コーチを設計する」という入力には、対象者（社内）、役割（営業コーチ）、ブランドがすでに含まれています。再度質問しないでください。

Step 3: アイデンティティ特性＋ネガティブアイデンティティ

このステップが、まず小さく始めるための基盤です。次を作成します。

• アイデンティティ特性 — 行動の定義を添えた形容詞を3～5個（例：「落ち着いている：ユーザーが感情的になっても、感情をあおらない」）
• ネガティブアイデンティティ — 性格レベルのアンチパターンを2～4個（例：「営業担当者ではない：押し売りせず、適したものを勧める」）

アイデンティティ特性が、以降のすべての基盤となります。

スタート・スモール・チェックポイント（明示的に、声に出して伝える）

アイデンティティ特性とネガティブアイデンティティが確定したら、現状のままペルソナ文書をディスクに書き込み、ここで中断できることを伝えます。

「最小限のペルソナを作成するには、これで十分です。現時点で含まれている内容は次のとおりです。

• アイデンティティ： [traits]
• ネガティブアイデンティティ： [anti-patterns]
• チャネル： [channel]
• 会社／対象者： [values]
• ユースケース： [first use case]

擬人化と残りの項目に進みますか？ それともここで止めて、ハブから選びますか？」

ユーザーがここで止めた場合、各項目にはアイデンティティとチャネルに基づくフレームワークのデフォルトが適用されます。ペルソナ文書はディスク上に保存されているため、ユーザーは作成済みの内容を正確に確認できます。

ステップ 4：擬人化（第14の次元）

擬人化はアイデンティティの直後に設定します。以降の各次元が、キャラクター性を表現するのか、取引的な対応を行うのかを決定します。

位置	説明	影響する項目
対話システム	機能的で予測可能であり、キャラクター性はありません。背景に溶け込みます。ATM、発券キオスク、取引サービスなどです。	読解レベルは低め、ユーモアはなし、パーソナリティの強さは控えめ、代名詞は「そのエージェント」またはブランド名のみです。
親しみやすい存在	認識しやすいタイプのヘルパーで、個性は控えめです。「サービスエージェント」「コーディングアシスタント」などです。	パーソナリティの強さは中程度、代名詞は「私」＋名前でもかまいません。
パーソナルアシスタント	認識しやすい声を持つ、個性のある名前付きエージェントです。一人称で話し、アイデンティティの特性が表れます。	パーソナリティの強さは控えめまたは大胆、代名詞は通常「私」＋名前です。

アイデンティティ特性から候補を自動提案し、ユーザーが確定または変更します。

ステップ 5：残りの次元

依存関係に沿って進めます：レジスター → 声（フォーマルさ、温かさ、パーソナリティの強さ、読解レベル）→ トーン（感情的な色合い、共感レベル＋トーンの境界、トーンの柔軟性）→ 伝え方（簡潔さ、ユーモア）→ 会話スタイル（絵文字、書式、句読点、大文字・小文字の使い分け）。

簡潔さのデフォルトはチャネルに応じて設定します — SMS → 簡潔、電話 → 要点を絞る、ウェブ／モバイルチャット → 標準、メール → 詳細。強いシグナルがある場合にのみ変更します。

各次元について：

1. 入力シグナルに基づいて事前入力します
2. 確信度を示します（strong ＝ 入力からの強いシグナル、マーカーなし ＝ デフォルト）
3. 選択肢の全範囲と推奨位置を表示します

ステップ 5 の最後に生成します：

• フレーズ集 — 該当する各カテゴリにつき2～4個のフレーズ（了承、肯定、誤りへの謝罪、話題からの誘導、歓迎、談話標識。条件付き：外部向けの場合はエスカレーション／引き継ぎ、励ます色合いの場合は進捗の称賛、コーチのレジスターの場合は学びの機会、ユーモアが「なし」以外の場合はユーモアの例）
• 使用禁止リスト — 5項目以上（チャットボット特有の水増し表現＋レジスター違反＋認知処理を示す表現＋ペルソナ固有の表現）
• トーンの境界 — エージェントが決してどのような口調になってはいけないか
• トーンの柔軟性 — 基準となるトーン＋きっかけ＋変化のルール
• グローバル用語集 — どこでも使用するブランド名、製品名、業界用語。編集可能なものと変更不可のものを区別します。
• ガードレール — 内容に関する境界。分野に応じて含めます（「医療上の助言をしない」など）。使用禁止リストとは区別します。
• 価値観 — ユーザーが明示した場合にのみ含めます。決して推測しません。

全体に適用される逐語的なガードレール： デザイナーが変更不可と指定した内容（法的免責事項、ブランドが定義した用語など）は決して変更しません。フレーズ集の項目または用語集の用語が変更不可の内容と矛盾する場合は、変更不可の内容を優先します。

DRAFT 終了時

ペルソナ文書がディスクに保存されています。状態には以下が含まれます：

• モード（greenfield/brownfield）
• チャネル
• 会社、対象者、ユースケース
• アイデンティティ特性、ネガティブ・アイデンティティ
• 擬人化＋13の次元（入力済みまたはデフォルト設定）
• 確信度の注釈
• フレーズ集、使用禁止リスト、トーンの境界、トーンの柔軟性、用語集
• ガードレール（該当する場合）、価値観（明示されている場合）、変更不可のコンテンツブロック
• display_name_placeholder（入力から検出された仮の名称）
• name_decision: pending

HUB を表示します。

---

PHASE 2 — 改善

会話例を生成し、ユーザーが反復して改善できるようにします。

会話例の生成

シナリオの種として、DRAFT のステップ 2 で取得したユースケースを使用します。以下の条件を満たすやり取りを3～5件生成します：

• ペルソナの特徴を実際の応答で示す（語彙の選択、トーン、簡潔さ、ユーモア、書式）
• 少なくとも1つ、エラー、確認、感情的な場面などの「興味深い」やり取りを含める。順調なケースだけにしない
• ペルソナの影響がはっきり伝わるようにする。どのエージェントも「こんにちは！今日はどのようにお手伝いできますか？」とは言いません

音声／電話チャネルの場合は、AI の開示を含むウェルカムメッセージから始め、ユーザーがその内容を文脈の中で確認できるようにします。

洗練ループ

サンプルのダイアログを提示した後、次のように案内します。

「変更したい点を教えてください。「もっと温かみを持たせて」「ユーモアを控えて」「それは言わないで」など、または次から選んでください。

• よさそうです — ハブに戻る
• 別のシナリオを試す
• （いつでも自由入力できます）」

ユーザーが自然言語で調整内容を入力したら、references/refinement-mappings.md の対応表を使って適用します（例：「温かみを持たせて」→ Warmth +1、必要に応じて Empathy +1 も検討）。変更を単一軸に保ったままサンプルを再生成し、再提示します。曖昧な場合は主となる対応を適用し、変更内容を説明して、ユーザーが修正できるようにします。

差分ベースの再生成 — 単一の次元を変更した後：

1. 変更内容を明示します。「Warmth：Warm → Cool」
2. 変更していない次元はすべて一定に保ちます
3. 変更した次元のみを変化させて、サンプルのダイアログを再生成します
4. 何が変わったかを説明します

対照的な応答の比較 — ユーザーからの依頼（「このエージェントの応答例を2パターン見せて」など）があった場合、記録済みのユースケースからユーザーの発話を1つ作成し、1つの次元または特性（複数の軸ではありません）を変えた、対照的なエージェントの応答を2つ生成します。ユーザーの選択に基づいて状態を更新します。

REFINE の終了

サンプルのダイアログを persona/[agent-name]/sample-dialog.md に保存します。次元に変化があった場合は、ペルソナドキュメントを更新します。HUB を提示します。

---

PHASE 3 — SCORE — 「どのくらい優れていますか？」

100点満点の評価基準を適用します。開始方法は2つあります。

1. 設計済みペルソナ（DRAFT/REFINE から引き継いだ状態）
2. 既存のエージェント指示（ブラウンフィールドモード — .agent ファイル、システムプロンプト、トピックの指示、またはそれらの組み合わせ）

**重要な原則：**フレームワークの用語を使っているかどうかではなく、内容を評価します。「パーソナリティのガイドライン」＝Identity。「コミュニケーションのルール」＝dimensions。「禁止フレーズ」＝Never-Say。まず対応付けてから、評価します。

ブラウンフィールド抽出

ブラウンフィールドモードでは、scripts/parse_agent_yaml.py を使って .agent ファイルを読み取り専用で解析します。次の項目を確認します。

• system.instructions、system.messages.welcome、system.messages.error
• 各サブエージェント：name、instructions、reasoning_instructions、system_override
• 各アクション：name、progress_indicator_message

ラベルではなく内容に基づいて対応付けます。推測による対応付けには、「推測 — [source label]」と記します。フレームワークの概念がないからといって、スコアがゼロになるわけではありません。存在する内容を評価します。一般的なラベルと項目の対応表は references/scoring-rubric.md にあります。

100点満点の評価基準

references/scoring-rubric.md の100点満点の評価基準を適用します。11の評価カテゴリ、ブラウンフィールドにおけるサブエージェントごと／アクションごとのサブ評価ルール、パーセンテージ区分（90-100：本番環境に対応、75-89：強固な基盤、50-74：要修正、<50：重大な不足）が含まれます。用語ではなく、内容を評価します。

推奨事項（必須の出力）

明らかになった各不足について：

• 関連するフレームワークのセクションを示します
• 具体的で実行可能な修正案を提示します
• ブラウンフィールドの場合：ソースファイル内の場所（サブエージェント名、行範囲）を示します

SCORE の終了

評価結果を persona/[agent-name]/evaluation.md に保存します。合計はパーセンテージで提示します（90-100：本番環境に対応、75-89：強固な基盤、50-74：要修正、<50：重大な不足）。HUB を提示します。次のステップとして、不足がある場合は FILL OUT または ADJUST、スコアが基準を満たしている場合は ENCODE を提案します。

---

PHASE 4 — ENCODE

Agent Script（デフォルト）または Agentforce Builder 用の、有効なエンコーディング出力を生成します。

事前確認：NAME

name_decision がまだ pending の場合は、ENCODE を一時停止し、まず NAME スポークにユーザーを案内します。 理由：Agent Script の config.agent_label は必須です。プレースホルダーを使ってエンコードすると、作業用のタイトル（例：「the quoting agent」）が気付かれないまま引き継がれ、デプロイ前にユーザーが見落とす可能性があります。

NAME の完了後、ENCODE を再開します。

決定ツリー

1. Confirm channel (single value from state).
2. Confirm authoring tool:
   - Greenfield: default = Agent Script.
     → "Encode for Agent Script (default), or switch to Agentforce Builder?"
   - Brownfield, source is Agent Script: default = Agent Script.
     → "Stay on Agent Script (recommended)?"
   - Brownfield, source is Builder: default = Builder, but offer the upgrade path.
     → "Stay on Builder, or switch to Agent Script (recommended for per-subagent encoding granularity)?"
3. Generate comprehensive persona block (always):
   - system.instructions — full persona content
   - system.messages.welcome — in-character welcome
   - system.messages.error — in-character error
4. Subagent-level encoding? Three answers:
   - "I have subagents defined" → enumerate them, generate per-subagent reasoning.instructions
   - "I don't have subagents yet" → skip; output is global-only (Use Case A)
   - "Generate examples" → infer 2-3 plausible subagents, label as examples
5. Action-level encoding? Same three answers; generates progress_indicator_message per action.
6. Voice encoding? Only if channel is telephony or multimodal-with-audio.
   - Voice recommendations from references/voice-catalog.json
   - Per-voice fine-tuning starting points (Speed, Stability, Similarity)
   - AI disclosure in welcome message
   - Pronunciation dictionary for brand terms
7. Diff (brownfield only): annotated proposed-new-file + diff summary.

このスキルは、サブエージェント、アクション、変数、ルーティングを決して創作しません。アーキテクチャはユーザーが決定します。

作成ツール別の出力

フィールドごとの詳細なガイド（ブロックの順序、書式ルール、Builder フィールドの文字数制限、progress_indicator_message の配置、チャネルごとの調整）は、references/persona-encoding-guide.md を参照してください。運用上の要点：

• Agent Script（.agent） — forcedotcom/sf-skills/skills/developing-agentforce/ に準拠した有効な Agent Script 構文にします。新規作成の場合：最小限の有効な骨組みを出力します（ペルソナ全文とキャラクターに合ったウェルカムメッセージ／エラーメッセージを含む system、config、language、start_agent のスタブ、プレースホルダーの subagent を1つ）。ユーザーが肉付けできる、動作可能な出発点です。サブエージェント／アクション／変数／ルーティングを決して創作しないでください。既存ファイルの編集の場合：既存の構造を維持し、ペルソナに関わるフィールド（system.instructions、system.messages.welcome／error、サブエージェントごとの system:／reasoning.instructions:、アクションごとの progress_indicator_message:）のみを変更します。persona/[agent-name]/[agent-name].agent に書き込みます。
• Agentforce Builder — 設定フィールド（Name、Role＝機能の要約のみ、Company、Welcome、Error）、全体のペルソナブロック、サブエージェントごとの指示、アクションごとの読み込みテキストを入力します。Register と Formality に基づいて Tone ドロップダウンの選択を推奨し、音声／SMS チャネル向けの調整を適用します。persona/[agent-name]/builder-fields.md に書き込みます。

既存ファイル編集時の差分出力

ソースが .agent ファイルの場合、次の2つの成果物を生成します。

1. persona/[agent-name]/persona-diff.md — 注釈付きの新ファイル案。ペルソナに関わる各フィールドについて、新しい内容案とインラインの理由（「変更理由：tone-flex により、エスカレーション時の共感を高める必要があった」など）を示します。
2. 差分の概要 — 変更点とその理由を、ペルソナに関わる範囲に限定して記載する付随セクションです。統合ビューが必要であれば、ユーザーはソースに対して実際の差分ツールを実行できます。この成果物は人による確認を目的としています。

差分には、ルーティング、サブエージェントの構造、アクションの契約は明示的に含めません。

ENCODE の終了

エンコーディング成果物を書き込みました。HUB を提示してください。

---

SPOKES

Spokes は付随作業です。DRAFT の後であればいつでも、順不同で何度でも実施できます。

⊙ NAME

「このエージェントに名前を付けますか？ 名前がないほうが適しているエージェントもあります（取引サービス、会話システム、ブランドそのものがアイデンティティであるエージェントなど）。一方、固有の名前を付けるとよいエージェントもあります。このエージェントにはどちらが適していますか？」

DRAFT で仮の名前が検出されていた場合（display_name_placeholder が設定済み）：

「入力から『[working title]』という仮の名前を見つけました。この名前でよいですか？ それとも候補から選びますか？」

名前を付ける場合：

• 会話システム → それでも名前を付けたい場合は、ブランドに合った名前を提案します（例：「Acme Service Agent」）。
• 親しみやすい存在 → 機能的で発音しやすい短い候補を2～3個提示します。
• パーソナルアシスタント → アイデンティティを端的に表す候補を最大3個提示します。

フレームワークの命名原則を適用します。

• 説明的（「Service Agent」） • 印象的（「Striker」） • 覚えやすい（「Clover」） • 文化に合ったもの（「Bug Squasher」） • ブランドに合ったもの（「Lex」） • 発音しやすい（無線テストに合格する） • 人工物だと明らかなもの（「Song」「Cortana」） • 機能的（「Scripty」） • 抽象的（「Koda」「Lumi」） • なし（意図的に名前を付けない）
• アンチパターン： Tech_Assist_Agent_v2_Internal_Test のような API 形式の名前は、ペルソナ名ではありません。

名前を付けない場合：name_decision: unnamed または brand-as-name を設定します。エンコーディング内の表示名は、ユーザーの選択に応じてブランド名または null にします。

状態の更新：name_decision ∈ {named, unnamed, brand-as-name}。表示名を設定します。

⊙ FILL OUT

「FILL OUT にいます。何に取り組みますか？

• フレーズ集への追加
• 言ってはいけない表現の追加
• 語彙集への追加（全体またはサブエージェントごと）
• 変更不可の内容の指定
• この spoke を終了する （1つ選んでください。各項目の後にここへ戻るか、複数選ぶ場合は一覧にしてください。）」

各サブアクティビティでは、現在の状態を提示し、追加や編集の内容を確認します。終了時にペルソナ文書を更新します。

⊙ ADJUST

ゲート付き: サブエージェントまたはアクションが存在する場合にのみ提供されます（ユーザーによる宣言、またはブラウンフィールドモードでソースの .agent ファイルから検出された場合）。

「あなたは ADJUST にいます。何に取り組みますか？

• サブエージェントごとのペルソナ調整（例：「エスカレーションサブエージェントでは、ユーモアをゼロにする」）
• アクションごとのローディングテキスト（ボイスで）
• このスポークはこれで完了です」

サブエージェントごとの調整は、Agent Script の system: オーバーライドまたは reasoning.instructions のキャリブレーションとしてエンコードされます。 アクションごとのローディングテキストは、progress_indicator_message 文字列としてエンコードされます。

⊙ CHECKLIST — 「何が埋まっているか？」

ペルソナドキュメントを読み取り、各要素を [+] 存在、[-] 欠落、または — 該当なしとしてマークした Markdown チェックリストを生成します。定義はフレームワークから直接取得されます。

出力テンプレートは assets/checklist-template.md にあります。各推奨ネクストステップは引用可能（例：「go to NAME」「go to FILL OUT, add Lexicon」）であるため、ユーザーは入力し直すのではなく貼り付けて返信できます。

SCORE の前に素早くギャップを確認する場合や、ENCODE の前に準備状況をチェックする場合に便利です。

persona/[agent-name]/checklist.md に書き込みます。

⊙ WORKSHOP

顧客の社内ワークショップ向けに、ステークホルダーに提示するアウトラインを生成します。出力は FigJam / ホワイトボード形式をサポートします。

質問生成ポリシー（完全なルールは references/workshop-question-policy.md を参照してください）:

• レバレッジの高いものから（Identity、Personification、Register）。
• すでにわかっていることはスキップします。ブランドの入力が明確にその次元に答えている場合は、質問しません。
• 3 つのスタイル: validate（「X と想定しました — 確認するか、反論してください」）、choose between（真に異なる 2 つの立場）、open spectrum（この線上にエージェントを配置する）。

would-you-rather ペアには、references/workshop-scenario-seeds.md のシナリオシードを使用してください。

出力テンプレートは assets/workshop-outline-template.md にあります。persona/[agent-name]/workshop-outline.md に出力します。

網羅性よりも品質。 一般的な 12 個の質問よりも、優れた 4 個の質問をする方が良いです。

---

HUB

各フェーズまたはスポークの終了後に、HUB を表示します。フラットなメニューではありません — 推奨ネクストステップは、理由を添えたラベル付きの主要な推奨として、他の項目の上に表示されます。

HUB

  Suggested next:
  → [SUGGESTED] — [one-line rationale grounded in current state]

  Or do something else:
    Phases:
      → REFINE              [state-aware annotation, e.g., "re-run; iterate on dialog"]
      → SCORE               ["how good is it?"]
      → ENCODE              [gating note if name_decision pending]
    Spokes:
      ⊙ NAME                [annotation: "name_decision pending" or "current: [name]"]
      ⊙ FILL OUT            [annotation: what's empty, e.g., "Lexicon empty"]
      ⊙ ADJUST              [annotation: gated reason if not available]
      ⊙ CHECKLIST           ["what's filled in?"]
      ⊙ WORKSHOP            ["stakeholder workshop outline"]
  Exit:
    → I'm done

提案ロジック:

• DRAFT を終了した直後 → REFINE を提案
• REFINE を終了した直後 → SCORE を提案
• 合格スコアで SCORE を終了した直後 → ENCODE を提案
• 不合格スコアで SCORE を終了した直後 → FILL OUT または ADJUST を提案（表面化したギャップがより大きい方）
• name_decision: pending で ENCODE を試みた → NAME を提案し、その後 ENCODE を再開
• 各フェーズ/スポークの後 → ユーザーはいつでも何でも選択できます（終了したばかりのものを含む）

---

出力ファイル

このスキルは以下を生成します:

1. ペルソナドキュメント（persona/[agent-name]/persona.md） — DRAFT。他のフェーズ/スポークによって更新されます。
2. サンプルダイアログ（persona/[agent-name]/sample-dialog.md） — REFINE。
3. 評価レポート（persona/[agent-name]/evaluation.md） — SCORE。
4. エンコード成果物（Agent Script の場合は persona/[agent-name]/[agent-name].agent、Builder の場合は persona/[agent-name]/builder-fields.md） — ENCODE。
5. ペルソナ diff（persona/[agent-name]/persona-diff.md） — ブラウンフィールドモードの ENCODE のみ。
6. チェックリスト（persona/[agent-name]/checklist.md） — CHECKLIST スポーク。
7. ワークショップアウトライン（persona/[agent-name]/workshop-outline.md） — WORKSHOP スポーク。

persona/ はスキルリポジトリレベルで gitignore されているため、このチェックアウト内で cwd を指定してスキルをドッグフーディングしても、出力が git に漏れることはありません。その他の作業ディレクトリでは、適用したい gitignore ルールについてユーザーが責任を負います。

---

インタラクション設計ノート

サーフェス横断的な UX ガイドライン（質問より先に出力、独立した質問のバッチ処理、コンパクトなフォーマット、進捗の認識、確信度の明示）は、references/interaction-design-notes.md にあります。すべてのサーフェス — CLI、TUI、web、IDE — で適用してください。

---

クレジット

このスキルは、公開されオープンライセンスの会話設計の成果物を活用しています。references/attributions.md を参照してください。