Shippie: a prebuilt code review agent built on flue and pi

The gap Shippie fills between a linter and a human reviewer

A linter catches what a rule can express. A human reviewer catches the rest: a secret pasted into a config file, an edge case nobody handled, a query that will be slow at scale. Shippie targets that second category. The README lists exposed secrets, slow or inefficient code, and potential bugs or unhandled edge cases as the kinds of issues it picks up. The framing matters: this is not a static analysis tool with a rule pack, it is an agent that reads a diff and decides what to comment on. The audience is teams that already run pull request review on GitHub or GitLab and want a first pass before a person looks. The project was previously called Code Review GPT, so the rename to Shippie reflects a scope that now includes QA and external tool access through MCP, not just review comments.

The agent loop runs on flue and pi, not on a hand-rolled tool registry

The mechanism is stated plainly in the README's ethos section: the agent loop runs on flue plus pi, and Shippie functions as a human code reviewer using flue's built-in tools instead of a hand-rolled tool registry. That is the architectural decision that separates it from most review bots. Rather than defining a fixed set of functions the model may call, Shippie inherits the tool set from the framework and lets the agent explore the codebase the way a developer would. The data flow implied by the documentation is: a diff enters, the agent reads it, calls tools to explore the repository, and emits focused review comments. Shippie can also act as a Model Context Protocol client, which means the agent can reach external tools such as browser automation, observability and documentation. The README points to a dedicated subagent tool that delegates work to flue subagents via a task tool. Provider-agnosticism is part of the same design: Anthropic, OpenAI, OpenRouter and Cloudflare Workers AI are supported out of the box.

Getting it running: an init command, a workflow file, and named inputs

There are three entry points. For GitHub Actions, run npx shippie init to scaffold the workflow, then add a provider API key as a repository secret. The README also shows the manual form: a workflow triggered on pull_request, with permissions for pull-requests: write and contents: read, a checkout step using actions/checkout@v4 with fetch-depth: 0, and a step using mattzcarey/shippie@v0 with GITHUB_TOKEN and ANTHROPIC_API_KEY in env. The full checkout depth is not optional padding; the agent needs history to explore the codebase. The action accepts MODEL, THINKING_LEVEL, IGNORE, CUSTOM_INSTRUCTIONS and MCP_SERVERS as inputs, documented in docs/action-options.md. For local use, npx shippie review runs the workflow with no server, reviews staged changes via git diff --cached, and writes results to .shippie/review/local_*.md. For on-demand runs, commenting /shippie review on a pull request triggers the review either through a GitHub Actions workflow or a deployed webhook channel. Project context can be injected through AGENTS.md or CLAUDE.md rules files. Development targets Node >= 22.19 with npm, and the scripts include npm run review, npm run dev, npm run build (which emits dist/server.mjs, served with npm run start and POSTed to /workflows/review?wait=result), npm run check for oxlint and oxfmt, npm run check:types for tsc, and npm test.

Where the design costs you: LLM review is non-deterministic and provider-bound

The obvious limitation is the one the README does not dwell on: the review is produced by a language model, so the same diff can yield different comments on different runs. There is no rule identifier to suppress, no exit code that fails a build on a specific finding, and no way to prove a given class of bug will always be caught. That makes Shippie a poor fit as a required status check unless you accept that its verdict is advisory. The second constraint is the provider key. Every supported path (Anthropic, OpenAI, OpenRouter, Cloudflare Workers AI) sends your diff and whatever the agent reads from the repository to a third-party endpoint. Teams with source-code egress restrictions should treat that as a blocker rather than a configuration detail, and the README does not describe a local-model path. Third, the GitHub Actions setup requires fetch-depth: 0 and write permission on pull requests; in organisations where workflows run with read-only tokens by default, the action will not be able to post comments until that is changed. Finally, the repository layout and documentation are organised around a small set of docs pages, so anything beyond the listed inputs (MODEL, THINKING_LEVEL, IGNORE, CUSTOM_INSTRUCTIONS, MCP_SERVERS) is not something I can confirm from the material provided.

Compared with a rules-based reviewer like reviewdog

The closest familiar alternative is a rules-based commenter such as reviewdog, which takes output from linters and static analysers and posts it as review comments. The difference in approach is fundamental. Reviewdog does not decide anything; it routes findings that another tool already produced, so its output is deterministic and reproducible, and every comment traces back to a rule. Shippie inverts that: the model decides what is worth commenting on, which is why it can flag an unhandled edge case that no rule covers, and also why it can miss one. If your priority is a fixed, auditable set of checks that fails a build, reviewdog plus your existing linters is the better fit. If your priority is a second pair of eyes on the parts of a diff that rules cannot express, Shippie's agent loop is aimed at exactly that. They are not mutually exclusive, and running both means accepting two different comment streams on the same pull request.

Maintenance surface and what the MIT licence leaves you with

Shippie is published to npm and ships as a GitHub Action pinned in the README at mattzcarey/shippie@v0, so upgrades arrive either by bumping the action reference or by moving the npx shippie version. The release cadence visible in the provided material is active: v0.21.0, v0.21.1 and v0.21.2 all landed within roughly a day of each other in June 2026, with the most recent push to main in September 2026. Pre-1.0 versioning means minor bumps can carry behaviour changes, and because the agent's output is model-generated, a version bump plus a model change can shift review quality in ways that are hard to attribute. That is a real operational cost: you will want to pin the action to a specific tag rather than a floating major if you care about reproducibility. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is not legal advice; if your organisation has policies about model providers or about the licences of dependencies pulled in through flue and pi, check those separately, since the README does not enumerate them.

Who should adopt Shippie, and what to check first

Shippie fits teams on GitHub or GitLab who want an automated first pass over pull requests and are comfortable sending diffs to a hosted model provider. It fits them especially well if they want the agent to reach outside the repository, since the MCP client support and the subagent task tool are the parts that distinguish it from a plain review bot. It does not fit teams that need deterministic, build-failing checks, teams that cannot send source code to Anthropic, OpenAI, OpenRouter or Cloudflare, or teams whose CI tokens are read-only by default. The first thing to verify is not the model quality, it is the plumbing: confirm the workflow checks out with fetch-depth: 0, confirm the job has pull-requests: write, and confirm which provider key the runner reads. Then run npx shippie review locally against your staged changes and read the markdown it writes to .shippie/review/ before you let it comment on anyone else's pull request.

Editorial conclusion

Adopt Shippie if your team already reviews pull requests on GitHub or GitLab and you want an agent that reads the diff and comments without you writing the tool loop yourself. Skip it if you need a deterministic linter, a self-hosted service with no third-party model calls, or a tool that works without an API key from Anthropic, OpenAI, OpenRouter or Cloudflare Workers AI. Before rolling it out, verify three things in your own repository: that the workflow checks out with fetch-depth: 0, that the pull-requests: write permission is granted to the job, and which provider key the runner will actually read.

Official sources

1. License: MIT
2. mattzcarey/shippie on GitHub
3. Project website
4. README
5. Releases