Issues in. Releases out.

Coding agents can write a fix. Shipmill does the rest: it triages the issue, lands the pull request on green CI, cuts the release your policy allows and tells the person who reported it. The agents run on your machine. Every decision stays in your repo.

GitHubGitLab · soon
issues in #314 #313 triage fix land CI green shipmill.toml v0.41.2 stable releases out PyPI · GitHub

Shipmill runs on Shipmill

Issue to release in 23 minutes, with nobody watching

This is one morning on Shipmill's own repository. The agent checked the issue against main, wrote the fix with a test, reviewed it in its own worktree and merged it once CI went green. Then the policy cut the release, published it and told the issue.

Every step left a comment, a label or a tag on the issue, so you can audit the whole run from one page.

shipmill/shipmill · 9 Oct 2026 · UTC● shipped
  1. issue#312 opened: a headless session loses Bash mid-landing
  2. triageVerdict implement, checked against main, the rest postponed with reasons
  3. fixPull request #313 opened with the fix
  4. landReviewed, CI green, merged
  5. release0.41.2 cut on the stable lane, published to PyPI
  6. watchIssue told: “Released in v0.41.2.”
23 minfrom issue to a release people can install

How it works

Seven stations from a report to production

Agents do the judgment work; plain CI and the shipmill CLI do the releasing. The release side works without the agents, so you can start there.

  1. Intake

    agent

    Feature requests and discussions grouped into opportunities you accept or decline

  2. Triage

    agent

    A verdict on every issue (implement, feature, postpone, clarify), with a comment and labels

  3. Fix

    agent

    The issue verified against main, fixed with a regression test, opened as a pull request

  4. Land

    agent

    Each pull request reviewed in its own worktree, small problems fixed, merged only on green CI

  5. Release

    policy

    Cut on its lane when the policy says one is due, CI run on that exact commit, tagged and published

  6. Deploy

    policy

    Health checks, bake time, promotion between environments, rollback that opens an incident

  7. Watch

    agent

    A stalled release, a missing upload, an unannounced fix: reported and finished

You stay in charge

Turn each stage up as you start to trust it

Every stage runs at observe, propose or act. Start with agents that only comment, then let them open pull requests, then let them merge. One file, shipmill.toml, holds the whole policy and goes through review like any other code.

Ask shipmill status what needs you. It answers stuck, waits on you, working or idle, with a link to each item.

example: a team two weeks in
Triageobserveproposeact
Fixobserveproposeact
Landobserveproposeact
Releaseobserveproposeact
Deployobserveproposeact

One issue stops everything

Open a shipmill-hold issue, from your phone if you must, and no agent or lane moves until you close it.

Release lanes

Most users get releases that real users already ran

Each pull request adds its own CHANGELOG entry, and the entries decide the next version. Installers skip dev and rc unless asked, so someone who needs a fix today pins the pre-release while everyone else waits for a stable one that soaked.

dev
1.5.0.dev410.dev411.dev412

From main after every batch of merges

rc
1.5.0rc11.5.0rc2

From main each workday morning

stable
1.4.01.5.0

An rc that soaked without a blocker

hotfix
release/1.41.4.1

The pull requests you name, by hand only

Point it at one repo

Run this in the repo with Claude Code. Setup asks which lanes you want and opens a pull request; releases stay in dry run until you switch them on.

claude plugin marketplace add shipmill/shipmill && claude plugin install shipmill@shipmill && claude "/shipmill:shipmill-setup"