workflow & control for agent-driven work

Your agent writes the code.
 satelle says when it’s done.

satelle isn’t a harness — it’s the workflow your harness answers to. Your agent (Claude today, any harness by design) does the work and mutates the repo; satelle defines the process and gates every status change. Status is the only proof of done, reached only when every gate has accepted.

curl -fsSL https://github.com/bobmcallan/satelle/releases/latest/download/install.sh | sh

satelle runs 100% local · one static binary · no server · no cgo

claude code — driving a satelle story
satelle is built for agents: Claude Code does the work and calls satelle; the reviewer gates every step.

Why  satelle

The workflow is yours — and it gates every step

satelle doesn’t run your agent; your harness does. It sits above the harness as the process — and that process is your team’s. You encode your own development or business workflow as one coherent lifecycle graph in markdown — not a loose pile of disparate skills — and satelle quality-controls every step against it: each transition is gated by the workflow before it’s allowed. It’s not a harness and it’s never coded to one agent — Claude today, agent-agnostic by design.

Stories are the unit of work

A story carries a title, a goal, and numbered, testable acceptance criteria. You create one and drive it — satelle story create, then satelle story set <id> --status in_progress. One story at a time, to its terminal state.

Executor and reviewer, never the same actor

Two roles. The executor does the work and mutates the tree. The reviewer is an isolated, read-only judge that reads the repository and returns one verdict — accept, or reject with notes — and never touches a file. Quality is managed at the boundary, not asserted by whoever wrote the code.

Status is the proof of done

A status advances only through a reviewer’s accept, and always through it. done is the terminal success state, reached only when every gate the workflow declares has accepted. Not “code written,” not “tests pass locally” — the status is the record.

Every transition writes evidence

Each edge appends to an evidence ledger — the verdict, the actor, the step — and a summariser records a short recap. The web project page folds the ledger into a row of numbered stage lights: green accepted, red rejected, amber the current stage. How work reached done stays auditable.

The process is authored markdown you own

Workflows (the lifecycle graph), skills (reviewer rubrics or functional checks), and principles (the guardrails the agent reads) live as markdown committed to your git under .satelle/. Index it with satelle index; validate its structure with satelle validate. The binary runs the process; it never contains it.

Two kinds of gate

A gate is either an LLM reviewer — a skill’s markdown rides as a fresh-context judge’s prompt — or a functional check: a self-contained command where exit 0 accepts. This site is built through satelle, including a functional gate that builds and runs this homepage in Docker before any story closes.

What satelle doesn’t do

satelle is deliberately small. It governs a process and gets out of the way. The things it refuses to do are the point.

No harness of its own

satelle doesn’t run the agent or own the loop. Bring your harness — Claude today, any other by design — and satelle governs it to done.

No cloud, no server

satelle runs locally — a single static binary over a per-repo SQLite database, no account and no daemon you don’t control. The agent it drives talks to whatever model you bring; satelle itself never phones home.

No “trust me, it’s done”

An executor can’t self-enact a gated edge. Status advances only through an isolated reviewer’s accept — or it doesn’t advance.

No bundled process

satelle ships no opinion about your lifecycle. Workflows, skills, and principles are markdown in your repo — author them, own them, diff them.

No graded-by-the-author gate

The reviewer reads the tree read-only and returns one verdict. It never mutates, so an accept means the work stood on its own.

No invented process

When a gap blocks the loop — bad config, a missing gate, a human-only call — the agent surfaces it and stops. It doesn’t work around the workflow.

No cgo, no runtime deps

Build it, drop the binary in, run it. Nothing to link, nothing to install alongside it, nothing to break on the next OS bump.

Drive your first story to done.