Kingdom ForgeBefore the Flood — Team Hub

The canon: how we build with agents. Deep detail lives in the repo's docs/agent-harness — this page is the map.

How we build with agents

Agents are teammates, not magic: they use the same doors we do, and every change — human or agent — faces the same gates. One week of this workflow shipped the Act 1 greybox, a tested gameplay loop, and the harness itself.

Two lanes, one rule

One question picks your lane: is your Editor open?

Lane A · Editor open

The agent works live inside your Editor through the pinned MCP plugin — reads and edits the open scene, you stay in the loop. Use for human-in-loop iteration.

Lane B · Editor closed

The agent runs Unity headless in its own git worktree — never touching your checkout. Used for all autonomous work and verification.

The rule: anything repeatable becomes a small Editor script (Assets/Editor/*.cs) that runs identically in both lanes — reproducible and reviewable. The split is enforced by the tools, not politeness: the MCP plugin refuses batchmode, and Unity's single-writer lock keeps batchmode out of open checkouts.

The safety net: ./vibe

One word, before every push. Four proofs:

  1. Compile — every script builds headlessly; broken C# can't land (BF-78)
  2. Scenes load — every scene in the project opens without errors (BF-79)
  3. Content checks — report-only asset sanity; informs, never blocks (BF-95)
  4. Verdict — green or red, with provenance: which commit was actually proven

Editor open? The gate re-runs your last commit in a disposable sandbox worktree automatically. In-Editor you also get a session brief on project open and the Vibe Check panel in the Scene view (BF-94/96). Works on Windows via Git Bash (BF-97).

How work flows: the board is the interface

Ticket = the spec in · status + PR = the output. Same lifecycle for humans and agents:

  1. Ticket — a BF ticket with a Done = acceptance line is an agent-ready spec
  2. Claim — assignee set, status → In Progress, on start (not after)
  3. Build — branch BF-XX-slug; the key rides commits and the PR title; gates run
  4. PR opens — status → In Review, PR link commented on the ticket
  5. Merge → Done — status flips at merge, not before. Done means it's on main
The board stays truthful as a byproduct of the work, not a separate chore. Full command lifecycle: jira-protocol.md.

The two proof patterns

Spec-driven scenes

Write the layout spec down; one C# Editor script (BlockoutAudit) reads the scene and compares. Drift gets loud instead of silent — missing zones, wrong counts, spawns inside the ark hull. This is the repeatable pattern for every future zone and act: spec first, agent builds, audit proves.

Gameplay gets tests

An agent's “it works” is a test you can run. The gather → haul → deposit loop is driven end-to-end by a PlayMode test that goes red if any link breaks — exactly the failure class BF-89 described (chopping silently yielding zero wood). Bugs written with repro detail become agent-ready specs.

Getting started in 5 minutes

  1. Clone and install the hooks — scripts/install-hooks.sh. Activation is per-clone; git never does it for you
  2. Pick your lane — Editor open? Work live. Closed? Headless in a worktree
  3. Agent config ships in the repo — Claude Code (.mcp.json) and Cursor (.cursor/mcp.json) just work; Codex needs a one-time codex mcp add
  4. Before every push — ./vibe. Green means proven

Where things live

Rules of the road

Each one of these has actually bitten:

Working agreements