Skip to main content

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.

PyPI Python CI License: MIT

issue ─▶ triage ─▶ fix ─▶ review & land ─▶ release ─▶ deploy ─▶ watch
          agent     agent      agent         policy     policy    agent

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; the decision policy ([decisions]) says which of the agents' decisions they take, tell you about, ask you, or leave to your hand (Who decides); 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 breaking change reaches a stable release only after your decision; 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:

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

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:

uv tool install shipmill  # once; `uv tool upgrade shipmill` after each plugin update
shipmill status

uv tool install shipmill is the one way to put the CLI on your PATH. The plugin runs its own pinned release, so run uv tool upgrade shipmill after each plugin update to keep the two the same; shipmill doctor and shipmill status report a shipmill on PATH whose version differs from the plugin's. Without the install, uvx shipmill status runs the latest release from PyPI.

It answers STUCK, WAITS ON YOU, WORKING, or IDLE, with a link to each item that waits on you. One factory line sums up the machinery on this machine; shipmill factory prints it a line per check: the gate's launchd job, its sessions, the GitHub App, the shipmill installs, the checkout, and the worktrees.

Prefer to set it up by hand, or want only the release lanes without agents? Follow docs/install.md.

Release lanes at a glance

Lane Version Released from Typical trigger
dev 1.5.0.dev412 main's head after every batch of merges
rc 1.5.0rc2 main's head each workday morning
stable 1.5.0 main's head after every green batch, or an rc after every batch of merges, a milestone, or by hand
hotfix 1.4.1 release/1.4 plus the pull requests you name by hand only

Every pull request adds its own CHANGELOG entry, as a fragment file by default so pull requests don't conflict on it; the entries decide the next version. Installers skip dev and rc unless asked, so a user who wants to try a change first pins the pre-release while everyone else gets each stable release; a breaking change waits for you.

Documentation

Read For
Install Prerequisites, every setup step, and how to pause or remove shipmill
Flow What to say to run each stage, alone or all at once
Direction The docs/product.md you write when agents implement: what it holds, what the agents do with it, and how you change it
Release lanes The policy file, environments, operate, autonomy, versions, the CLI, and limits
Decisions The rules shipmill follows and why
Changelog What changed in each release

Status

shipmill is alpha and releases itself with its own workflows, so every release you see on PyPI went through the pipeline described above. Expect the policy keys to change between minor versions; the CHANGELOG says how.

Contributing

Issues and pull requests are welcome. A new feature starts as a spec in docs/specs/; every pull request adds its own changelog entry as a new file in changelog.d/. The checks CI runs are listed in CLAUDE.md.

License

MIT

Metadata

Release files for shipmill 0.87.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for shipmill 0.87.1
File Size Uploaded Provenance Actions
shipmill-0.87.1.tar.gz 1.9 MB Without provenance Details for shipmill-0.87.1.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for shipmill 0.87.1
File Interpreter ABI Platform Actions
shipmill-0.87.1-py3-none-any.whl Python 3 none any Details for shipmill-0.87.1-py3-none-any.whl

Total release size: 2.7 MB

Release files / shipmill-0.87.1.tar.gz

Download URL shipmill-0.87.1.tar.gz
Size 1.9 MB
Tags Source
SHA-256 checksum
How to use checksums
df657072b9ab5f5d6fe7aded9fdb831d3f8a06ee3d96698e2adfcc517db1daa2
BLAKE2b-256 checksum
How to use checksums
1d571203bcba6fad977cb59bfcebf6647b4780127546c429ed9bd3bcf8bd2ccf
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via uv/0.13.6 {"installer":{"name":"uv","version":"0.13.6","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}

Release files / shipmill-0.87.1-py3-none-any.whl

Download URL shipmill-0.87.1-py3-none-any.whl
Size 749.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
399b71943d1d02ca1f3a774cf2a632556df3b772884a529f35bfb272a5c7a20a
BLAKE2b-256 checksum
How to use checksums
0c42caf8e0fe43a20be46f7d470eb593af16468b84143d0c02a33ad40ed39efb
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via uv/0.13.6 {"installer":{"name":"uv","version":"0.13.6","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}

Security for shipmill 0.87.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

0.87.1 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page