agentforce-persona-generate

设计 Agent 人设

如何使用

此技能用于为 Salesforce Agentforce 设计 AI Agent 人设。它分四个阶段依次进行（DRAFT → REFINE → SCORE → ENCODE），并提供五个可随时在 DRAFT 之后运行的分支（NAME、FILL OUT、ADJUST、CHECKLIST、WORKSHOP）。

产出内容：

• 人设文档（persona/[agent-name]/persona.md）——Agent 是谁、说话风格如何，以及绝不会做什么
• 对话示例（persona/[agent-name]/sample-dialog.md）——展示人设的实际表现
• 按需生成的评估报告（persona/[agent-name]/evaluation.md）——百分制评分标准、差距分析、建议
• 按需生成的完整性清单（persona/[agent-name]/checklist.md）——已填写内容和缺失内容
• 按需生成的工作坊大纲（persona/[agent-name]/workshop-outline.md）——利益相关者问题、维度卡片
• 按需生成的编码产物——有效的 Agent Script .agent 文件，或 Agentforce Builder 字段值

恢复会话： 如果在某个阶段中途停止，进度会保留在对话中，可继续完成。

何时使用此技能

• 设计新的 Agentforce Agent，并需要在构建前定义其个性（从零开始）
• 审核现有 .agent 文件中的人设一致性（已有基础）
• 将品牌指南转化为结构化人设
• 生成利益相关者工作坊大纲，以收集设计意见
• 在开发前让团队就 Agent 应有的说话风格达成一致

范围边界： 此技能定义 Agent 是谁，不定义对话流程、子 Agent、操作、路由或变量——这些属于 Agent 设计（使用 agentforce-generate）。对于用例 A，编码输出会生成一个 .agent 框架，并为这些结构预留占位符；用户需自行填写。

框架参考

阅读 references/persona-framework.md 了解完整框架。其定义了：

• 身份——3–5 个核心形容词 + 负面身份（≥2 个角色层面的反模式）
• 14 个维度（拟人化 + 13 个表达维度）：
  • 拟人化——对话系统 / 熟悉的事物 / 个人助手
  • 关系定位——下属 / 同级 / 顾问 / 教练
  • 声音——正式程度、亲和力、个性强度、阅读水平
  • 语气——情绪色彩、共情程度（+ 语气边界、语气灵活度）
  • 表达方式——简洁程度、幽默感
  • 聊天风格——表情符号、格式、标点、大小写
• 人设产物——身份（特质 + 负面身份）、表达（语气边界 + 禁用表达 + 防护规则）、措辞（常用语、话语标记、词汇表）
• 语气灵活度——语气如何随情境变化（包括针对每个子 Agent 的校准）
• 词汇表——全局及每个子 Agent 的词汇，包括不可更改的术语
• 防护规则——内容层面的边界（例如“不要提供医疗建议”），与禁用表达不同

属性按依赖关系排序：身份 → 拟人化 → 关系定位 → 声音 → 语气 → 表达方式 → 聊天风格。约束说明会推荐自然的搭配；任何组合都有效。

此技能引用的外部来源信息见 references/attributions.md。

DRAFT 前分流 — Greenfield 还是 Brownfield？

**首先，**询问用户属于哪种模式。后续流程会因模式不同而显著分化。

欢迎。使用此技能有两种方式：

1. 从头开始 — 根据品牌输入、受众详情和渠道，从头设计一个 persona。Greenfield。
2. 审查现有 Agent — 审查并改进你已有的 .agent 文件。Brownfield。

你想选哪一种？

在状态中设置 mode 标记：greenfield 或 brownfield。

Brownfield 触发条件：

• 用户上传 .agent 文件 → 使用 scripts/parse_agent_yaml.py 加载（只读）
• ADJUST 分支立即可用（已有子 Agent 和操作）
• SCORE 包含按子 Agent 和操作划分的子评分
• ENCODE 生成带注释的拟议新文件和差异摘要，绝不凭空编造结构

Greenfield 触发条件：

• ENCODE 生成一个入门版 .agent 框架，其中包含子 Agent／操作／路由的占位符
• ADJUST 分支初始处于禁用状态（仅当用户之后声明有子 Agent 时才提供）

---

架构：阶段与分支

阶段按顺序进行——顺序很重要。分支围绕中枢运行，在 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

中枢会建议下一个默认选项，但允许用户选择任何选项，包括重新运行刚刚结束的阶段或分支。

---

PHASE 1 — DRAFT

DRAFT 遵循“从小处着手”的原则：先处理身份特征，再处理各个维度。用户可以在“从小处着手”检查点之后退出 DRAFT，之后通过分支返回，或重新进入 DRAFT。

步骤 1：输入

接受任意起始输入。不询问识别问题——用户提供什么都予以接受。

可接受的输入：

• 品牌指南或语气风格文档（PDF、文本）
• 组织网址
• 之前的 persona 文档（先前会话中的 persona.md）
• 自由文本描述（例如：“一位像鳄鱼邓迪那样说话的销售教练”）
• 现有 Agent 系统提示词或 .agent 文件（brownfield 模式）
• 任意组合

如果用户没有提供任何内容：

“分享一些内容即可开始——品牌指南、网址，或用自己的话描述这个 Agent。”

步骤 2：上下文（必备信息）

以下四项为必填：

1. 渠道 — 必须且只能选 一个：

   • 网页聊天（文本）
   • 移动端聊天（文本）
   • SMS（文本 — 短格式、字符数受限、不支持富文本）
   • 电子邮件
   • 电话（通过电话语音交流 — 语音选择、AI 披露、禁用格式化）
   • 多模态音频（聊天界面加 Agent 语音回复）
   • 嵌入式 / 应用内
   • 其他（自由填写）

   渠道会限制简洁度的默认设置（SMS → 简短，电话 → 精简，网页 / 移动端聊天 → 适中，电子邮件 → 详尽）和富文本功能。多渠道 + 动态角色是路线图上的项目 — 本版本只支持一个渠道。

2. 公司 / 品牌 — 从输入中提取，或向用户询问。介绍他们是谁、从事什么业务。

3. 受众 — Agent 服务的对象：员工、客户、合作伙伴或混合受众。

4. ≥1 个用例 — 用例决定 REFINE 的示例对话。如果用户只能说出一个，也足够了。

条件上下文 — 按规则逐一处理；只有满足条件时才询问：

• 主要语言 — 如果输入未明确说明或暗示工作语言，则询问（这会影响正式程度规范）。
• 业务目标 + 成功指标 — 如果输入未提及目标或指标，则询问一个（这会影响主动性、语域和共情方式）。
• 法律 / 合规 — 如果输入提到医疗保健、金融、保险、法律或其他受监管领域，或者包含看起来像法律团队撰写的措辞：将 regulated_industry = true 设为 true，并询问法律 / 合规限制。

不要收集： 子 Agent、操作、路由结构或 Agent 名称（NAME 是独立的环节）。

工作名称检测： 如果用户在输入中用工作名称指代 Agent（“报价 Agent”、“Flex 2.0”），则将其记为状态中的 display_name_placeholder。NAME 环节会将其用作默认值。

先提取，再询问： 提问前先解析输入中的上下文信号。“为 Buc-ee's 设计一个内部销售教练”已经说明了受众（内部人员）、角色（销售教练）和品牌。不要重复询问。

步骤 3：身份特质 + 负面身份

此步骤是从小处着手的锚点。生成：

• 身份特质 — 3-5 个形容词，并附带行为定义（例如：“沉着：即使用户情绪激动，也不会在情绪上升级”）
• 负面身份 — 2-4 条角色层面的反模式（“不是推销员：不会强行推销，会推荐合适的选项”）

身份特质是后续所有内容的锚点。

从小处着手检查点（明确说出来）

身份特质 + 负面身份确定后，将当前状态的角色设定文档写入磁盘，并告知用户可以在此结束：

“我们已经有足够的信息来交付一份最简角色设定。以下是目前的内容：

• 身份： [特质]
• 负面身份： [反模式]
• 渠道： [渠道]
• 公司 / 受众： [值]
• 用例： [第一个用例]

你想继续完善拟人化和其余维度，还是到此为止并从中心页选择？”

如果用户在此结束，则各维度会根据身份 + 渠道采用框架默认值。角色设定文档已写入磁盘；用户可以清楚地看到当前已有的内容。

步骤 4：拟人化（第 14 个维度）

拟人化紧接在身份之后。它决定其余维度塑造的是角色，还是事务性工作。

位置	描述	影响
对话系统	功能性、可预测，没有角色。淡出背景。ATM、售票亭、事务性服务。	阅读级别低；幽默无；个性强度内敛；代词使用“该 Agent”或仅使用品牌名。
熟悉的帮手	可识别类别的助手，略有个性。“服务 Agent”“编码助手”。	个性强度适中；代词：“我”+ 名字可接受。
个人助手	有鲜明个性、名字和可识别声音的 Agent。以第一人称交谈；体现身份特征。	个性强度内敛或鲜明；代词：“我”+ 名字为标准用法。

根据身份特征自动建议；由用户确认或覆盖。

步骤 5：其余维度

沿依赖链逐项处理：语域 → 声音（正式程度、亲和度、个性强度、阅读级别）→ 语气（情绪色彩、共情程度 + 语气边界、语气灵活度）→ 表达方式（简洁程度、幽默）→ 聊天风格（表情符号、格式、标点、大小写）。

简洁程度的默认值与渠道绑定——短信 → 简短，电话 → 简洁，网页/移动端聊天 → 适中，电子邮件 → 详尽。只有强烈信号表明有必要时才覆盖。

针对每个维度：

1. 根据输入信号预先填充
2. 标注置信度（strong = 输入中有强烈信号；无标记 = 默认值）
3. 展示完整范围和建议位置

在步骤 5 结束时生成：

• 语句库 — 每个适用类别包含 2-4 个语句（确认、肯定、为错误致歉、引导回正题、欢迎、话语衔接语；条件项：外部对象场景的升级/转交、鼓励型情绪色彩的庆祝进展、教练式语域的教学时刻、幽默 ≠ 无时的幽默示例）
• 禁用语句清单 — ≥5 项（聊天机器人填充语 + 语域违规用语 + 认知处理标记 + 特定角色用语）
• 语气边界 — Agent 绝不能表现出的语气
• 语气灵活度 — 基线 + 触发条件 + 调整规则
• 全局词汇表 — 品牌名、产品名、全局使用的行业术语。区分可编辑项和不可更改项。
• 防护规则 — 内容层面的边界；适用时应包含（“不要提供医疗建议”）。与禁用语句清单不同。
• 价值观 — 仅在用户明确提出时包含；绝不推断。

跨维度的原文防护规则： 绝不更改设计者标记为不可更改的内容（法律免责声明、品牌定义术语）。如果语句库条目或词汇表术语与不可更改内容冲突，以不可更改内容为准。

DRAFT 阶段结束

角色设定文档已保存到磁盘。状态包含：

• 模式（greenfield/brownfield）
• 渠道
• 公司、受众、用例
• 身份特征、负面身份
• 拟人化 + 13 个维度（已填写或使用默认值）
• 置信度标注
• 语句库、禁用语句清单、语气边界、语气灵活度、词汇表
• 防护规则（如有）、价值观（如明确提出）、不可更改的内容块
• display_name_placeholder（从输入中检测到的临时名称，如有）
• name_decision: pending

展示 HUB。

---

阶段 2 — 优化

生成对话示例，并让用户迭代调整。

对话示例生成

使用 DRAFT 步骤 2 中记录的用例作为场景种子。生成 3-5 轮对话，以：

• 展示角色设定的实际表现（用词、语气、简洁程度、幽默、格式）
• 至少包含一个“有意思”的回合——错误、澄清或情绪时刻，而不只是顺利流程
• 明显体现角色设定的影响——这些 Agent 都不会说“你好！今天有什么可以帮你？”

对于语音/电话渠道，从包含 AI 披露信息的欢迎语开始，让用户看到其具体呈现方式。

优化循环

展示示例对话后：

“告诉我需要改什么——‘更温暖一些’、‘去掉幽默感’、‘别这么说’——或者选择：

• 看起来不错 — 返回主菜单
• 尝试不同的场景
• （始终可以输入自由文本）”

当用户输入自然语言调整时，通过 references/refinement-mappings.md 中的映射表应用调整（例如，“warmer” → Warmth +1，同时考虑 Empathy +1），在保持单一维度变化的情况下重新生成示例，并再次展示。当意思不明确时，应用主要映射，并说明所做的更改，以便用户纠正。

基于差异的重新生成 — 单一维度更改后：

1. 明确显示更改：“Warmth：Warm → Cool”
2. 将所有未更改的维度保持不变
3. 重新生成示例对话，仅改变已更改的维度
4. 说明发生了哪些变化

对比响应 — 如果用户提出请求（“给我看看这个 Agent 有两种什么样的回复方式”），根据已记录的用例生成一句用户发言，以及两种在一个维度或特质上有所区别（而非多个维度）的 Agent 响应。根据用户的选择更新状态。

优化阶段退出

将示例对话写入 persona/[agent-name]/sample-dialog.md。如果维度发生变化，则更新 Persona 文档。显示主菜单。

---

阶段 3 — 评分 — “效果如何？”

应用 100 分制评分标准。两个入口：

1. 已设计的 Persona（来自 DRAFT/REFINE 的状态）
2. 现有 Agent 指令（棕地模式 — .agent 文件、系统提示词、主题指令或其组合）

**核心原则：**评估实质内容，而不是是否使用了框架的术语。“个性指南” = Identity。“沟通规则” = dimensions。“禁用语句” = Never-Say。先映射，再评分。

棕地提取

棕地模式下，通过 scripts/parse_agent_yaml.py 解析 .agent 文件（只读）。逐项检查：

• system.instructions、system.messages.welcome、system.messages.error
• 每个子 Agent：name、instructions、reasoning_instructions、system_override
• 每个操作：name、progress_indicator_message

按实质内容映射，而不是按标签。标记推断映射：“推断 — [来源标签]”。缺少某个框架概念 ≠ 得 0 分；根据已有内容评分。常见标签映射表位于 references/scoring-rubric.md。

100 分制评分标准

应用 references/scoring-rubric.md 中的 100 分制评分标准 — 11 个评分类别、棕地模式下针对每个子 Agent / 每个操作的子评分规则，以及百分比分档（90-100：可投入生产，75-89：基础扎实，50-74：需要修订，<50：存在重大缺口）。评估实质内容，而不是术语。

建议（必需输出）

针对发现的每个缺口：

• 引用相关的框架章节
• 提供具体、可执行的修复建议
• 对于棕地模式：引用源文件中的位置（子 Agent 名称、行范围）

评分阶段退出

将评估写入 persona/[agent-name]/evaluation.md。以百分比形式展示总分（90-100：可投入生产，75-89：基础扎实，50-74：需要修订，<50：存在重大缺口）。显示主菜单；如果存在缺口，建议下一步执行 FILL OUT 或 ADJUST；如果评分达标，则建议 ENCODE。

---

阶段 4 — 编码

为 Agent Script（默认）或 Agentforce Builder 生成有效的编码输出。

编码前检查：名称

如果 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.

此技能绝不自行编造子 Agent、操作、变量或路由。架构由用户决定。

由创作工具输出

阅读 references/persona-encoding-guide.md，了解完整的逐字段指南（区块顺序、格式规则、Builder 字段字符数限制、progress_indicator_message 的位置、渠道调整）。操作要点：

• Agent Script（.agent）——按照 forcedotcom/sf-skills/skills/developing-agentforce/ 中的要求，使用有效的 Agent Script 语法。全新项目：输出最简有效骨架（包含完整角色设定以及符合角色特点的欢迎语和错误消息的 system、config、language、start_agent 存根、一个占位 subagent）——提供一个可用的起点，由用户继续完善；绝不臆造子 Agent、操作、变量或路由。棕地项目：保留现有结构，仅修改承载角色设定的字段（system.instructions、system.messages.welcome/error、各子 Agent 的 system:/reasoning.instructions:、各操作的 progress_indicator_message:）。写入 persona/[agent-name]/[agent-name].agent。
• Agentforce Builder——填写配置字段（Name、Role = 仅功能摘要、Company、Welcome、Error）、全局角色设定区块、各子 Agent 的指令，以及各操作的加载文案；根据 Register + Formality 推荐 Tone 下拉选项；应用语音/SMS 渠道调整。写入 persona/[agent-name]/builder-fields.md。

棕地差异输出

当源文件为 .agent 文件时，生成两个工件：

1. persona/[agent-name]/persona-diff.md——带注释的拟议新文件。展示每个承载角色设定的字段及拟议新内容，并附上行内理由（“变更原因：tone-flex 要求在升级处理时加强共情”）。
2. 差异摘要——配套章节，列出变更内容及原因，仅涉及角色设定。用户如需统一视图，可对源文件运行实际差异工具；此工件用于人工审核。

差异明确排除路由、子 Agent 结构和操作契约。

ENCODE 阶段退出

编码工件已写入。呈现 HUB。

---

SPOKES

Spoke 是辅助工作，可在 DRAFT 之后的任何时间进行，顺序不限，可重复进行。

⊙ NAME

“要为这个 Agent 取名吗？有些 Agent 不取名更合适（例如事务型服务、对话系统、身份本身就是品牌的 Agent）。另一些则适合有个独特名称。这个 Agent 适合哪种？”

如果在 DRAFT 中检测到工作名称（已设置 display_name_placeholder）：

“我在你的输入中发现了‘[working title]’。确认使用，还是从建议中选择？”

如果回答是（有名称）：

• 对话系统 → 如果用户仍想取名，建议与品牌一致的名称（例如“Acme 服务 Agent”）
• 熟悉的事物 → 提供 2–3 个简短候选名称（功能明确、易于称呼）
• 个人助手 → 提供最多 3 个能凝练其身份的候选名称

应用框架中的命名原则：

• 描述性（“服务 Agent”）• 富有意象（“Striker”）• 易记（“Clover”）• 符合文化语境（“Bug Squasher”）• 与品牌一致（“Lex”）• 易于称呼（通过无线电测试）• 明显为人工命名（“Song”、“Cortana”）• 功能性（“Scripty”）• 抽象（“Koda”、“Lumi”）• 空值（刻意不取名）
• 反模式： 类似 API 的名称，如 Tech_Assist_Agent_v2_Internal_Test，不是角色名称。

如果回答否（不取名）：设置 name_decision: unnamed 或 brand-as-name。根据用户选择，编码中的显示名称设为品牌名称或 null。

状态更新：name_decision ∈ {named, unnamed, brand-as-name}。填写显示名称。

⊙ FILL OUT

“你正在进行 FILL OUT。想处理什么？

• 添加短语手册内容
• 扩充禁用表达
• 添加词汇表条目（全局或针对单个子 Agent）
• 标记不可变内容
• 结束此 spoke （选择一项；每项完成后都会返回此处，也可通过列出多项来选择多个。）”

对于每项子活动，展示当前状态并收集新增或修改内容。退出时更新角色设定文档。

⊙ ADJUST

**有条件提供：**仅在存在子 Agent 或操作时提供（由用户声明，或在棕地模式下从源 .agent 文件中检测到）。

“你正在进行 ADJUST。想处理什么？

• 调整各子 Agent 的角色设定（例如：‘在升级处理子 Agent 中，将幽默程度降为零’）
• 为各操作设置加载提示文本（语音）
• 这个分支就到这里”

各子 Agent 的调整会编码为 Agent Script system: 覆盖项或 reasoning.instructions 校准项。 各操作的加载提示文本会编码为 progress_indicator_message 字符串。

⊙ CHECKLIST — “哪些内容已填写？”

读取角色设定文档；生成一份 Markdown 清单，将每个元素标记为 [+] 已填写、[-] 缺失，或 — 不适用。定义直接取自框架。

输出模板位于 assets/checklist-template.md。每条建议的后续步骤都可直接引用（例如，“前往 NAME”、“前往 FILL OUT，添加 Lexicon”），用户可以直接粘贴回复，无需重新输入。

适合在 SCORE 前快速检查缺漏，也适合在 ENCODE 前检查准备情况。

写入 persona/[agent-name]/checklist.md。

⊙ WORKSHOP

生成面向客户内部工作坊利益相关方的大纲。输出适用于 FigJam / 白板格式。

问题生成规则（完整规则请阅读 references/workshop-question-policy.md）：

• 优先提出影响力大的问题（身份、拟人化、语域）。
• 跳过已知内容。如果品牌输入已明确回答某个维度，就不要提问。
• 三种风格：验证（“我们假设 X——请确认或提出异议”）、二选一（两个真正不同的立场）、开放范围（将 Agent 定位在这条轴线上）。

使用 references/workshop-scenario-seeds.md 中的情境种子生成二选一问题。

输出模板位于 assets/workshop-outline-template.md。输出到 persona/[agent-name]/workshop-outline.md。

**质量优先于覆盖面。**提出 4 个好问题，胜过 12 个泛泛的问题。

---

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. 角色设定差异（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。