用途
Agent Personas 是一个角色（persona）共享库，供其他技能加载使用，通过在任务执行期间切换执行器的默认行为偏置，让同一技能的产出更贴近特定专业视角。它解决的核心问题是：智能体的默认行为是“称职的通用工程”，只会浮现通才级别的关注点，因而会漏掉特定视角下的缺陷。例如架构师能发现类型学与命名缺陷，通才会忽略；开发者关系能发现新读者理解上的摩擦，通才会视为正常；产品经理能发现范围漂移，通才会吸收掉。加载角色就是把执行器的默认行为在该任务期间切换到对应视角。
主要能力
- 角色定义：一个角色是一个“谁”——是一组一致的优先事项、职责和词汇线索的具名代表，用于框定任务的执行方式。角色与技能正交：技能是“做什么”，角色是“谁来做”。
- 偏置切换：角色是一种加载到执行器上下文中的偏置框架，即一段 markdown 文本，声明身份、优先事项、关注点、以及惯用与回避的词汇。这种切换是 markdown 加载进上下文所能产生的效果，属于约定而非强制。
- 诚实的边界说明：角色会改变执行器的优先事项，以及某类关注点被驳回的门槛，但不会在交互式评审中把执行器变成用户。m1 architect-persona 的 A/B 测试显示了结论转变（在相同证据下 CONCERNS 对 SATISFIED），并浮现出无框架运行时被驳回的类型学关注点；但两轮都没有完全恢复用户实现后发现的最强形式——那是在交互式迭代而非单轮评审中浮现的。该库提升的是智能体默认审查的下限，不能替代人在回路中的评审。
使用方式
- 解析规则：当技能指示采用 <id> 角色时，从该技能目录加载 personas/<id>.md（.agents/skills/drive-agent-personas/personas/<id>.md），并在当前任务剩余时间内遵循它。
- 角色文档会替换默认框架：它的立场即你在该任务中的立场；它的优先事项即你首先关注的内容；它的职责即你产出或浮现的内容；它的词汇线索即你采用和回避的表述；它的可选探针（若存在）是在触发条件命中时要抛出的具体问题；它的可选“本视角之外的范围”章节指明哪些内容应交给其他角色而非自行裁定。
- 技能仅通过 ID 引用角色，绝不用文件路径。路径保存在本技能内部，使存储布局可以在不重写每个引用角色的技能的情况下改变。
- 标准加载指令为：“Adopt the <id> persona (see the drive-agent-personas skill).”
- developer 作为默认回退：省略角色指令的技能以 developer 角色执行。这是显式默认——未声明不等于没有；未声明即 developer。加载 personas/developer.md 可了解其实际含义（称职的实现者、契合代码库、运行验证门禁、诚实浮现逃逸问题、把实质性评审交给更高级角色）。作者编写新技能并打算以 developer 基线运行时，无需显式命名 developer；显式命名也可以，有时更清晰（例如在复合技能中想明确哪些子技能跑在默认上），但从不强制。
可用角色（v1）
v1 库恰好七个角色，每个都锚定到一个当前需要偏置切换的生产界面；推测性角色被推迟。
- architect（架构师）：命名、类型学、系统形态、统一语言、限界上下文、概念完整性。用于评审重命名、类型前缀、分层放置、ADR。
- principal-engineer（首席工程师）：可构建性、正确性、可运维性、爆炸半径、成本与复杂度。用于评审设计、代码和运行时关注点。
- pm（产品经理）：具名用户、证据、结果重于产出、范围、排序、最大风险假设、非目标。用于评审计划、规格和产品框定。
- tech-lead（技术负责人）：多角色工作的编排；路由评审者/实现者；把冲突浮现给人类；为正确受众打包产出。用于复合技能设计。
- developer（开发者，默认）：实现。未命名其他角色时运行的角色。在编写希望绑定可见的实现者类技能时显式使用。
- devrel（开发者关系）：采纳者的可学习性——文档、术语表、上手流程、新读者体验、界面所教会的内容。用于评审 README、JSDoc、示例、公共 API 名称。
- oss-specialist（开源专家）：公共界面管理——破坏性变更、许可证/来源、贡献摩擦、治理、triage 卫生。用于评审 CONTRIBUTING、破坏性变更 PR、依赖新增、RFC。
每个角色文件的形态文档见 personas/_shape.md，编写新角色前应先阅读该文件。
多角色技能
当一个技能的工作跨越多个角色时，在其主体顶部采用一个编排者角色，并在主体内的工作流边界处标明角色切换。编排者在综合点重新加载（通常在开始、切换之间和结束时），使智能体在视角切换之间回到元判断框架进行路由与打包工作。
关键原则：
- 技能显式命名自己的编排者角色——通常是 tech-lead，因为编排是 tech-lead 的视角。其他编排者在技能确有需要时也允许（例如 PM 编排的发现类技能）；由技能作者选择。
- 每次角色加载在技能主体中可见——在顶部和每个工作流边界处。不存在隐式角色继承。
- 角色不传播。每次切换都是独立的加载指令；智能体在每个边界重新加载，而不是把先前的角色延续下去。
- 技能在读取时自描述。阅读其 SKILL.md 的读者应能无需推断地重建在哪个时刻加载了哪个角色。
机制：SKILL.md 主体在工作流边界包含显式角色加载指令。每个切换处使用标准加载措辞（见解析规则），例如：“Begin by adopting the architect persona (see the drive-agent-personas skill). When architect-class concerns are settled, adopt the principal-engineer persona for the buildability/operability pass. At synthesis, reload the tech-lead persona to package the outcome.”
示例：以 architect + principal-engineer 序列调用的 drive-discussion，在单一问答工作流内依次处理类型学/命名/限界上下文关注点 → 失败模式/爆炸半径/可运维性关注点，并在综合时重新加载 tech-lead。由于对话是连续的，交叉授粉得以保留：在一个角色下提出的关注点可以在下一轮被引用而无需重新裁定。
未来扩展：随着 v2+ 角色被接纳（安全、QA 等），额外的角色加载步骤在适当位置插入工作流。在 architect 与 principal-engineer 之间加入安全角色轮次，应是在正确边界处的单次插入，而非重构工作流。
接纳 v2+ 角色的启发式
根据规范 NFR3，角色库是拉取驱动的：当具体技能需要时才编写新角色。接纳门槛为：
- 不同的执行期优先事项和职责。候选角色必须有一致的立场，是现有 v1 集合未覆盖的。“它像 architect 但针对 X”不是独立角色——那是 architect 角色应生长的探针。
- 实质性不同的执行输出。在代表性技能上加载候选角色，应产生读者可与同一技能在任何 v1 角色下执行区分开的输出。如果输出与 developer 或现有评审类角色无法区分，候选角色就未挣得其位置。
两个条件必须同时成立。记录候选者的接纳需包含：一段立场预览、需要它的技能（拉取），以及（在可行时）一个小的 A/B 对比以证明“实质性不同输出”条件。
v1 中推迟的角色
以下候选角色在 v1 中被考虑但未编写，理由是推测性接纳会在启发式可被应用之前稀释角色库：
- 安全：真实关注点，但横切其他每个角色的视角（架构师关心类型学的安全含义；首席工程师把安全视为失败模式；开源专家关心许可证风险即安全；PM 关心安全即用户价值）。当某个技能真正需要横切无法提供的安全专属视角时再接纳。
- 发布经理：目前由 tech-lead（发布类工作流的编排）和 oss-specialist（发布说明、破坏性变更纪律）吸收。当存在发布管理专属技能时再接纳。
- QA：目前由 principal-engineer（测试纪律作为可构建性关注点）和 developer（运行验证门禁）吸收。当存在立场与二者不同的 QA 专属技能时再接纳。
- 工程经理：v1 由 tech-lead 吸收。当某个工作流真正需要区别于编排的人员与流程视角时再接纳。
这些并非被禁止——只是尚未挣得。当技能作者有 v1 集合无法覆盖的具体需求时，他们应用启发式并接纳该角色。
角色文档形态
personas/<id>.md 下的每个角色文档遵循 personas/_shape.md 记录的形态契约：四个必需章节（Stance 立场、Priorities 优先事项、Responsibilities 职责、Vocabulary cues 词汇线索）加两个可选章节（Out of scope for this lens 本视角之外的范围、Probes 探针），在角色职责需要时启用。编写或评审角色前应先阅读 _shape.md。
参考
- AGENTS.md：角色引用的仓库约定。
- personas/_shape.md：角色文档形态契约。
- 七个角色文档本身（personas/<id>.md）。