name: create-hat-collection description: 通过引导对话生成新的Ralph帽子集合预设。询问澄清问题，验证模式约束，并输出生产就绪的YAML文件。

创建帽子集合

概述

这个技能通过引导的、对话式工作流生成Ralph帽子集合预设。它询问关于您工作流的澄清问题，验证配置以对抗模式约束，并产生生产就绪的YAML预设文件。

输出： 一个完整的.yml预设文件在presets/目录中。

何时使用

从头开始创建新的多代理工作流
将工作流想法转换为结构化预设
需要帽子设计模式和事件路由指导

不用于： 修改现有预设（使用/creating-hat-collections参考代替）

工作流

阶段1：理解工作流

询问澄清问题以理解：

目的： 这个工作流解决什么问题？
模式： 哪种架构模式最合适？
- 流水线： A→B→C线性流（分析→总结）
- 批评者-执行者： 一个提出，另一个批评（代码审查）
- 监督者-工作者： 协调员委派给专家
- 科学方法： 观察→假设→测试→修复（调试）
角色： 需要哪些不同的代理角色？
交接： 每个角色何时应该交接给下一个？
完成： 什么信号表示工作流完成？

阶段2：设计事件流

将工作流映射为事件链：

task.start → [角色 A] → event.a → [角色 B] → event.b → [角色 C] → LOOP_COMPLETE
                                                    ↓
                                         event.rejected → [角色 A]

要验证的约束：

每个触发器映射到恰好一个帽子（无模糊路由）
task.start和task.resume是保留的（从不作为触发器使用）
每个帽子必须至少发布一个事件
链必须最终达到LOOP_COMPLETE

阶段3：生成预设

创建包含这些部分的YAML文件：

# <预设名称>
# 模式：<架构模式>
# <单行描述>
#
# 使用：
#   ralph run --config presets/<name>.yml --prompt "<示例提示>"

event_loop:
  starting_event: "<first.event>"  # Ralph发布这个

hats:
  hat_key:
    name: "<表情符号> 显示名称"
    description: "<帽子目的的简短描述>"
    triggers: ["event.triggers.this"]
    publishes: ["event.this.publishes", "alternate.event"]
    default_publishes: "event.this.publishes"
    instructions: |
      ## <帽子名称> 模式

      <清晰的角色定义 - 这个帽子做什么>

      ### 过程
      1. <步骤一>
      2. <步骤二>
      3. 发布适当的事件

      ### 事件格式
      ```
      <event topic="event.name">
      key: value
      </event>
      ```

      ### 不要
      - <要避免的常见错误>
      - <另一个错误>

模式参考

必需顶级字段

字段	描述
`event_loop.starting_event`	Ralph发布的第一个事件

帽子定义字段

字段	必需	描述
`name`	是	显示名称，可选表情符号（例如，“🔍 分析器”）
`description`	是	帽子目的的简短描述（一个句子）
`triggers`	是	这个帽子响应的事件（列表）
`publishes`	是	这个帽子可以发出的事件（列表）
`default_publishes`	推荐	如果帽子忘记发布时的回退事件
`instructions`	是	角色特定的提示（使用`\|`用于多行）

不存在的字段

从不使用这些——它们不在模式中：

emoji（将表情符号放在name中）
system_prompt（使用instructions）
subscriptions / publications（使用triggers / publishes）

事件命名约定

<阶段>.ready / <阶段>.done      # 阶段转换
<事物>.approved / <事物>.rejected  # 审查门
<名词>.found / <名词>.missing     # 发现事件
<动作>.request / <动作>.complete # 请求-响应

示例： analysis.complete, review.approved, build.blocked, spec.rejected

验证清单

在最终确定预设之前，验证：

[ ] 每个触发器映射到恰好一个帽子
[ ] 没有帽子使用task.start或task.resume作为触发器
[ ] 每个帽子都有name、description、triggers、publishes和instructions
[ ] 对于有多个发布选项的帽子，设置了default_publishes
[ ] 事件链可以达到LOOP_COMPLETE
[ ] 没有未被处理的事件孤儿（仅警告）
[ ] 指令包括角色定义、过程步骤、事件格式和不要事项

输出位置

保存生成的预设到：presets/<name>.yml

对于最小/嵌入式预设：presets/minimal/<name>.yml

测试预设

生成后，用以下测试：

# 干运行以验证配置解析
cargo run --bin ralph -- run -c presets/<name>.yml -p "test prompt" --dry-run

# 运行冒烟测试
cargo test -p ralph-core smoke_runner

使用/evaluate-presets进行全面的验证。

示例对话

用户： 我想要一个用于进行代码审查并关注安全的预设。

助手： 我将帮助创建一个关注安全的代码审查预设。让我问几个问题：

审查深度： 这应该是一个快速扫描还是彻底分析？
所需角色： 我正在考虑：
- 安全分析师（发现漏洞）
- 代码审查员（检查逻辑/风格）
- 总结者（创建最终报告）
这覆盖了您的需求吗，或者我们应该添加/移除角色？
迭代： 如果发现问题，应该修复代码，还是只报告？

用户： 彻底分析，这些角色有效，只报告问题不修复。

助手： 这是我设计的事件流：

task.start → [安全分析师] → security.complete
                                        ↓
          → [代码审查员] → review.complete
                                        ↓
          → [总结者] → LOOP_COMPLETE

让我生成预设…

[生成遵循模式的三个帽子的YAML]

常见模式参考

流水线（顺序）

A → B → C → 完成

用于：分析工作流、文档处理

批评者-执行者（审查循环）

执行者 → 批评者 → 批准/拒绝
                    ↓
         拒绝 → 执行者（重试）

用于：代码审查、质量门

监督者-工作者

监督者 → worker.task → 工作者 → work.done → 监督者

用于：复杂任务分解

科学方法

观察 → 假设 → 测试 → 确认/拒绝
                                    ↓
                         拒绝 → 观察

用于：调试、调查