Open source Self-hosted · Apache 2.0

A software team made of AI agents, and you approve every step.

Write what you want built. A Product Owner turns it into a backlog, an Architect into a plan, specialists build it phase by phase, QA writes the tests and DevOps opens the pull request. Nothing moves past a gate until a person says yes.

Download & run View source
terminal
$ docker run -d --name slipwright -p 8500:8500 \
    -v slipwright-state:/data -v slipwright-work:/work \
    ghcr.io/ksksertac/slipwright:latest
amd64 & arm64 No separate database or queue Your keys, your repository
The Slipwright project pipeline: three developments waiting for approval and a finished one opened to its request, plan and four stages
Why Slipwright

Built the other way round

Most coding agents are one model in a loop, and you find out what it did when it is finished. Slipwright keeps a person at the wheel from request to pull request.

A team, not a chatbot

Each role is its own agent with its own model, instructions and permissions. A deterministic state machine calls one role at a time, and every answer is a typed schema.

You stay in charge

Backlog, architecture, screens, test cases, tests and deployment each stop at a gate. Edit what was proposed, approve it, or send it back with a reason.

Nothing is lost

Every step is written to the database before the next one runs. Stop the server mid-development and start it again: running work carries on, waiting work keeps waiting.

Your keys, your repository

It runs on your own model keys, pushes to your own GitHub or Bitbucket, and mirrors the backlog into your own Jira.

How a development flows

From a sentence to a pull request

Every stage stops at a gate you control. The agents never talk to each other; the engine hands work from one role to the next.

  1. Your request

    Describe what you want in plain words: in the pipeline, from the CLI or from Telegram.

  2. Product Owner writes the backlog You approve

    Epics, stories and tasks, written after reading the request and the repository. Rename, add or remove anything before approving.

  3. Architect plans the phases You approve

    The stack, the build/test/run commands, the decisions and one phase per task. Reorder phases, change domains, files or commands.

  4. Specialists build, one phase at a time

    Backend, web and mobile developers do the work, with the Designer's screens ready before any UI phase. After every phase the build gate runs your build_cmd and test_cmd; a red build goes back to the same specialist (up to three times), and QA reviews the diff against your standards.

  5. QA proposes cases, then writes the tests Two gates

    Approve the test cases, then the unit and end-to-end tests written against exactly those cases. Or go on without tests.

  6. DevOps deploys and opens the PR You approve

    Deployment files, the pushed branch and a pull request described from the plan, test cases and history. CI is watched; red CI goes back to the developer who wrote the code.

  7. Merge

    The pull request link is on the development and in the activity feed. Review it like any other PR.

See it run

One development, start to finish

From the Agents page to a new project linked to Jira. The backlog and the plan are approved and become issues on the Jira board, the Designer's screens are approved, QA's test cases are approved from Telegram, and DevOps proposes an AWS deployment on ECS Fargate, pushes the branch and opens the pull request.

From the Agents page to a new project linked to Jira. The backlog and plan are approved and become issues on the Jira board; the Designer's screens are opened at full size, web and mobile, and approved; QA's test cases are approved from Telegram; the tasks move to Done on the board; DevOps proposes an AWS deployment on ECS Fargate, writes the Dockerfile, task definition, deploy script and workflow, pushes the branch and opens the pull request; and the bot answers /status
Recorded against the scripted provider: no model, no key. Telegram, Jira and GitHub are local stand-ins that Slipwright's own code talks to; the press on the phone is what approves the gate, and the branch is really pushed.
The team

An agent for every role

Each agent has its own provider, model, thinking depth, standards and permissions, enforced by the engine, not by the prompt.

Planning

Product Owner

Reads the request and the repository, writes epics, stories and tasks.

read_filesjira
Planning

Architect

Chooses the stack, the build/test/run commands, the decisions and one phase per task.

read_filesrun_commandsjira
Design

Designer

Draws the screens the web and mobile specialists will build, behind a gate of its own.

read_fileswrite_files
Building

Backend · Web · Mobile

Implement one phase each, in the phase's own domain, behind the build gate.

write_filesrun_commands
Testing

QA

Proposes test cases, then writes unit and end-to-end tests for the approved ones, and reviews every diff against your standards.

write_filesrun_commands
Delivery

DevOps

Proposes the deployment, writes it, pushes the branch and opens the pull request.

networkgit_push
Oversight

Supervisor

Reads every gate and recommends approve or reject, with confidence, risk and reasons.

read_files
Human

You & your team

Put a colleague on an agent: they approve and edit only at that agent's gates, and are mailed when work arrives.

approveeditreject
Slipwright Agent

One Slipwright gives the orders, every machine does the work

Slipwright plans a development and splits it into phases. It never runs a model or a build on these machines itself: each agent asks for work it can do, and takes one phase at a time.

One Slipwright hands out phases to a MacBook, a Windows PC and a Linux server; each writes its phase with its own model, the Mac builds iOS, and the answers flow back until the development is done
Several machines can be lent to one account at once, so phases that do not depend on each other are written side by side.

Slipwright gives the orders

It keeps the plan, the gates and the order of the phases. It decides what is next and checks every answer: a wrong one is a retry, never a wrong file.

Every machine you lend it

Each says what it can do (write:backend, write:web, ios, android …) and is given only that. A Mac with Xcode gets the iOS builds, a Windows PC with Codex writes the web phases, and a Linux box over SSH runs with no window at all.

Your own model, your own keys

The phase is written on the machine with its own Claude Code or Codex sign-in, or its own API key. Keys never leave it.

From anywhere

Plain HTTP on the same network, or sealed end to end through the relay when the machine is somewhere else.

Download Slipwright Agent

Lend this computer to your Slipwright: a desktop app for macOS, Windows and Linux, or one file for a server with no window.

All releases
Apple Silicon (M1–M4) · .dmg Intel · .dmg

Prefer a .zip? Apple Silicon .zip · Intel .zip

  1. InstallOpen the .dmg and drag Slipwright Agent into Applications.
  2. Open it the first timeThe app is not notarized, so Gatekeeper refuses it once. Run the command below, or use System Settings → Privacy & Security → Open Anyway. Updates come through the app itself and the warning does not return.
  3. Pair it with SlipwrightIn Slipwright open Settings → Machines → Connect a machine, paste the one-time code into the app and choose which agents this machine runs, with which model. From then on it takes work by itself.
once, after installing
xattr -cr "/Applications/Slipwright Agent.app"

Native iOS and Android: the Mobile Builder

No container can hold macOS, so Xcode can never run in Slipwright's Docker image. The Mobile Builder is a small helper on a Mac, outside Docker, that does the builds the server cannot: iOS with Xcode, Android with Android Studio.

  • A development with a native app builds everything else, then waits at Waiting for the Mobile Builder: nothing fails and nothing is spent.
  • It carries on by itself when the Mac connects. The worker calls the server; nothing is opened on the Mac.
  • Set it up with slipwright worker --connect <code> from Settings → Machines → Connect a machine.
Settings, Machines: three connected computers, online, each with the agents it writes for and the platforms it builds, and a card to connect another
Tour

See it in action

Gates you can edit, a pipeline for every development and a dashboard of what waits for you.

Gates you can edit, not just approve

Each gate offers Save, Approve and Reject with a reason, and the reason goes back to the agent as feedback.

  • Supervisor advice on every gate, with confidence and risk.
  • Go on without tests when a change isn't worth testing.
  • Go on without deployment and still get the pull request.
The test cases gate: the supervisor recommends approve at 0.86 confidence, with QA's proposed cases open for editing
Under the hood

Serious about getting it right

A supervisor at every gate

Per project, choose how much the supervisor does. When a build fails, it also decides whether the same specialist fixes it, whether to re-plan, or whether to ask a person.

Manual
You decide every gateNo recommendations, no automation.
Assisted
Recommendation on each gateWith its confidence, its risk and its reasons. The default.
Auto
Confident, low-risk approvals made for youRejections are never automatic, and any automatic approval can be undone.
Supervisor recommendation on a gate with confidence and risk

Built behind a build gate, reviewed against your standards

After every phase, the project's own build and test commands run. Every green phase is committed on the development's branch. Then QA reviews the diff against your standards: Markdown pages per domain, indexed for keyword and optional embedding search.

  • Review mode: off, advisory or blocking.
  • Standards edited in the app, for all projects or per project; linted, reindexed and committed.
  • Only the relevant sections go into each agent's prompt.
phase 3 · build gate
# the project's own commands, after every phase
$ uv run pytest -q
........................  24 passed in 3.1s
$ npm run build
✓ built in 2.4s
# green → committed on sw/notes-search
# QA review against standards/backend.md
review: advisory · 0 blocking findings

Any model, per agent

Pin each agent to its own provider and model. Change the model in the profile and that role runs on it. No code change, no restart.

Anthropic Claude OpenAI GPT Google Gemini DeepSeek Alibaba Qwen Z.ai GLM MiniMax OpenRouter EVREN ChatGPT via Codex
profile.json · roles
"architect": { "model": "claude-opus-5",
               "thinking_depth": "high" },
"qa":        { "model": "claude-sonnet-5",
               "thinking_depth": "medium" },
"devops":    { "model": "claude-haiku-4-5",
               "thinking_depth": "low",
               "permissions": ["git_push", …] }

GitHub & Bitbucket

Clone a private repository or use a local checkout. A finished development pushes its branch and opens a pull request; red CI goes back to the developer.

Jira, optionally

The approved backlog becomes epics, stories and sub-tasks. PR links and failures are commented, as a bot account you choose.

In your language

The interface is in English and Turkish. Agents write in the project's language; everything is shown in yours through a cached translation bridge.

Costs & budgets

Per-project budgets on tokens, wall-clock time and model calls stop a runaway development with a readable reason.

CLI & API

Start, approve, reject and message developments from the command line. A JSON API at /docs and server-sent events for every change.

Encrypted credentials

Model keys and tokens are stored encrypted. State and work live in separate volumes, so a checkout can never reach the key.

Local or hosted, one codebase

LocalHosted
Who writes the build commandsyoustrangers
DatabaseSQLite filePostgreSQL
Commands runon the machinein a throwaway container
Model keysthe installation'seach account's own
Quotasoffon
Built for real work

You stay in control, all the way through

Phases written side by side, a branch you can follow on GitHub, an agent you can question, and a development you can take over by hand and give back.

Phases written side by side

The Architect says what each phase needs, and the plan gate shows it before you approve: which phases need no other, which come after which, and how wide the plan really is.

  • Up to 3 phases at once by default (max_parallel_phases, per project).
  • Each is still built, checked and committed one at a time, so the branch never holds half of two things.
  • A cap per provider key keeps the side-by-side calls from turning into rate-limit errors.
The plan at its approval gate: each phase with what it needs, and a summary saying up to 2 phases run at once, so the plan takes 2 steps instead of 3

Every step on your repository

Every green phase is committed and pushed at once, and the first push opens a draft pull request, so the work can be followed on GitHub or Bitbucket while it is still being made.

  • Commit messages carry the Jira key.
  • Each phase card says whether it is ready, being written alongside or waiting, and links to its own commit.
A finished development's building stage: each phase card says what it came after and links to its commit

Talk to the agent on a step

Open any step and Write to the agent that holds it. It answers on its own model, with the step's record, the plan and the work in progress in front of it, and changes nothing.

  • When the answer hears a request, it is put in the box for you to edit.
  • Then send it to this step, or plan it again from here and keep the phases already built.
A phase's side panel: two questions to the Backend Developer and its answers; the second heard a change, which waits in the box with Plan it again from here and Ask

Stop, work on it by hand, carry on

When you would rather write a part yourself, you do not have to wait for the agents or start over.

A development is stopped and its branch pushed; Ada checks it out in VS Code, finishes the half-written phase by hand and pushes; back in Slipwright, Pull and carry on brings her commit in, the Architect reads it as phase 2 done by hand, and once that is approved the development carries on with phase 3
  1. Stop and pushThe development stops where it is, keeps its place and pushes its branch, half-written phase and all, with the two commands to check it out.
  2. Finish it in your editorOpen the branch in VS Code or anything else, write what you want, commit and push as you always do.
  3. Pull and carry onSlipwright pulls your commits and the Architect reads what you did against the plan. Phases you finished are marked done by hand and never built again.
A paused development: Paused by Ada, the branch is pushed, with the git commands to check it out
Paused, with the branch pushed and the commands to check it out.
The carry-on dialog: somebody has pushed to the branch since it was paused, so pull them in; Carry on, and Pull and carry on
Somebody pushed since the pause: pull their commits in and carry on.

Move to another computer

Settings → Move carries an account to another Slipwright on the network in one go: projects, developments at whatever gate they stopped, history, attachments, settings and keys, every checkout with its unpushed branches and uncommitted work.

  • Sealed end to end: the code is the input to a key exchange, so nothing on the network can read it.
  • All or nothing: a move that stops half-way leaves nothing behind.
Settings, Move: this installation's card, a receiving code counting down from three minutes, and three promises: sealed end to end, keys arrive working, all or nothing

A phase that gets stuck stops, and asks

No runaway loops: a phase that cannot get green stops spending and puts the decision to you.

A budget per phase

Building, fixing, triage and review of one phase share one budget of model calls (8 by default). A phase that runs out stops spending, and QA recommends what to do next.

Your answer, in words

Choose Send to the developer or Plan this phase again, and write what should be different. What you write is what the next attempt is told.

The others go on

A phase out of budget is set aside with its work kept, and the phases that do not need it carry on being built.

Re-plans keep what is built

Planning again starts from the phase that failed. Phases already committed stay, and the Designer does not draw the same screens again.

Only what each step needs

Every prompt is trimmed to what that step can use, because tokens are what a development costs.

  • Context goes as compact JSON, not indented.
  • A red build sends the errors, not the last 20,000 characters of its log.
  • A developer sees other phases by their heading, and only its own in full.
  • A large file is changed with edits, not written out again.
  • Dependencies and lock files are kept out of every diff a role is shown.

Two-step sign-in

Optional and per person. Scan a QR code with any authenticator app and type the six digits back; eight recovery codes are shown once.

  • Every sign-in then asks for a code after the password; each code works once.
  • A link from an email no longer signs you in around it.
  • Turning it off asks for your password and a code.
  • The secret is stored encrypted with the installation key.
Remote control

Run it from Telegram

Link your Telegram account once, then answer gates, check on your projects and start new work from your phone, without opening the app. The bot reads your account and nobody else's.

Telegram: the bot is linked, a test-cases gate is approved, an architecture gate is rejected with a reason
A gate comes to you. The bot sends what is waiting, the supervisor's advice and a link. Press Continue to approve; press Reject and the bot asks why, and your answer goes back to the agent.
Telegram: /projects, /waiting and /status answered from the account's own developments
Ask where things stand. /projects, /waiting, /status, /running and /cost are answered straight from your data, at no model cost. Or just ask in your own words.
Telegram: /new, one sentence, a confirmation with Yes and No buttons, and the development starts
Start a development. /new, one sentence saying what should be built, and a Yes. Nothing starts until you confirm, because a development spends your own model credit.

Set up in two minutes

Create a bot with @BotFather, paste its token under Remote control, then press Get a link code and Open in Telegram. A one-time code, good for 30 minutes, proves the Telegram account is yours.

  • A gate only goes to its own people. A button pressed by anybody else does nothing.
  • An answer counts once. A late press is told so and changes nothing.
  • Commands work in English and Turkish (/durum, /bekleyen, /yeni …).
  • No public address needed: the bot fetches its own updates, so it works from a laptop behind a router.
The Remote control page: the bot token, and linking your own Telegram account
Get started

Download and run in a minute

One image holds everything: the API, the web UI, git, gh, Python and Node. There is no separate database or queue to run.

published image · nothing to clone or build
docker run -d --name slipwright -p 8500:8500 \
    -v slipwright-state:/data -v slipwright-work:/work \
    ghcr.io/ksksertac/slipwright:latest
# first login (becomes admin)
docker exec -it slipwright slipwright user add ada

Open http://localhost:8500. Keep /data and /work as two separate volumes: /data holds the key that decrypts every stored credential.

  1. Settings → ModelsPaste a key for at least one provider and click Test connection.
  2. Settings → SourcesAdd a GitHub or Bitbucket token to clone, push and open pull requests.
  3. Projects → New projectPick a repository; Slipwright reads it and proposes a brief.
  4. New developmentDescribe what you want, then answer the gates as they arrive.

ghcr.io/ksksertac/slipwright

Every push to main publishes :latest for amd64 and arm64; a v1.2.3 tag publishes :1.2.3 as well.

Open the package
Open source

Built in the open. Come build it with us.

Slipwright is fully open source under the Apache 2.0 license. Read every line, run it anywhere, fork it, and help shape where it goes next.

Contributions are welcome

Bug reports, fixes, new model providers, translations, documentation and ideas all help. Every contribution goes through a pull request on GitHub.

  • Found a bug or have an idea? Open an issue and describe it.
  • Want to write code? Fork the repository, make your change on a branch and open a pull request.
  • New to the codebase? CLAUDE.md is the orientation: the layout, the rules that are easy to break and the mistakes already made.
  • Like the project? A star on GitHub helps others find it.
Contribute on GitHub Open an issue
contributing · github.com/ksksertac/slipwright
# fork on GitHub, then
git clone https://github.com/<you>/slipwright.git
cd slipwright && git checkout -b my-change
uv sync
# the whole suite, lint and types
uv run pytest
uv run ruff check . && uv run mypy
cd web && npm install && npm run lint && npm run build
# push and open a pull request
git push origin my-change
FAQ

Questions, answered

Is Slipwright free?

Yes. Slipwright is open source under the Apache 2.0 license. You pay only for the model API calls your agents make, with your own keys.

How do I install Slipwright?

Run the published Docker image with the command above, create the first login with docker exec -it slipwright slipwright user add <name>, and open http://localhost:8500. A “Getting set up” card on the dashboard walks you through the rest.

Which AI models does it support?

Anthropic Claude, OpenAI GPT, Google Gemini, DeepSeek, Alibaba Qwen, Z.ai GLM, MiniMax, OpenRouter and EVREN work out of the box, and each agent can be pinned to its own provider and model. On a self-run install, agents can also use a ChatGPT subscription through OpenAI's Codex CLI.

Does my code leave my machine?

Slipwright runs on your machine or server. Code is sent only to the model providers you configure, and pushed only to your own GitHub or Bitbucket repository.

Can I try it without API keys?

Yes. Set SLIPWRIGHT_PROVIDER=scripted to run the whole pipeline on canned model replies. A new account also starts with Example: a Notes app, a finished development to read before you run one of your own.

What happens if the server stops mid-development?

Nothing is lost. Every step is written to the database before the next one runs, so running work carries on and work waiting for you keeps waiting.

Is it open source? Can I contribute?

Yes. The full source is on GitHub under the Apache 2.0 license. Open an issue for bugs and ideas, or fork the repository and send a pull request.

Can I run it for a team or as a hosted service?

Yes. Switch to PostgreSQL, run every command in a throwaway container with SLIPWRIGHT_RUNNER=docker, and turn on sign-up, per-account keys and quotas. None of it is on by default, so a local install stays a single command.

Put a team to work. Keep the final say.

Self-hosted, open source and running on your own keys. One command to start.

Get the Docker image Star on GitHub