How work moves
From a sentence you write to reviewed work on main.
- You decide what matters.
- The shaper helps you turn an idea into work.
- Workers build it, review each other and land it.
- The operator handles what workers aren't allowed to do.
- The hub keeps the record, so none of them start from nothing.
You're reading the 30-second version.You're reading the 5-minute version.You're reading the 30-minute version. This page has three depths: for the cast and the flow, for each part's steps, for the details. Keys 1, 2 and 3 switch it.
1. Set up once
Connect your machines, install the plugin and the GitHub App, and start a runner. Getting started has the commands.
- Connect each machine. Install nuworq from your hub, connect, and approve the code in the browser. Each machine gets its own token.
- Install the Claude Code plugin once. It gives you
/nuworq:shaperand/nuworq:operator. - Install the GitHub App on the repos agents push to.
- Turn on staffing for the project and start a runner:
nuworq run --workers 3 --agent claude.
The GitHub App gives agents one-hour tokens for one repo at a time, so no one needs a personal access token. Staffing is off by default, because workers cost money. The runner can be installed as a service, so it keeps going.
A setup that works well: an operator in a Claude Code terminal session, and a shaper session in the Claude Code app, opened in the project.
2. Shape the work with the shaper
Type /nuworq:shaper and say what you want and why, in your own words.
- It reads the project first: the board, your standing decisions, related items.
- It asks one or two questions at a time: who it's for, what done looks like, what must not change.
- It offers two or three options with trade-offs, recommends one, and names the milestone and its parts.
- Nothing goes to the hub until you say so. Then it files the parts and reads back what it filed.
Because it reads first, it doesn't propose work that already exists or that you've ruled out. Each part it files has an outcome for a title and acceptance criteria someone else can check. Its read-back lets you correct it in one reply.
When a rule should outlast these items ("phone-first", "no new dependencies"), it drafts it and asks you in the hub. It becomes a decision only if you confirm it, and from then on every agent reads it in every session.
3. Autonomy decides what happens next
You choose, for each project, how much agents do without you.
- Check with me. Proposals wait for your OK, and you check all finished work.
- Keep moving. Agents shape and start work, and you check finished work.
- Run with it. Agents also review each other's work, never their own.
4. Workers build, review and land it
Each worker takes an item, builds it on its own branch, and a different worker checks it before it lands on main.
- The runner keeps a worker going for each waiting item, each in its own git worktree, each item on its own branch cut from the latest main.
- The hub sends each worker to the most valuable waiting work across your projects, your priorities first.
- A worker claims an item and says which files it will change, so others steer clear.
- It submits with evidence: tests, commits, screenshots. A different worker checks it against the acceptance criteria.
- Accepted work lands on main before new work starts.
Routing. A worker never picks a project for itself; the hub routes it.
Leases. A claim is a 20-minute lease that progress renews. If the worker goes quiet, the item goes back to the queue.
Questions and handoffs. A question doesn't stop the work: the worker states the assumption it will make and keeps going. Only a truly blocked item parks, and the worker takes other work. When its context runs low, it hands off with a note, and the next worker starts from it.
Send-backs. The reviewer accepts the work or sends it back with reasons, and the next attempt starts from those reasons.
Landing. The branch is rebased onto main and checked, then main is fast-forwarded or the pull request merged. The item is done only when git shows main contains it.
5. The operator handles what workers can't
Workers run with a narrow set of permissions. The operator is an attended Claude Code session with yours, started with /nuworq:operator.
- It answers workers' questions about permissions and runs steps on live infrastructure.
- It signs releases, administers GitHub and uses a real browser.
- It can also review and land work.
It sits idle and costs nothing until a listener wakes it for operator work. It asks you only what only you can do, as one question in the hub with exact steps.
6. Agents get cheaper as they go
Turn on Cheaper models, and agents move to cheaper models once those prove they land work within the quality bar you set.
- You choose the models and the bar. nuworq only chooses among them; it never adds a model on its own.
- List the models each agent may use, cheapest first, and pick a quality bar: Best quality, Balanced or Cheapest that passes.
- Reviews and shaping always run on the top model: reviews are the quality gate, and shaping takes judgment.
- A share of builds tries a cheaper model, and the cheapest one that keeps up takes that kind of work.
- Analytics shows it as Model routing: each model's clean rate by kind of job, the figures routing picks from.
Off until you turn it on. It's set per project in Settings, under Cheaper models. You list up to six models for each agent, cheapest first. Best quality takes only a model that does as well as the best; Balanced, a cheaper model within 5 points of the best; Cheapest that passes, within 15 points.
Starting out. Until there's data, builds start on the top model, and landing and tidying start on the cheapest.
Trials. To learn, a share of builds (10% unless you change it) tries one model down, or races a cheaper model against the top one. Only rote and standard items that aren't urgent are tried, and only while the project's daily budget lasts. Trials are counted, not random, so the share holds exactly.
The threshold. Once the top model and a cheaper one each have 20 finished attempts at a kind of job and difficulty, the cheapest model whose clean-landing rate is within your bar of the best takes those jobs.
Stepping up. A failed attempt (sent back, stalled, handed off, or its lease lost) moves the next attempt up a model.
7. Your part
A short list of what needs you, and steering when you want to change course.
- Needs you lists the few things only you can do: answer a question, make a call, check finished work. Healthy work never shows up there.
- Your phone pings only when something new needs you.
- You steer. A steer is a course correction every agent must acknowledge, and a decision is a rule every agent follows from then on.
Depth sets how much you see in the app too: 30 seconds, 5 minutes or 30 minutes.