shipmill/shipmill

**The open-source AI software factory for GitHub.** Agents triage your issues, fix them,
and land the pull requests; release lanes cut, publish, deploy, and roll back by a policy
you write. Everything runs on GitHub, and you stay in charge.
Why shipmill
Coding agents can write a fix. Getting that fix to users is the rest of the work: deciding
which issues deserve one, reviewing the pull request, waiting for green CI, cutting a
release, publishing it, telling the reporter, and noticing when production breaks.
shipmill does that rest, end to end, on any GitHub repository.
- **Issue to release, not just issue to PR.** One pipeline from a new issue to a published,
deployed, and announced release
- **Policy, not prompts, decides what ships.** A single file, .github/shipmill.toml, says
which lanes release and when (dev, rc, stable, hotfix), what gates hold them, and
how far automation may go
- **You stay in control.** Each stage runs at observe, propose, or act; one
shipmill-hold issue, opened from your phone, stops everything
- **No server, no state of its own.** GitHub is the database: issues, labels, pull requests,
tags, deployments; nothing lives outside your repository
- **Releases you can trust.** CI runs on the exact release commit before it is tagged; a
stable release ships the code a pre-release already soaked; a failing deploy rolls back
and opens an incident
How it works
| Stage | Done by | What happens |
|---|---|---|
| Intake | product-intake skill | Feature requests and discussions grouped into opportunities you accept or decline |
| Triage | github-issue-triage skill | A verdict on every issue (implement, feature, postpone, clarify), a comment, labels, one PR per fix; a feature gets a spec first |
| Fix | github-issue-resolve skill | One issue verified against main, fixed with a regression test, opened as a PR |
| Land | github-pr-triage skill | Each PR reviewed in its own worktree, small problems fixed, merged only on green CI |
| Release | shipmill workflows | The release cut on its lane when the policy says one is due, CI run on it, tagged, published |
| Deploy | shipmill operate | Health checks, bake time, promotion between environments, automatic rollback |
| Watch | github-ship-watch skill | A stalled release, a missing upload, an unannounced fix, an untriaged issue: reported and finished |
The skills run in Claude Code, on demand or unattended on
a schedule. The release side is plain GitHub Actions plus the shipmill CLI, and works
without the agents.
Quickstart
You need a GitHub repository with a CHANGELOG.md that has an ## [Unreleased] section,
the gh CLI signed in, uv, and
Claude Code. From the root of your repository:
The shipmill-setup skill inspects the repository, asks which lanes to run, and wires
everything on a branch, ending with a pull request. Releases start in dry-run mode until you
switch them on.
Then ask what needs you:
Without the install, uvx --from git+https://github.com/shipmill/shipmill@v0 shipmill status