← the Atlas

The /be Workflow

Reference·budding·implemented·

How kolu takes a task to a shipped, reviewed PR — one interview up front, then a fully autonomous pipeline of skills. The whole flow, every skill in place, in one diagram.

/be is how kolu ships. You type /be <task>, answer a couple of questions, and walk away — the agent takes it from a fresh branch to a draft PR that has already survived a four-reviewer gauntlet, with green CI and visual evidence attached. This note is the map of that pipeline: what each phase does, which skill runs it, and how they hand off. Every blue node in the diagram is a link — to the skill’s canonical SKILL.md in whichever repo it lives (kolu, agency, odu), or to deeper reading where there is some.

/be — kolu's autonomous build pipeline One interview up front, then fully autonomous to a shipped, reviewed PR. Every blue node is a skill — click it to open its SKILL.md on GitHub. 0 Interview — the differentiator the one & only place /be asks you anything AskUserQuestion (batched, once) Plan first? · Task kind 1 Set up git fetch · branch off origin/HEAD · read .agency/do.md feature branch only — never commit to master /atlas plan-of-record note (optional · "plan first") 2 Implement — test-first repro red→green (bug) · cover (feature) · sync docs honor design philosophy · changelog · check + fmt /test /dev-server /nix-typescript /pu (heavy work) 3 Open the PR (draft) before any review — findings land on a real PR backfill changelog link · finalize plan note /forge-pr /atlas status: implemented 4 Review gauntlet four reviewers, SERIAL — each sole editor, commits in turn /be-review orchestrates the four · pushes once · then comments /lens-debate boundaries ∥ simplicity /agent-debate claude · codex · grok peer /simplify reuse · efficiency · altitude /code-police --no-elegance in gauntlet /lowy /hickey /fact-check elegance — skipped perf pass → atlas/performance if a perf-sensitive surface changed 5 Ship — CI ∥ evidence run concurrently on a pu box · join before Done CI pipeline (backgrounded first) /ci odu run → settle → rerun /odu-mcp drive CI via MCP face Evidence (concurrent) /evidence screenshot / video on pu /dev-server venue gate (local vs pu) /pu ephemeral host for both Done report PR · gauntlet outcome · CI status never merge — the human reviews & merges Legend: skill (links to SKILL.md) phase flow serial gauntlet attached skill / tool Autonomy propagates to every subagent · heavy work runs on a pu box.
The /be pipeline. The spine (top to bottom) is the six phases; skills attach to the right of each. The magenta loop is the review gauntlet — four reviewers run strictly one after another, each the sole editor of the branch while it runs. Ship fans into two parallel lanes (CI and evidence) that rejoin before Done. Click any skill node to open its source.

How /be differs from /do

/be is the Claude-Code-native descendant of /do. Both run fully autonomously start to finish — /do is “mostly autonomous” by design and asks nothing along the way either, so autonomy is not what sets them apart. Two things actually do:

/be lives in kolu today, but it’s meant to be upstreamed — to agency (where /do and most review skills already live) or another home — so it can decouple from kolu and be used anywhere. The kolu-specific pieces it leans on (the /pu box, /dev-server, the Atlas) are the seams that work would tease apart.

The interview covers three things:

The six phases

The spine of the diagram is six phases, run in order. The first is the interview above; the rest are fully autonomous.

  1. Set up — git fetch, branch off origin/HEAD (never commit to master), and read .apm/instructions/implementer.instructions.md for the project’s check / fmt / test / ci commands. If “plan first” was chosen, the plan of record is an Atlas note authored via /atlas.
  2. Implement — test-first. A bug is reproduced red before it’s theorized about, then fixed until the repro flips green — via the /test harness when a failing e2e can express it. Heavy work (builds, the dev server, reproductions) runs off-machine on a /pu box, launched through /dev-server, because production kolu lives on the same machine. A lockfile change refreshes the Nix FOD hash via /nix-typescript. Docs and the changelog are synced in the same commit.
  3. Open the PR — a draft PR, written with /forge-pr, before any review, so every reviewer’s findings land as comments on a real PR. The changelog link is backfilled and, if there’s a plan note, it’s finalized to status: implemented via /atlas.
  4. Review gauntlet — the heart of /be (next section). Skip entirely with /be --skip-gauntlet … (draft PR → Ship with no reviewers).
  5. Ship — CI and evidence, in parallel (section after next).
  6. Done — report the PR, the gauntlet outcome (or that the gauntlet was skipped), and CI status. /be never merges; the human reviews the commits and merges when satisfied.

The review gauntlet

Phase 4 is /be-review, which runs four reviewers serially — each the sole editor of the branch while it runs. Serial, not parallel, by design: two reviewers writing the same worktree at once would see torn, half-edited state. Running one at a time means every reviewer reads a clean, committed tree and applies its own fixes directly — no snapshot machinery, no separate apply pass.

  1. /lens-debate — two structural lenses, lowy (volatility-based boundaries) and hickey (structural simplicity), run as two independent subagents in parallel; one reconcile-and-apply pass then merges their findings and commits the fixes. Debate is only an escalation valve — bounded, and pulled just for findings where the two lenses directly contradict each other, with a discriminating experiment preferred over argument. Calls that are genuinely judgment (product scope, naming, boundary taste) go to the human instead of being argued to a synthetic consensus. Both lenses — and why kolu reviews with them — are explained in the blog post Hickey & Lowy.
  2. /agent-debate — the selected Claude, Codex, or Grok peer reviews the current author agent’s diff to consensus, with each author round auto-committing its fix(…).
  3. /simplify — the self-applying reuse, simplification, and efficiency pass over the changed code. (A built-in Claude Code skill, so this links to its docs rather than a repo.)
  4. /code-police — its rule-checklist and /fact-check passes, applying their fixes. It runs --no-elegance here, because the elegance pass would just re-invoke /simplify, which step 3 already ran over this same tree.

be-review commits each step locally but pushes once at the end, then posts the PR comments — so no comment ever advertises a commit that’s still local-only. If the diff touches a perf-sensitive surface, a performance pass checks it against the performance map and updates that note when a win is banked or a new one surfaces.

Ship in parallel

Phase 5 runs two independent lanes at once — there’s no reason to wait for green before capturing:

Both lanes run on a /pu box, never locally — a prior run piled local builds beside production kolu and the OOM-killer took production down. The lanes rejoin before Done: CI must be green on the final HEAD and evidence posted.

This note shipped in #1565.