Skip to Content
WorkflowsOverview

Workflows

setup, build and fix: the three commands your coding agent runs.

The Veris plugin adds three commands to your coding agent.

CommandWhen
setupOnce per repository. Wires it to an environment
buildA feature that touches a third-party dependency
fixA bug in code that talks to one
/veris:setup
/veris:build https://github.com/org/repo/issues/42
/veris:fix "create_invoice duplicates the invoice when the response is lost"

Each agent writes the same three commands its own way.

Agentsetupbuildfix
Claude Code/veris:setup/veris:build/veris:fix
Codex$veris:setup$veris:build$veris:fix

Both build and fix take an issue link or a plain description, and both end in a proving run against the twin. What performs that run depends on the tier setup chose. On the container tier it is veris run, and its receipt is the record. On the direct tier your tests run against the wired sandbox, and the record is the twin’s trace, read from the id noted before the run. See Running tests.

Your agent cannot start these on its own. You invoke them. They deploy sandboxes and run your test suite, so they run when you meant them to.

What build and fix both do

Many agents infer how a vendor behaves from the client code that calls it, and a test written from the same inference passes whether the inference was right or not. Both commands check every vendor claim against a live twin before they change any of your source.

What you get back from either:

  • A test run with a record of what the twin received. On the container tier that is the veris run receipt; on the direct tier it is the twin’s trace. A run that did not reach the twin did not test anything, so neither command calls the work done without that record.
  • A PR saying what was verified and what was assumed. Three sections: what I verified and how, what I am assuming rather than verifying, and limitations and risks. It names the sandbox the work ran against.
  • No sandbox left behind. Each task gets its own, deleted at the end. Neither command promotes a sandbox, so what your team boots into is unchanged.

build or fix

Use fix for anything described as broken, build for anything described as missing.

fix is the stricter of the two. It reproduces the failure against the twin before it changes any code, and reproduces it green afterwards through the same code path. If the bug will not reproduce, that is the finding, and it stops and tells you rather than changing code on a guess.

build has no failure to reproduce, so it checks the vendor claims the design rests on instead.

Zoomsetup