gt-architecture

Describe Gas Town multi-agent roles and bead workflow primitives.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/justSteve/GasTownOperations --skill gt-architecture
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: gt-architecture
Source: https://github.com/justSteve/GasTownOperations/tree/main/.claude/skills/gt-architecture
Command: npx skills add https://github.com/justSteve/GasTownOperations --skill gt-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps reason about and document the Gas Town multi-agent architecture, clarifying role responsibilities, work primitives (beads, molecules, wisps, convoys), and per-rig configuration so teams can design, debug, and coordinate agents without losing operational context.

Core Features & Use Cases

  • Role mapping: Defines Town-level and Rig-level roles (Mayor, Deacon, Dogs, Boot, Witness, Polecats, Refinery, Crew) and their responsibilities for orchestration and supervision.
  • Workflow primitives: Documents beads (JSONL atomic work units), molecules (durable chained workflows), wisps (ephemeral in-memory tasks), and convoys (grouped delivery orders) to guide implementation and recovery strategies.
  • Rig configuration & examples: Describes per-rig .beads databases, witness supervision, polecat workers, and example rigs such as DReader and DataArchive for operational planning.

Quick Start

Ask the assistant to analyze the GT architecture and summarize the roles, workflow primitives, and recommended rig configuration for the DReader rig.

Frequently Asked Questions about gt-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the Gas Town multi-agent architecture and how do its roles interact?

The Gas Town multi-agent architecture orchestrates town-level supervision and per-rig worker coordination through roles like Mayor, Deacon, Witness, and Polecats. These roles manage tasks such as convoy delivery, bead workflow recovery, and merge management across designated rigs.

How do I configure a rig for multi-agent workflow recovery and merge management?

To configure a rig for workflow recovery, you need per-rig .beads databases and persistent bead tracking in JSONL. The rig must support durable molecules, ephemeral wisps, and clearly defined roles for Mayor, Deacon, Witness, Polecats, Refinery, and Crew.

What are beads, molecules, wisps, and convoys in multi-agent workflows?

In multi-agent workflows, beads are JSONL atomic work units, molecules are durable chained workflows, wisps are ephemeral in-memory tasks, and convoys are grouped delivery orders. These primitives guide implementation, orchestration, and workflow recovery strategies.

Can I use the Gas Town architecture to coordinate tasks in DReader and DataArchive rigs?

Yes, the Gas Town architecture applies to per-rig worker coordination for tasks in rigs like DReader and DataArchive. It uses witness supervision and polecat workers to manage convoy delivery, bead workflow recovery, and merge management.

Why do I need persistent bead tracking in JSONL for multi-agent orchestration?

Persistent bead tracking in JSONL is required for multi-agent orchestration to maintain operational context and ensure durable molecule processing. It prevents losing atomic work unit states during town-level supervision and per-rig workflow recovery.

What is the difference between town-level orchestration and per-rig worker coordination in Gas Town?

Town-level orchestration in Gas Town manages high-level supervision through roles like Mayor and Deacon, while per-rig worker coordination handles specific task execution via Polecats and Crew. Both levels rely on beads, molecules, and convoys for operational planning.