AI SDLC — process control for agent-driven delivery
satelle is not another coding agent. It is the AI software development lifecycle your agent answers to. You map your real process — stories, gates, reviews, release — into authored workflows. The agent executes; isolated AI reviewers validate every transition against your rules and acceptance criteria. Status is the only proof of done. Local-first. Open-core. Works with any CLI agent you already drive from a terminal.
curl -fsSL https://github.com/bobmcallan/satelle/releases/latest/download/install.sh | shsatelle core runs 100% local · one static binary · your terminal agent · your model subscription
Coding agents are strong at doing. They are weak at owning process. Without a control plane you get chat-scoped “done,” the same session judging its own work, and no durable story spine. satelle sits above the agent as your team’s process — not a harness of its own, never coded to one vendor. Drive any CLI agent; the process stays yours. Change the workflow or a skill; change the SDLC. No platform rewrite.
Vibe coding optimizes for conversation. satelle optimizes for
work items. 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. Chat sentiment never advances status.
Every important transition can require a reviewer: isolated (fresh context, not the executor’s chat), read-only (judges outcome; never mutates), and bound to skill rubrics, principles, and the story’s acceptance criteria. The agent’s grant is bound per step — tools it may call, mutators denied where it must not write, and the model and effort it runs at — all configuration, not trust. Accept advances status; reject returns notes. Quality is managed at the boundary.
satelle does not sell tokens or a proprietary agent runtime. It drives any CLI agent that exposes a command-line interface — claude and grok are proven examples, not a fixed vendor list. Each step of a workflow can run on a different agent, model, and reasoning effort — expensive judgment where it pays, cheap execution everywhere else. Keep your subscription; satelle builds payloads, enforces grants, and records verdicts.
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.
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 stage lights: green
accepted, red rejected, amber the current stage. How work reached
done stays auditable.
Workflows (a derived route — done.toml + step.toml),
skills (reviewer rubrics or functional
checks), and principles (guardrails the agent reads) live under
.satelle/ in your git. UI work is judged against your own
authored design system, so agent-written interfaces do not drift into
one-off styling. A minimal baseline ships so you can start; you override
and own the rest.
Business or development process becomes configuration. The agent is forced through that lifecycle with gates and evidence — that is AI SDLC.
.satelle/workflows (done.toml + step.toml) · skills (rubrics & checks) · principles (guardrails).
Two kinds of gate: an LLM reviewer that judges a step, or a functional check — a real command (full test suite, container build, health probe) where exit 0 is the accept. Gates adapt to the story: UI changes can take a design review; others pass that gate by. This site is built through satelle, including a functional gate that builds and runs this homepage in Docker before a story closes.
Terminal agents optimize execution. Cloud platforms optimize agent infrastructure. satelle optimizes delivery governance — making AI implementation obey an authored SDLC.
e.g. claude, grok, or any CLI agent
Do the work in the repo. Excellent at generation and tool use. Definition of done is the session or a human eyeball. satelle is the process those hands must finish.
e.g. AWS agent runtimes & orchestration
Build, deploy, and operate agents at scale. Strong for multi-tenant agent ops. You design isolation, story spine, and AC gates yourself. satelle ships that pattern as a local, purpose-built product for coding delivery.
AI SDLC control plane
Stories + ACs, isolated reviewers, authored workflows, evidence ledger. Local-first core. Uses the subscription CLI agent you already pay for. Status is the only proof of done.
satelle is deliberately small. It governs a process and gets out of the way. The things it refuses to do are the point.
satelle doesn’t run the agent or own the loop. It drives an agent over its command line or over ACP, so a new agent is bound in configuration rather than waiting on a satelle release. Bring any CLI agent — claude and grok are proven examples — and satelle governs it to done on your subscription.
satelle core runs locally — a single static binary over a per-repo SQLite database. The agent talks to whatever model you bring; satelle itself never phones home.
An executor can’t self-enact a gated edge. Status advances only through an isolated reviewer’s accept — or it doesn’t advance.
A minimal baseline helps you start. Workflows, skills, and principles are authored files in your repo — override them, own them, diff them. Process is not frozen in the binary.
The reviewer reads the tree read-only and returns one verdict. It never mutates, so an accept means the work stood on its own.
Chat sentiment never advances status. Stories with acceptance criteria and gates do. When a story blocks, stuck is a state: the process runs triage on entry instead of stalling silently.
Build it, drop the binary in, run it. Nothing to link, nothing to install alongside it, nothing to break on the next OS bump.
Create a story. Drive it. Let isolated reviewers validate ACs. Treat done as earned.