Spec → shipped code. Supervised.
After installing core, every coding task in your repo runs through work-loop: plan → execute → verify → adversarial review. You get lint, typecheck, and tests as mechanical gates. Three specialist reviewers read every diff cold. The loop cannot self-certify — it always surfaces to you for plan approval and PR merge.
work-loop2 gatesThe build loop. Plans, executes, verifies, and reviews — mechanical gates and human checkpoints the agent cannot bypass.
new-spec1 gateAuthors a spec document before the build loop starts. Captures the trio (problem, user, success criteria) and acceptance criteria.
bug-fix1 gateDiagnoses and fixes a bug with a targeted root-cause analysis before writing a line of code.
frontend-engineeringEstablishes design intent and craft rules before writing HTML/CSS — pre-flight before any frontend surface change.
contract-acquisitionGrounds agent code against an unfamiliar API or library contract before implementation — prevents guessed signatures.
receive-brief1 gateReceives a structured brief from an external source and grounds it against the project scope and conventions before implementation begins.
init-project1 gateInitializes a new project with the full agent-ready-repo structure, conventions, and AGENTS.md.
adapt-to-project1 gateAdapts the agent-ready-repo conventions to an existing project's idioms and structure — the on-ramp for brownfield repos.
author-brief1 gateConverts unstructured external input (email threads, prose, Linear issues) into a DoR-compliant product brief and queues it in workspace.toml.
capture-work1 gateCaptures follow-ons, deferred scope, and audit items surfaced in a session into workspace.toml so later sessions can pick them up cold.
workspace-statusReads workspace.toml and surfaces ready-to-start items, blocked items, parallel candidates, and active signals — the cold-start orient for every session.
operational-safetyProvides failure-mode-keyed operational safety checklists for the work-loop's quality-engineer reviewer. Loaded selectively for infra and destructive work — not invoked directly.
security-checklistsProvides boundary-keyed security checklists for the security-reviewer. The work-loop loads only the boundary-matching modules — not invoked directly.
You open a task and describe it. The agent activates work-loop, checks whether risk triggers require full mode, writes the lean inline spec — the trio: problem, user, success criteria — and surfaces its assumptions.
You: Read the trio in the chat. Confirm the scope matches what you asked for — or redirect if the agent overreached. Check that the correct mode (light or full) was selected. Approve the plan. Five to ten minutes of focused reading; this is the gate that costs least and protects most.
After your plan approval, the agent implements against the spec. It runs lint, typecheck, and tests after each logical change. When a gate fails, it fixes the issue and re-runs the gate before continuing.
You: Watch the chat at key moments. After each logical task completes, skim the agent’s output to catch early drift. You don’t need to read every line — look for file names you didn’t expect, for scope creep, and for the agent surfacing a question. If it surfaces, answer quickly — a blocked agent costs more time than a fast redirect. If all is well, let it run.
After all mechanical gates pass, the agent runs adversarial-reviewer in a fresh session. The reviewer reads the diff cold — no context from the build session. It returns findings grouped by severity (Blockers, Concerns, Nits). The loop iterates on Blockers until the reviewer reports clean.
You: Monitor the review output as it lands. If the reviewer flags a Blocker you disagree with, provide a brief direction (“this is expected behavior because…”) so the next fix targets the real issue. For Concerns and Nits, scan them — you may choose to apply or defer without waiting for the loop to finish.
After all reviewers report clean, the agent opens the PR with a description including: what changed, why, what was deferred, and what was found mid-implementation.
You: Review the PR diff in GitHub or your editor. Read the description, not just the diff — the description tells you what the agent decided when it had choices. Check that the spec and implementation align. Look for anything in the diff that wasn’t in the plan you approved. Merge when satisfied.
For each gate, everything you need to make a confident decision.
A bounded plan with a clear trio, no scope creep, correct risk-trigger assessment, and plausible assumptions.
A plan that extends the scope of the request, missing risk triggers that should have fired, or a trio that doesn't name a specific user.
If you approve a bad plan, the agent executes it faithfully. The cost of a bad plan is the cost of a full loop iteration — plan approval is the cheapest gate.
Green gates, clean adversarial review, spec and implementation aligned, no unexplained diff.
Adversarial reviewer flagged a Blocker and you merged anyway. Or the spec drifted from the implementation without an update.
G4 is the last line of defense before the build loop output goes to release. A bad merge is harder to undo than a bad plan.
agentbundle install --pack core