Menü
Conductor handoff and acknowledgement protocol for Pantheon gods
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | conductor-protocol |
| description | Conductor handoff and acknowledgement protocol for Pantheon gods |
| category | software-development |
| version | 1.0.0 |
| author | Marvin |
| tags | ["conductor","handoff","ack","protocol","workflow","pantheon"] |
This skill documents the Conductor workflow engine's handoff and acknowledgement protocol. Every god in the Pantheon must follow this protocol when completing workflow steps or receiving dispatches from Conductor.
Spec: ~/athenaeum/Codex-Pantheon/specs/conductor-workflow-engine.md v2.0.0
Runtime: ~/pantheon/conductor/conductor-server.py
When you complete a workflow step, you MUST submit a structured handoff to Conductor.
Call the conductor.submit_handoff MCP tool with this payload:
{
"handoff_id": "hof_20260614_abc123",
"workflow_id": "wf_deploy_42",
"from_god": "thoth",
"to_god": "hephaestus",
"step": "research",
"context": {
"summary": "Researched MCP ecosystem migration options.",
"decisions": ["Migrate to FastMCP 3.x", "Priority: MCP migration (critical)"],
"artifacts": ["/athenaeum/research/mcp-ecosystem-2026/report.md"],
"open_questions": ["Should Hermes coordinate upgrade schedule?"],
"gates_passed": ["state_gate"]
},
"routing": {
"workflow_definition": "deploy-feature",
"workflow_version": "1.0.0",
"workflow_step": "architect"
}
}
| Field | Format | Description |
|---|---|---|
handoff_id | hof_YYYYMMDD_random6 | Unique ID. Generate with timestamp + 6-char hex. |
workflow_id | wf_{name}_{seq} | Workflow instance this belongs to. |
from_god | God name | Your god name (thoth, hephaestus, marvin, etc.) |
to_god | God name | Next god in the workflow. |
step | Step ID | Step you just completed. |
context.summary | String | One-line summary of what you did. |
context.decisions | String[] | Decisions made during this step. |
context.artifacts | String[] | Paths to files you produced. |
context.open_questions | String[] | (Optional) Questions for next god. |
context.gates_passed | String[] | (Optional) RALPH gates you passed. |
shared/handoffs/schema.json).shared/handoffs/{workflow_id}/{step}.json.conductor/state/{workflow_id}.json.routing), dispatches to the target god's pending inbox.{ "status": "dispatched", "target_god": "...", "target_step": "..." }.When Conductor dispatches work to you, a dispatch file appears in your pending inbox at conductor/pending/{your_god_name}/{handoff_id}.json.
At session start, call:
inbox = conductor.check_inbox(god_name="marvin")
Returns:
{
"god": "marvin",
"dispatches": [
{
"dispatch_id": "disp_20260614_123456_abc123",
"handoff_id": "hof_20260614_abc123",
"workflow_id": "wf_deploy_42",
"from_god": "hephaestus",
"to_god": "marvin",
"step": "implement",
"context": { ... },
"dispatched_at": "2026-06-14T10:30:00Z",
"ack_status": "unacked"
}
],
"count": 1
}
You MUST call conductor.ack_handoff with one of these statuses:
| Status | When to Use | Conductor Action |
|---|---|---|
accepted | You have the work, will execute | Sets workflow in_progress, waits for your handoff |
pending | You're busy, queued it | Keeps dispatch visible, checks back later |
rejected | Wrong god / out of scope | Marks workflow failed, looks for alternative routing |
completed | Step done, result follows | Triggers next step immediately |
{
"ack_id": "ack_20260614_456",
"handoff_id": "hof_20260614_abc123",
"workflow_id": "wf_deploy_42",
"status": "accepted",
"eta": "2026-06-14T12:00:00Z",
"message": "Heard, pulling context now. ETA ~90min."
}
ack_YYYYMMDD_random3 — timestamp + 3-char minimum hex.
Every god session should:
conductor.check_inbox(god_name="your_name")ack_handoff with accepted or pendingcontext contains all prior decisions, artifacts, summaries — do not ask the user to repeat information already in context.submit_handoff with your results.Conductor runs RALPH gates at step boundaries. Your handoff's context.gates_passed should list gates you've satisfied.
| Gate | Skill | When It Runs |
|---|---|---|
state_gate | Read-before-write check | Before any file mutation |
logic_gate | Syntax/type validation | After code generation |
phase_detect | RALPH phase detection | At step boundaries |
handoff | Handoff validation | On every submit_handoff |
conductor.get_workflow_state(workflow_id) — Full state of a workflow.conductor.list_pending() — All pending dispatches across all gods.conductor.list_rules() — Active reaction rules.conductor.list_workflows() — Available workflow definitions.If a workflow fails irrecoverably:
conductor.abort_workflow(workflow_id, reason) — Writes abort manifest + .aborted markers beside artifacts.conductor.cleanup(workflow_id) — Deletes declared temp_artifacts from workflow YAML (opt-in).Add this to your god's SKILL.md:
## Conductor Integration
When you receive a handoff via Conductor:
1. Call `conductor.check_inbox(god_name="your_name")` at session start.
2. Acknowledge with `conductor.ack_handoff({ status: "accepted", ... })`.
3. Read the full `context` block — it contains ALL prior decisions and artifacts.
4. Execute the step.
5. Submit handoff with `conductor.submit_handoff({ ... })` including:
- `context.summary`: one-line summary
- `context.decisions`: array of decisions made
- `context.artifacts`: array of file paths produced
- `context.gates_passed`: gates you satisfied
PANTHEON_ROOT — Override Pantheon root (default: ~/pantheon)CONDUCTOR_BASE_DIR — Override Conductor base dirCONDUCTOR_HANDOFFS_DIR — Override handoffs dir| Tool | Call When | Returns |
|---|---|---|
submit_handoff | Step complete | { status, target_god, target_step } |
check_inbox | Session start | { dispatches[], count } |
ack_handoff | Dispatch received | { acknowledged, state_status } |
get_workflow_state | Need status | Full workflow state JSON |
list_pending | Overview | All pending across gods |
list_rules | Debug routing | Rule file paths |
list_workflows | Discover | Workflow definitions |
~/pantheon/shared/handoffs/schema.json~/pantheon/conductor/conductor_server.py~/pantheon/conductor/conductor-server.py~/pantheon/tests/test_conductor_*.pyRun tests: python3 -m pytest tests/test_conductor_*.py -q
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 '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/.
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/.
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.