Your tickets. Your machine. Trau at work.

Tickets in. PRs out.

Watch Trau build, verify, and ship a ticket. Start to finish, on your machine.

Trau in action

From ticket to merged PR

0:00 / 0:00
A real run, from the first rough ticket to the merged pull request.
Start free trial Read the docs

14 days free, no card. Runs on the agent subscription you already pay for.

→ intake

A note at breakfast is a merged PR by lunch.

Type the idea badly. The grill interviews you until it is a ticket, the ticket queues behind the ready-for-agent label, and the drain runs the queue top to bottom — several slices at once, each on its own worktree.

trau — hub · loop

2 running · 1 merged · drain armed

1

Grill

mode: interview

draft

the run ledger should say which brain did each phase, i keep guessing

provider
claude · fable
destination
tracker
auto-accept
on
2

Backlog

ready-for-agent

  • FLD-521todo

    Atlas: collapse the dependency graph to the touched packages

  • FLD-524todo

    Quarantine a slice after the third failed verify

  • FLD-526todo

    Diff sidebar keeps its scroll position across refreshes

  • FLD-529todo

    Re-queue a parked ticket from its run page

3

Loop

2 worktrees live

  • FLD-512pr_openclaude · opus

    Editable label chips on every inbox issue

    ci-wait…2h 15m

    wt · feature/FLD-512-editable-label-chips

  • FLD-508pr_opencodex · gpt-5.6-sol

    Queue drain stalls when a parked epic un-parks

    ci-wait…2h 15m

    wt · feature/FLD-508-queue-drain-stalls-when-a-parked

  • FLD-514mergedclaude · fable

    Run ledger wraps the finished cell onto two lines

    merged #14101h 39m

    wt · feature/FLD-514-run-ledger-wraps-the-finished-cell

shipped

  • FLD-514 · #1410

6h 9m of agent time

Timings are compressed for the demo — a real slice takes minutes to hours. Everything else is what the hub reports: the phase names, the activity per phase, the brain each slice was routed to, and a verify that sends work back rather than waving it through.

Nothing waits on you
Grill a ticket while three others build. The queue drains whether or not the hub is open.
Parallel by worktree
Each slice gets its own checkout, so lanes never fight over the index or a dirty tree.
Rejection is the normal path
A failed verify routes to cold repair and re-verifies — bounded, then quarantined for you.

→ the engine

Build → Verify → Ship. Every phase cold.

Under the hub, each ticket runs through three steps — and every activity inside them starts a fresh, isolated agent.

No --continue. No --resume. Each activity starts a brand-new agent that inherits only what it needs: a durable handoff brief and the code on disk. The build agent's reasoning — and its blind spots — never carry forward.

trau — live run
→FLD-512— in progress
BUILD
build
lintfix
cleanup
handoff
VERIFY
verify
repair
bugfix
SHIP
commit
pr
ci-wait
merge
  1. Build

    Writes the code against the ticket, strips AI-slop, and distills what changed into a brief the next agent can act on cold.

    buildlintfixcleanuphandoff
  2. Verify⚠ cold

    A fresh, skeptical pass that sees only the brief and the diff. Failure spawns cold repair, then re-verifies — bounded, then quarantined.

    verifyrepairbugfix
  3. Ship

    Stages the verified diff, opens the PR, waits on your existing CI checks, and merges on green.

    commitprci-waitmerge

A ticket with sub-issues runs as an epic — children fan out onto a shared epic branch; a ticket without them runs solo. You don't configure it — Trau reads it.

Three steps. One binary. No mercy at verify.

See how verify worksRead the docs

Build · Verify · Ship · fresh process per activity — no --continue, no --resume

⚠ the differentiator

Let a rival check your homework.

Cold verify. No mercy.

Most loops let the author grade their own work. Trau doesn't. Every phase runs in its own fresh, isolated agent — so verify is a cold, adversarial pass that sees nothing but the handoff brief and the code on disk. No shared reasoning. No shared blind spots.

Build agent

Writes the code. Knows every shortcut it took, every assumption it made, every corner it cut.

never meet

Verify agent

A fresh, skeptical process. Sees only the brief and the diff. Cold. It cannot inherit the build agent's blind spots.

Or convene a panel — across vendors

Turn one verifier into two or three. Each is a fresh, isolated agent grading the same diff independently — and you can pull them from different vendors, so no single model's blind spots decide the merge. Disagreement blocks it, under a policy you set. The most rigorous cold-verify pass in any AFK loop.

build → panel grades cold & independent → consensus, or no merge

When verify fails, the merge is blocked and a fresh repair agent gets spawned, then it re-verifies — bounded, then quarantined. The build agent knew every shortcut it took. The verifier doesn't, and doesn't trust the diff.

Every verdict and every rubric lands in the Run ledger — the receipts live in the hub.

fail → merge blocked → cold repair → re-verify → bounded, then quarantined

Read the verify docs

⌂ the hub

One tab for the whole herd.

Every screen below is served by trau serve — from the same binary, on your machine, in either theme.

Work

Operate

Observe

Configure

THEME
127.0.0.1:8728
Get notified when a run pauses, faults, quarantines, or merges.Enable

FIELDKIT-WEB

Inbox

Make unclear or new work ready to run — questions waiting on you come first.

New issue
WAITING FOR YOU4
  • FLD-221your turnconflict banner when a draft is stale
  • INT-4thinkingtidy the readme
  • draft:newsavedoffline-first draft sync
  • research:14thinkingpick a tile cache for the map view
1 of 4FLD-221conflict banner when a draft is staleSkip
FLD-221needs-triageyour turn

conflict banner when a draft is stale

What's unclear

The epic asks for a banner when a stored draft is stale, but it never says what makes a draft stale — a newer server revision, a different device, or simply age.

Why it matters

The build agent has to pick a staleness rule to write the check against, and the wrong guess ships a banner that fires on every reload.

Direction

Settle the rule and the affordance before this is queued: what the banner says, and whether it offers to keep the local draft or take the server copy.

No session yet — pick how this one should start, or send a first message to open with it.

InterviewRequirementsResearchSkip

Type your first message to start the interview…

Send

Work

From half an idea to a ready ticket.

Drop a thought in the Inbox and pick how it should start. An Interview asks one question at a time — recommending an answer and saying why — Requirements writes the business case, and Research comes back with a report you can export. Drafts hold tickets that don't exist yet, and when a session lands you choose what it becomes: update this ticket, split it into children, file it as tasks, or open a new one beside it.

Interview · Requirements · Research · Draft → ready ticket · applied → Add to queue

trau · live run — terminal + diff

● Build ○ Verify ○ Ship

0:00 / 0:00
The live run screen: the agent's real terminal, and the diff it is writing, growing file by file.
See it in the docsStart free trial

◇ speaks your stack

Plugs into what you already run.

Everything else is in the docs.

~ $ agents

  • claude code

    exercised

  • codex

    wired

  • kimi

    wired

~ $ git hosting

  • github

  • bitbucket

  • gitlab

~ $ trackers

  • linear

  • jira

Full capability matrix lives in the docs.

→ dogfooded

Trau is built by trau.

Every number below is counted out of trau's own repository. The loop opens pull requests against the binary that runs it — epics fan out into child slices, each one cold-verified before it merges.

of its 1,080 commits arrived as merged pull requests
984

of its 1,080 commits arrived as merged pull requests

releases tagged in the first eleven weeks
98

releases tagged in the first eleven weeks

Go test functions the loop has to keep green
6,626

Go test functions the loop has to keep green

config keys, every one editable from the hub
269

config keys, every one editable from the hub

trau · run detail — verify verdict

cold verify

Cold verify grading a slice it did not build: all twenty-four acceptance criteria in the rubric, re-checked against the running app before the PR opens.

→ pricing

Free for 14 days. Then one plan.

Install without a key and start the trial from the hub: every feature, no card. Subscribe in the app to keep going.

Trau Solo

The whole loop, the hub and every integration, on your own machines.

  • 14-day free trial with every feature, no card
  • 2 installs per license, and you can release a machine from the app
  • Subscribe, change the card and download invoices in the app
  • Cancel at any time
Monthly

€9.99

/ month

Billed every month.
Annual

€69.99

/ year

€5.83 a month, billed once a year.

Prices include VAT.

~ $ start the trial

Paste this into a terminal on macOS, Linux or WSL2.

curl -fsSL https://get.trau.sh/install.sh | sh

  1. Install

    Paste the command above. No key, no account.

  2. Open the hub

    Run trau serve and open it in your browser.

  3. Start the trial

    Enter your email, then the 6-digit code we mail you.

Already hold a license key? Add TRAU_LICENSE_KEY=<key> in front of sh. Perpetual keys keep working.

How the trial and license work