create-hat-collection – OpenClaw Skill

---

name: create-hat-collection description: Generates new Ralph hat collection presets through guided conversation. Asks clarifying questions, validates against schema constraints, and outputs production-ready YAML files.

Create Hat Collection

Overview

This skill generates Ralph hat collection presets through a guided, conversational workflow. It asks clarifying questions about your workflow, validates the configuration against schema constraints, and produces a production-ready YAML preset file.

Output: A complete .yml preset file in the presets/ directory.

When to Use

• Creating a new multi-agent workflow from scratch
• Transforming a workflow idea into a structured preset
• Need guidance on hat design patterns and event routing

Not for: Modifying existing presets (use /creating-hat-collections reference instead)

Workflow

Phase 1: Understand the Workflow

Ask clarifying questions to understand:

1. Purpose: What problem does this workflow solve?
2. Pattern: Which architecture pattern fits best?
   • Pipeline: A→B→C linear flow (analyze→summarize)
   • Critic-Actor: One proposes, another critiques (code review)
   • Supervisor-Worker: Coordinator delegates to specialists
   • Scientific: Observe→Hypothesize→Test→Fix (debugging)
3. Roles: What distinct agent personas are needed?
4. Handoffs: When should each role hand off to the next?
5. Completion: What signals the workflow is done?

Phase 2: Design Event Flow

Map the workflow as an event chain:

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

Constraints to validate:

• Each trigger maps to exactly ONE hat (no ambiguous routing)
• task.start and task.resume are RESERVED (never use as triggers)
• Every hat must publish at least one event
• Chain must eventually reach LOOP_COMPLETE

Phase 3: Generate Preset

Create the YAML file with these sections:

# <Preset Name>
# Pattern: <Architecture Pattern>
# <One-line description>
#
# Usage:
#   ralph run --config presets/<name>.yml --prompt "<example prompt>"

event_loop:
  starting_event: "<first.event>"  # Ralph publishes this

hats:
  hat_key:
    name: "<Emoji> Display Name"
    description: "<Short description of the hat's purpose>"
    triggers: ["event.triggers.this"]
    publishes: ["event.this.publishes", "alternate.event"]
    default_publishes: "event.this.publishes"
    instructions: |
      ## <HAT NAME> MODE

      <Clear role definition - what this hat does>

      ### Process
      1. <Step one>
      2. <Step two>
      3. Publish appropriate event

      ### Event Format
      ```
      <event topic="event.name">
      key: value
      </event>
      ```

      ### DON'T
      - <Common mistake to avoid>
      - <Another mistake>

Schema Reference

Required Top-Level Fields

Field	Description
event_loop.starting_event	First event Ralph publishes

Hat Definition Fields

Field	Required	Description
name	Yes	Display name with optional emoji (e.g., "🔍 Analyzer")
description	Yes	Short description of the hat's purpose (one sentence)
triggers	Yes	Events this hat responds to (list)
publishes	Yes	Events this hat can emit (list)
default_publishes	Recommended	Fallback event if hat forgets to publish
instructions	Yes	Role-specific prompt (use | for multiline)

Fields That DON'T Exist

Never use these—they're not in the schema:

• emoji (put emoji in name instead)
• system_prompt (use instructions)
• subscriptions / publications (use triggers / publishes)

Event Naming Conventions

<phase>.ready / <phase>.done      # Phase transitions
<thing>.approved / <thing>.rejected  # Review gates
<noun>.found / <noun>.missing     # Discovery events
<action>.request / <action>.complete # Request-response

Examples: analysis.complete, review.approved, build.blocked, spec.rejected

Validation Checklist

Before finalizing the preset, verify:

• Each trigger maps to exactly ONE hat
• No hat uses task.start or task.resume as triggers
• Every hat has name, description, triggers, publishes, and instructions
• default_publishes is set for hats with multiple publish options
• Event chain can reach LOOP_COMPLETE
• No orphan events that never get handled (warning only)
• Instructions include role definition, process steps, event format, and DON'Ts

Output Location

Save generated presets to: presets/<name>.yml

For minimal/embedded presets: presets/minimal/<name>.yml

Testing the Preset

After generation, test with:

# Dry run to validate config parsing
cargo run --bin ralph -- run -c presets/<name>.yml -p "test prompt" --dry-run

# Run smoke tests
cargo test -p ralph-core smoke_runner

Use /evaluate-presets for comprehensive validation.

Example Conversation

User: I want a preset for doing code reviews with a security focus.

Assistant: I'll help create a security-focused code review preset. Let me ask a few questions:

1. Review depth: Should this be a quick scan or thorough analysis?

2. Roles needed: I'm thinking:

   • Security Analyst (finds vulnerabilities)
   • Code Reviewer (checks logic/style)
   • Summarizer (creates final report)

   Does this cover your needs, or should we add/remove roles?

3. Iteration: If issues are found, should the code be fixed, or just reported?

User: Thorough analysis, those roles work, just report issues don't fix.

Assistant: Here's the event flow I'm designing:

task.start → [Security Analyst] → security.complete
                                        ↓
          → [Code Reviewer] → review.complete
                                        ↓
          → [Summarizer] → LOOP_COMPLETE

Let me generate the preset...

[Generates YAML with three hats following the schema]

Common Patterns Reference

Pipeline (Sequential)

A → B → C → done

Use for: analysis workflows, document processing

Critic-Actor (Review Loop)

Actor → Critic → approved/rejected
                    ↓
         rejected → Actor (retry)

Use for: code review, quality gates

Supervisor-Worker

Supervisor → worker.task → Worker → work.done → Supervisor

Use for: complex task decomposition

Scientific Method

Observe → Hypothesize → Test → confirmed/rejected
                                    ↓
                         rejected → Observe

Use for: debugging, investigation