Your first run

This walks one ticket from nothing to an open pull request. It takes two commands.

Before you start you need the CLI installed with your keys set, a GitHub repo you can push to, and a ticket in Linear or Jira.

Pick a small one

For a first run, choose something contained and boring — a focused fix, a small addition with an obvious test. You are checking that the loop works end to end, not how far it can be pushed.

1. Set up the repo

Styre needs to know how your project builds and tests before it can verify anything. Point it at your repo once:

styre setup ~/code/acme-app

It probes the repo — the languages, the components, the build and test commands — and then shows you everything it found:

Resolved components (commands run with repo write + network; paths drive verify routing):
  api [backend]  paths: services/api
    build: bun run build
    test: bun test
    lint: bun run lint
  web [frontend]  paths: apps/web
    build: npm run build
    test: npm test
Approve these components (commands + paths)? [y/N]

Read this list before you approve it

This is the one prompt that matters. Every command here later runs on your machine with write access to the repo and access to the network — that is how Styre verifies work against ground truth rather than taking an agent’s word for it. Some of these commands may have been proposed by the agent that probed your repo. Approving is you signing off on them.

Anything other than y aborts and writes nothing.

The result is a project profile at ~/.config/styre/<slug>/profile.json. It lives outside your repo, so nothing is added to your project. You do this once per repo, not once per ticket.

If you are missing a credential a later run will need, setup tells you now rather than halfway through the run.

2. Hand it a ticket

From inside the repo:

cd ~/code/acme-app
styre run ENG-482

That is the whole invocation. Styre reads the ticket, plans the work, implements it, verifies it, reviews it, and opens the pull request.

Your working copy is not touched

By default Styre does its work in an isolated git worktree under your system temp directory, not in your checkout. You can keep working while it runs. Your branch is pushed to GitHub when it is done; your default branch is never written to.

3. Read the result

A finished run ends with a summary on stderr:

Opened the PR — ready for your review. Waiting on CI + merge approval.
PR: https://github.com/acme/app/pull/1183
Stage merge · 14 ticks · 23 events
  #4  transition design→implement
  #12 transition implement→review
  #19 transition review→merge
  …

The last line and the timeline are the run’s own record of what it did — every step is journaled as it happens, which is what makes a run auditable after the fact and resumable if it dies.

Everything human-readable goes to stderr. stdout carries only NDJSON telemetry, one JSON object per line, so you can pipe a run somewhere useful without the prose getting in the way:

styre run ENG-482 | jq -c 'select(.type == "summary")'

Then open the pull request and review it like any other. Styre stops here on purpose — it does not merge, and it will not wait for CI to go green before handing it to you. See Exit codes for what the process returns.

If it stops early

It happens, and it is usually not a failure of your setup:

• Exit 75 — the run hit a session limit or ran out of credits. It saves its state without consuming a retry and can be picked up later with styre run --resume.
• Exit 69 — a program your build or test commands need is not installed. Caught before any tokens are spent; the message names what is missing.
• Exit 65 — a resume was refused because the branch moved underneath it.

Recovering a run covers all of these.

---

Next: Writing a ticket — what makes a ticket Styre can deliver, and Project setup for the parts of the profile you may want to adjust by hand.