Menú
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/.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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.
| 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: