conductor-design-rule

스타15

포크2

업데이트2026년 6월 16일 03:19

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/.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

Duskript

Duskript/Pantheon

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Conductor Rule Designer

When to Use

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."

Process

Step 1: Identify the Event Source

Ask:

Where does this event come from? (internal handoff, NATS message, webhook, cron schedule)
What is the specific trigger? (god completes a step, Tallon sends a message, Stripe payment, GitHub PR, time of day)
Is this source internal or external to our Pantheon?

Step 2: Determine Handling Mode

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.

Step 3: Define the Action

What should happen when the rule matches?

Dispatch a workflow → which one?
Dispatch to a specific god → which god, which skill/action?
Log only → to which journal?
Notify → via Hermes, or directly to Konan?

Step 4: Map to YAML

# 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

Step 5: Validate

Source type matches the event taxonomy (handoff / nats / webhook / cron)
Handling mode is appropriate for the source (external sources never default to auto-execute)
Target workflow or god exists
id is kebab-case, unique among existing rules
For cron rules: expression is valid

Step 6: Write

Save to ~/pantheon/conductor/rules/{rule_id}.yaml

Step 7: Confirm

Summarize what was set up:

Trigger source and event
Handling mode
Action on match
What happens if the source is unknown

이 저장소의 다른 Skills

같은 저장소

conductor-design-report

Duskript/Pantheon

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.

2026-06-1615

conductor-design-webhook

Duskript/Pantheon

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/.

2026-06-1615

conductor-design-workflow

Duskript/Pantheon

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/.

2026-06-1615

conductor-protocol

Duskript/Pantheon

Conductor handoff and acknowledgement protocol for Pantheon gods

2026-06-1615

design-critical-assessment

Duskript/Pantheon

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.

2026-06-1615

skill-author-for-amber

Duskript/Pantheon

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.

2026-06-1615

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"]}}

Conductor Rule Designer

When to Use

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."

Process

Step 1: Identify the Event Source

Ask:

Where does this event come from? (internal handoff, NATS message, webhook, cron schedule)
What is the specific trigger? (god completes a step, Tallon sends a message, Stripe payment, GitHub PR, time of day)
Is this source internal or external to our Pantheon?

Step 2: Determine Handling Mode

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.

Step 3: Define the Action

What should happen when the rule matches?

Dispatch a workflow → which one?
Dispatch to a specific god → which god, which skill/action?
Log only → to which journal?
Notify → via Hermes, or directly to Konan?

Step 4: Map to YAML

# 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

Step 5: Validate

Source type matches the event taxonomy (handoff / nats / webhook / cron)
Handling mode is appropriate for the source (external sources never default to auto-execute)
Target workflow or god exists
id is kebab-case, unique among existing rules
For cron rules: expression is valid

Step 6: Write

Save to ~/pantheon/conductor/rules/{rule_id}.yaml

Step 7: Confirm

Summarize what was set up:

Trigger source and event
Handling mode
Action on match
What happens if the source is unknown