using-gc

name	using-gc
description	Operate a caller-selected Gas City 1.4 with upstream registry packs and native run-centered surfaces while keeping GC runtime state out of AgentOps verdicts. Triggers: "using gc", "gas city", "drive the mayor", "dispatch through gc".
practices	["team-topologies","design-by-contract"]
hexagonal_role	driving-adapter
consumes	["explicit-packets"]
produces	["gas-city-runtime-evidence"]
context_rel	[{"kind":"partnership","with":"agent-native"}]
skill_api_version	1
user-invocable	true
metadata	{"tier":"execution","dependencies":[],"capabilities":["dispatch_explicit_packet","observe_gc_runtime","inspect_pack_registries","drive_mayor_door"],"effects":["operate_gas_city","configure_codex_trust"],"canonical_status":"canonical","disposition":"keep_optional_adapter"}
output_contract	runtime evidence per supplied packet

Using GC

Use Gas City only when the caller explicitly selects it. Treat it as a replaceable execution adapter, not a correctness or completion boundary.

Choose the factory first

AgentOps supports both Gas City and the Agentic Coding Flywheel as external software-factory runtimes. Use this skill only for Gas City. If the caller selects the Flywheel, use its native workflow instead of wrapping it in Gas City.

AgentOps supplies skills and evidence contracts to either factory. It does not need its own Gas City formula or role pack. Install or link AgentOps skills into the provider runtime before starting workers; the upstream Mayor, coordinator, and workers can then discover and select plan, implement, test, validate, and other AgentOps skills normally.

Gas City 1.4 operating model

Gas City 1.4 is run-centered. The supervisor serves the dashboard and typed, paginated session/run APIs. Every graph-owning city or rig scope needs its own core.control-dispatcher; that deterministic worker advances formula control beads. Agent workers claim routed work. The upstream gc.mayor skill is the guided coordinator; gc.run-operator launches and supervises formulas.

The normal AgentOps path is:

1. Install and pin the upstream gascity workflow and rig-role imports.
2. Add the project as a rig, prepare its stock maintainer runtime, and make AgentOps skills visible to its provider sessions.
3. Create a caller-owned bead and launch the upstream build-basic, continuation, review, or implementation formula that matches the available artifacts.
4. Read run, session, bead, artifact, and verdict state. Completion is never inferred from chat or pane prose.

Prepare and qualify a rig before its first build with the shipped AgentOps CLI (no repo checkout required):

ao gc prepare --city /path/to/city --rig /path/to/rig
ao gc check --city /path/to/city --rig /path/to/rig

The command verifies the exact official workflow and role pins, snapshots the upstream validation scripts and schemas unchanged inside the rig's .gc runtime, installs only small AgentOps-owned wrappers at the formula check paths, selects an existing Python that can import PyYAML, and links the AgentOps skills into the city and rig Codex sinks. Skills come from the enclosing AgentOps checkout when one is present, otherwise from the installed skills root; pass --skills-source to pin a different directory. It never modifies the GC binary, cache, formulas, roles, or upstream pack. issues only native inspection commands, writes no adapter files, and fails before model spend when that runtime contract is missing or drifted.