A collection of opt-in Gas City packs.

Gas City is an orchestration-builder SDK for multi-agent coding workflows. A pack is a unit of workspace configuration: agents, commands, services, formulas, skills, hooks, template fragments, or any combination. Packs compose through pack.toml imports, so a city can opt into any subset of the packs in this repo without forking.

For the full model (cities, rigs, formulas, beads, runtime providers) see the Gas City README.

If you just installed Gas City and want a working multi-agent build factory, this is the shortest path. Each step is copy-pasteable; swap names to taste.

1. Install Gas City and start a city (skip steps you have already done):

   brew install gascity
   gc init ~/my-city
   cd ~/my-city
   gc start

2. Add the repository you want agents to work on as a rig:

   git clone https://github.com/you/your-project
   cd your-project
   gc rig add .

3. Import the base pack. From the city directory:

   gc import add --name gc https://github.com/gastownhall/gascity-packs.git//gascity

   This writes the import, fetches the latest release, and pins it in packs.lock — no clone needed. (gc import upgrade gc moves the pin later; contributors hacking on the packs themselves can point source at a local clone instead.)

4. Import the rig roles in your city's city.toml. Rig-scoped imports are declared on the rig entry:

   [[rigs]]
   name = "your-project"
   
   [rigs.imports.gc]
   source = "https://github.com/gastownhall/gascity-packs.git//gascity/roles"

   The city-level import provides the workflow formulas and the gc.mayor coordinator skill; the rig-level roles import provides the worker agents (gc.implementation-worker, gc.requirements-planner, and friends) that the formulas route work to. Run gc import install after editing to fetch anything newly referenced.

5. Run your first build. Create a bead describing the goal, then launch the starter factory against it:

   gc bd create "Add a --json flag to the export command"
   gc sling gc.run-operator <bead-id> --on build-basic \
     --var artifact_root=plans/json-flag/build

   build-basic walks requirements → plan → plan review → decomposition → parallel implementation → a three-lane review fanout → finalize. Artifacts (requirements, plan, review reports, and a factory-run.md summary) land under artifact_root in your rig.

6. Pick a methodology when you want more opinion. The four methodology packs below replace build-basic's stages with vendored, battle-tested processes while keeping the same launch shape — import one at city scope and sling its build formula instead (for example --on bmad-build):

   gc import add https://github.com/gastownhall/gascity-packs.git//bmad

   Each pack's README has its own quick start.

All five expose the same launch variables (interaction_mode, review_mode, drain_policy, push, open_pr, …), so switching methodology is a one-word change to the formula name.

The canonical path is the import CLI — it writes the import, fetches the latest release, and pins the commit in packs.lock:

gc import add https://github.com/gastownhall/gascity-packs.git//bmad

Which is equivalent to this in city.toml (or any pack's pack.toml), followed by gc import install:

[imports.bmad]
source = "https://github.com/gastownhall/gascity-packs.git//bmad"

Contributors working on the packs themselves can clone this repo and point source at a local path instead:

[imports.bmad]
source = "../gascity-packs/bmad"

Each pack documents its own prerequisites, import snippet, and usage.

Each top-level directory is either a pack or a group of related packs:

• A directory containing pack.toml is itself a pack; import it by path.
• A directory without pack.toml groups related subpacks and typically ships an all/ rollup that imports the group as one.

Browse the tree for the current set; each pack has its own README.

• cass adds a shared cass-search prompt fragment and Claude skill overlay for searching past coding-agent sessions.

Raw-framework subagents become Gas City fanouts. The vendored methodology text is treated as source material for behavior, not runtime authority: if a raw skill says to spawn a subagent, dispatch a task tool, or invoke a plugin command, the pack should model that work as formula steps, expansion children, drains, or fanout/fanin lanes.

Use two mode concepts when comparing methodology packs:

• interaction_mode describes human participation in planning and gates: interactive, autonomous, or headless.

• review_mode describes whether review is report-only, machine handoff, or an interactive top-level review that may apply safe fixes.

• gascity provides the build-base workflow contract, the default build-basic implementation, and the build-from-* continuation entrypoints for resuming a build from existing artifacts.

• compound-engineering imports gascity as gc and implements build-base with vendored Compound Engineering skills, agent personas, and Gas City-native review/finalization expansions.

• superpowers imports gascity as gc and implements build-base with vendored Superpowers skills and Gas City-native development/review expansions.

• bmad imports gascity as gc and implements build-base with vendored BMAD Method skills and Gas City-native story/review expansions.

• gstack imports gascity as gc and implements build-base with vendored garrytan/gstack office-hours, autoplan, review, QA, security, documentation, and release-readiness skills mapped to Gas City fanouts.

See the build methodology framework audit for the current parity assessment and proposed beginner-friendly updates.

The Slack provider ships as three tiers — pick the smallest one that covers your use case:

See the tiering design memo for the rationale.

Issues and pull requests are welcome. When a pack's surface changes, update its README in the same PR so the docs stay current with the code.