/ralph-hats

name: ralph-hats
description: Create, inspect, validate, explain, and improve Ralph hat collections. Use this skill whenever the user asks to make or refine a `.ralph/hats/*.yml` workflow, debug hat routing, explain event topology, or tune a multi-hat Ralph run.

Ralph Hats

Use this skill to operate the full Ralph hat lifecycle for user-authored hat collections.

Use This Skill For

• Creating a new hat collection in `.ralph/hats/`
• Inspecting an existing hat collection and explaining its topology
• Validating trigger routing, event flow, and completion behavior
• Improving or refactoring hats for clearer roles and safer routing
• Recommending better orchestration patterns for a Ralph workflow

Core Assumptions

• Core runtime config already lives in `ralph.yml` or another `-c` source.
• User-authored hats are stored separately and passed with `-H`.
• This skill operates public hat collections, not Ralph built-in presets.

Workflow

1. If a hats file already exists, read it first and explain the current topology before proposing changes. 2. If creating a new workflow, write it to `.ralph/hats/<name>.yml`. 3. Keep the hats file focused on hats-only data. Leave runtime limits and other core config in the main config file. 4. Validate with `ralph hats validate`. 5. Visualize topology with `ralph hats graph` when the event flow is not trivial. 6. Use `ralph hats show <hat>` when you need to inspect one hat's effective configuration. 7. When the user wants stronger confidence, run a targeted `ralph run -c ... -H ... -p "..."` exercise or provide the exact test command.

Guardrails

• Only use hats-file top-level keys that Ralph accepts today:

`name`, `description`, `events`, `event_loop`, `hats`.

• In a hats file, `event_loop` is only for hats overlay keys such as

`starting_event` and `completion_promise`.

• Never use `task.start` or `task.resume` as hat triggers. Ralph reserves those

for coordination. Use semantic delegated events like `work.start`, `review.start`, or `research.start`.

• Each trigger must route to exactly one hat.
• Keep `description` populated on every hat.
• Prefer `events:` metadata when custom event names would otherwise be opaque.
• Do not write user workflows into `presets/` from this skill.

Output Expectations

• When editing or creating hats, produce the file changes and the validation

result.

• When only inspecting, produce a concise topology summary, the main risks, and

concrete improvement options.

Read These References When Needed

• For current hats schema and supported fields: `references/schema.md`
• For command recipes and validation workflow: `references/commands.md`
• For pattern and file examples: `references/examples.md`