<< All versions

Skill v1.0.0

currentAutomated scan100/100
jxoesneon/ciel/gastown-orchestration
──Details
PublishedSeptember 27, 2026 at 06:46 PM
Content Hashsha256:41d3881e119069db...
Git SHA0a73bb6da1f0
──Files
Files (1 file, 3.8 KB)
SKILL.md3.8 KBactive
SKILL.md · 63 lines · 3.8 KB

version: "1.0.0" name: gastown-orchestration description: CIEL's framework for CLI-toolchain multi-agent orchestration via the gt/bd command suite. Manages agent lifecycles, work slinging, and crash recovery. license: MIT metadata: ciel-version: 1.0.0 ciel-extension: ciel.yaml


CIEL ADAPTATION: Gas Town Orchestration (CLI Toolchain)

This skill adapts the Gas Town CLI toolchain (gt/bd) into Ciel's vocabulary. It provides a CLI-driven alternative to Ciel's internal fleet model — where autonomous-orchestration uses Ciel-native worktrees and missions, gastown uses external process spawning, bead-based work tracking, and mail-triggered patrols. Ciel's risk classifier gates subprocess spawning as mid→LLM_JUDGE or high→Council.

Core Vocabulary (Ciel Translation)

  • Bead (bd): A tracked work unit. Ciel equivalent: a mission task ticket.
  • Convoy: A batch of related beads. Ciel equivalent: a mission DAG node group.
  • Rig: A registered project workspace (GitHub repo). Ciel equivalent: an isolated worktree target.
  • Polecat: Ephemeral worker spawned per-task, vanishes on completion. Ciel equivalent: a one-shot sub-agent.
  • Crew: Persistent named worker with ongoing sessions. Ciel equivalent: a long-lived fleet agent.
  • Hook: Where work lands for a worker. GUPP (Gas Town Universal Propulsion Principle): if hook has work, run it.
  • Molecule: A workflow unit that survives crashes — any worker can resume where another left off.
  • Patrols: Witness (watches for stuck workers), Refinery (merges completed work), Mayor (coordinates rigs).

CLI Command Patterns

Engine Control: gt up (start), gt down (graceful stop), gt status (overview) Work Management: gt sling <bead> <rig> (assign work), gt convoy list, gt hook Workers: gt polecat list, gt crew list, gt peek <agent>, gt nudge <agent> "msg" Diagnostics: gt doctor (health check), gt doctor --fix (auto-repair), bd doctor, gt feed (activity stream) Beads: bd list, bd show <id>, bd sync, bd create --title "..." Refinery: gt refinery start, gt refinery status, gt refinery queue Patrol Activation: gt mail send <rig>/witness -s "Patrol" -m "Process completed work"

Lifecycle Management

  1. Install: go install .../gt@latest + go install .../bd@latest; verify with gt doctor AND bd doctor.
  2. Add Rig: Register a project; verify patrols exist via gt doctor --fix.
  3. Create Work: bd create --title "..." → bead ID assigned.
  4. Sling: gt sling <bead> <rig> → polecat spawns, work lands on hook, GUPP executes.
  5. Monitor: gt peek <agent>, gt feed; Witness patrols detect stuck workers.
  6. Merge: Refinery processes completed work → code lands on main.
  7. Shutdown: gt down for graceful stop.

Crash Recovery

  • Molecules survive crashes — any worker resumes another's in-progress molecule.
  • Run gt doctor --fix to repair prefix mismatches, missing patrols, daemon issues.
  • bd sync restores bead consistency across clones.
  • If a polecat is stuck: gt nudge <agent> "msg" → trigger Witness patrol → if still stuck, pull work and gt polecat nuke.

Verification Protocol

Never declare "ready" without full-flow verification: create test bead → sling → polecat completes → Witness marks ready → Refinery processes → code on main. If ANY step fails, investigate before proceeding.

Anti-Patterns

  • Manual Agent Beads: Creating agent beads by hand — gt sling does this automatically.
  • Guessing Session Names: Always use gt polecat list to get actual names.
  • Assuming Patrols Self-Activate: Witness/Refinery are agents, not daemons — send mail to trigger them.
  • Partial Readiness: Declaring the system working after gt doctor passes but before testing the full sling→merge flow.
All versions