Menu
Use when the user says 'when X happens, do Y', 'set up a rule for', 'react to', or any request to define an event-driven trigger. Produces a Conductor reaction rule YAML and saves it to ~/pantheon/conductor/rules/.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | conductor-design-rule |
| description | Use when the user says 'when X happens, do Y', 'set up a rule for', 'react to', or any request to define an event-driven trigger. Produces a Conductor reaction rule YAML and saves it to ~/pantheon/conductor/rules/. |
| version | 1.0.0 |
| author | Thoth & Hermes (Pantheon) |
| license | MIT |
| metadata | {"hermes":{"tags":["conductor","rule","reaction","trigger","event"],"related_skills":["conductor-design-workflow","conductor-design-webhook","conductor-design-report"]}} |
Load this skill when the user wants to define what happens when a specific event occurs. Keywords: "when X, do Y," "react to," "trigger," "on [event]," "set up a rule for."
Ask:
If the source is external, walk through the handling modes:
| Mode | When to Use |
|---|---|
log_only | Monitoring, no action needed. Check later on demand. |
notify | FYI only. "Here's what happened." No execution. |
notify_and_log | Routine notification, explicitly marked no-action-needed. |
approval_required | Default for unknown sources. Actionable but needs a human nod first. |
route_on_approval | Known message type, predictable routing, but still needs approval before executing. |
If internal, gates are the primary guard — but still confirm whether the user wants auto-execution or a confirmation step.
What should happen when the rule matches?
# rules/{name}.yaml
rules:
- id: "" # kebab-case id
when:
event_type: "" # handoff.completed | nats.message | webhook | schedule.cron
source: "" # which god, which pantheon, which service
subject: "" # NATS subject, webhook path, schedule expression
then:
handling_mode: "" # log_only | notify | notify_and_log | approval_required | route_on_approval
action: "" # what to do
# For approval_required / route_on_approval:
on_approval:
dispatch_workflow: "" # optional
dispatch_god: "" # optional
skill: "" # optional
context_policy: forward_all
id is kebab-case, unique among existing rulesSave to ~/pantheon/conductor/rules/{rule_id}.yaml
Summarize what was set up:
Use when the user says 'set up a report', 'create a digest', 'I want a daily/weekly summary of', 'monitor X and report on Y', or any request for scheduled information synthesis. Produces a Conductor workflow + rules for scheduled reports and digests.
Use when the user says 'set up a webhook', 'connect X service to Pantheon', 'receive notifications from Y', or any request to bring external events into the Pantheon. Produces a webhook integration config and rule, saved to ~/pantheon/conductor/webhooks/ and ~/pantheon/conductor/rules/.
Use when the user says 'set up a pipeline', 'create a workflow', 'I need a multi-god process', or any request to chain multiple gods into a repeatable sequence. Produces a Conductor workflow YAML and saves it to ~/pantheon/conductor/workflows/.
Conductor handoff and acknowledgement protocol for Pantheon gods
Use after a design spec is written, before any implementation begins. Runs a structured assessment of holes, risks, pros/cons, system conflicts, overhead, and a go/no-go verdict. Must be completed before build handoff.
Use when the user says 'build Amber a skill', 'she needs something for X at the conference', 'make her a skill that does Y', 'package this up for her', 'design a skill for Amber', or any request to design, build, and ship a custom skill for Amber. The output is a fully packaged skill (zip file) ready to attach to Telegram and send to her agent for install. Designed to be invoked repeatedly as new conference needs come up.