using-gc

# Using GC Use Gas City only when the caller explicitly selects it. Treat it as a replaceable execution adapter, not a completion or correctness boundary. This skill teaches an agent to ORCHESTRATE the Mayor, which in turn propels the city — the same standing session a human drives, steered through native primitives. ## The model: one shepherd, two doors The city has a standing city-scoped **Mayor** session. It is a DISPATCH SHEPHERD: it watches ready rig step beads and slings each to its run-target with a nudge, which spawns that worker to claim the rig-scoped bead. Workers claim; **the Mayor never claims and never authors work.** You reach the one Mayor session through two doors: - **Human door:** `invoke.sh --city C mayor status` prints a `tmux -L <socket> attach -t <session>` line; the human attaches and drives interactively. - **Agent door:** `invoke.sh --city C mayor tell "dispatch <bead-id>"` delivers a notified mail message. No keystroke injection — GC ships mail/sling as first-class control, so an agent steers the resident session the way a human would, NTM-style. One-line why: on GC v1.3.5 demand-spawn is broken for rig work (#4586), so a shepherd that sling-nudges ready steps is the propulsion path — and it is also the stock GC mayor pattern, so this flow survives the upstream fix. ## The drive loop (for an orchestrating agent) 1. **Author intent — caller-owned.** `invoke.sh --city C create "<title>" -d "<why/how>"` writes one source bead with EXA...