A factory that turns a GitHub issue into a ready-for-review pull request, or on request a merged one, by running unattended agent sessions. The humans are the day shift; the agents work the third shift, overnight, while you do something else.
Quality over quantity: a pull request marked ready for review is one the factory stands behind. When it can't stand behind the work, it preserves the work and leaves a draft.
Read the user manual here on GitHub or on thirdshift.app. Both come from the same Markdown. For a visual introduction, see How thirdshift works.
curl -LsSf https://github.com/JacobStephens2/thirdshift/releases/latest/download/thirdshift-installer.sh | shThe installer puts a single binary in ~/.local/bin; no Rust toolchain or checkout of this repo is needed. Supported: x86_64 Linux (Rocky, Ubuntu and WSL2) and Apple Silicon macOS. See supported versions and other installation methods.
Have git and authenticated gh and a Harness installed: Claude Code by default, or Codex, Antigravity CLI, Grok Build, Muse Code or OpenCode. Set git's user.name and user.email and make sure it can push. Prerequisites and permissions covers setup and access: sessions run unattended as your user, with access to that account's files, credentials and tools.
thirdshift setup # choose defaults
thirdshift update # update a shell-installer copyFrom a clone of the issue's repository, on the branch you want the pull request to target:
cd ~/repos/widgets
thirdshift https://github.com/acme/widgets/issues/7The Run works in its own worktree, implements and reviews the issue, opens a pull request, and keeps it mergeable and green. It leaves the pull request ready for your review; thirdshift merge <Issue URL> also merges it. Your checkout's uncommitted changes stay out of the Run. Push any Base branch commits first.
Use thirdshift help for the command reference, or read Run behavior, command options and failure recovery.
| Start with | Workflow and details |
|---|---|
| One GitHub issue | Run and Merge run |
| An issue with sub-issues | Spec run: works through Tickets in dependency order |
| Architecture improvements | Architect run: reviews, publishes a plan and builds it |
| An issue marked ready | Pickup run: takes the lowest-numbered Ready issue |
| A security audit | Security run: records findings privately; can fix one reproduced finding |
The operating system schedules Architect, Pickup and Security runs. See scheduling, Weeding and Fencing.
- Configuration, Harness, Model and Effort, and email notifications.
- Machine status, showing Commands and reading logs, and stopping a Command.
- Building and testing and releasing.
- Exact prompts and Factory skills, also readable on the site.
- Domain vocabulary and architectural decisions.
- Open issues for known gaps and planned work.
Released under the MIT License. Factory skills include work by Matt Pocock, Dex Horthy and Cloudflare. See full credits and license notices.
Links from the former README manual
These section links keep older bookmarks useful. The complete explanations now live in the user manual.
- What a Run does
- The Claim
- When the Claim ends
- Status
- Machine status
- Show and read one Command
- Updating
- Supported platforms
- Prerequisites
- Unattended sessions
- What sessions leave behind
- Usage and cost
- User config
- Harness, Model and Effort
- Run notifications
- Stopping a Command
- Logs
- Foreign commits in a Merge run
- Base fix
- One Base fix per Base branch
- Continuation
- Failed runs
- An Inherited failure links the Base branch's checks
- Spec runs
- Architect runs
- One Run notification
- No Strong candidate
- An Architect idea waits for triage
- A Ready issue goes first
- One at a time
- One Architect plan at a time
- On a schedule
- Weeding
- Security runs
- Security review
- Fencing
- Pickup runs
- The Claim limit
- The Sweep
- Why an issue was passed over
- One Run notification for the issue taken
- A Pickup run on a schedule
- Building from source
- The Rust version
- Releasing