AI code review · CI insight · repository hosting

Code review that reads the whole repository.

Anvil reads every pull request on GitHub or on repositories hosted on Anvil with the whole repository checked out, posts findings on the lines they're about with a fix, and tells you in the PR why a CI job failed.

Request access Read the docs

Invitation only · runs on one server · reviews by Claude

itest.wicker.life/review/alice/shop/52

Layer 2 of 3

Accept endpoint and emails

Token check, account creation, welcome email

TSserver/api/invites/accept.post.ts+18-3

AnvilPotential issue|Major

Expired invites can still be accepted

The check covers used invites but never compares expires_at with the current time, so a link from months ago still creates an account.

Committable suggestion

-if (invite.used_at) throw gone();+if (invite.used_at || invite.expires_at < new Date()) throw gone();

Prompt for AI agents

What it does

One Anvil that reads the code and the CI log.

It works on a real checkout of the repository, so it can follow a call into a file the pull request didn't touch, and it sees what CI said about the same commit.

Findings on the line, with the fix.

Walkthrough and change stack. One comment per pull request, edited in place: a summary, the change split into layers in reading order, a sequence diagram, effort and risk.
Inline findings. Each has a severity, a category, an explanation, a committable suggestion and a prompt you can paste into a coding agent.
Incremental reviews. After a push, only the new commits are reviewed, and open comments aren't repeated. A force-push gets a full review.
Pre-merge checks. Rules in plain language ("every migration is reversible"), judged on every review and reported in the Anvil commit status.
Your settings in the repo. .anvil.yaml sets the profile, path filters, path instructions, auto-review rules and a cost cap.

How reviews work

Anvilcommented · edited

Walkthrough

Adds email invitations: an invites table, an accept endpoint that creates the account, and a members page to send and revoke them.

#LayerFiles

1Invitation data model2

2Accept endpoint and emails (after 1)4

3Members page (after 2)3

Review effort 3/5 (~30 min) · Risk medium · Findings 1 major, 2 minor

Pre-merge checks

Migrations are reversiblepass

Description explains whyfail

Anvil — 3 findings· success

Read a pull request in the order it was built.

Change stack workspace. Layers, files, split or unified diffs, findings inline, and viewed state that resets when a file changes again.
Change summaries. What each changed function or endpoint now does, rated by complexity, so you know where to slow down.
Ask. Private questions about a line or the whole PR. The answer comes from the checkout and stays in Anvil.
Chat and learnings in the PR. Mention @anvil to ask or push back. Rules you teach it apply to every later review of the repository.
Comments post as you. Line comments and reviews from the workspace go to the pull request under your own account.

The pull request workspace

alicecommented

@anvil tokens are checked in the invite middleware, so handlers don't need to check them again. Please stop flagging that.

Anvilreplied

You're right: requireInvite() in server/middleware/invite.ts:14 rejects bad tokens before any handler under server/api/invites/ runs. My comment on line 30 was wrong.

Saved as a learning for alice/shop:

Invite tokens are validated by requireInvite(); don't flag missing token checks in invite handlers.

Know why CI failed before you open the log.

Run history and filters. Every GitHub Actions job and every job on Anvil-hosted repositories, filtered by status, event, user, repository, job, branch and time range.
Failure diagnosis on the PR. The cause, the file and line, the fix and the log lines that matter, in one comment that's updated as CI re-runs.
Flaky jobs. Jobs that failed and passed on the same commit are listed, and the diagnosis says so instead of sending you after a bug.
Runner sizing. Duration and queue time at p50 and p95 per runner label, with plain advice.
Runner pools and caches coming anvil-2cpu, 4cpu and 8cpu pools, a cache next to the runners, and sticky volumes per repository.

How CI insight works

Anvilcommented · edited

CI failed on 9f3c2a1

One job failed: a test still expects the old status code.

test

test failure · src/invites.test.ts:48

accept.post.ts now answers 410 (gone()) for a used invite; the test still asserts 404.

Fix: expect 410 in invites.test.ts:48. The new status is what this PR intends.

FAIL src/invites.test.ts > accept > rejects a used inviteAssertionError: expected 410 to be 404  ❯ src/invites.test.ts:48:31

lint41s

test2m 12s

build1m 30s

Let your coding agent run CI and read the review.

MCP server. Add itest.wicker.life/mcp to Claude Code or any MCP client, with a personal API token.
Run a workflow from a prompt. The agent sends workflow YAML; Anvil commits it to a scratch branch and returns the run.
Wait, read, retry. Tools to wait for a run, read job logs, re-run and cancel.
Reviews as input. The agent can fetch a PR's findings with their agent prompts, fix them, and ask for a new review.

Set up the MCP server

~/shop

$ claude mcp add --transport http Anvil \
    https://itest.wicker.life/mcp \
    --header "Authorization: Bearer $REVIEWER_TOKEN"

> Run the tests on Node 24 before I bump engines.

⏺ anvil.run_workflow(alice/shop, node-24-check.yml)
  ⎿ run 4182 queued on anvil-ci/7f2a
⏺ anvil.wait_for_run(4182)
  ⎿ failure · test · 1m 52s
⏺ anvil.get_job_logs(4182, test)
  ⎿ TypeError: punycode is not a function

⏺ One test fails on Node 24: src/url.ts uses the
  removed punycode module. Switch to node:url's
  domainToASCII and the suite passes.

Runner

ubuntu-latest

also ubuntu-24.04

Concurrency

5 jobs at once

across the server

Per job

4 CPU · 8 GB

1 h timeout

Review cap

per run, lower it per repo

Runner time

0 min

used by reviews

Setup

1 step

add the bot as collaborator

How access works

Invitation only, four steps.

Anvil is a small, private setup. There's no public sign-up; you ask, and we invite you.

01Request accessTell us who you are and what you'd use it for.
02We send an inviteBy email, if it's a fit.
03Sign inFrom the invite link, with your email address or GitHub.
04Connect a repositoryInstall the Anvil app on GitHub repositories, or create a repository on Anvil, then open a pull request.

Request access Getting started

FAQ

Questions people ask first.

More in the docs FAQ and on security and data.

Where does my code go?

It's cloned onto your server, Anvil's server, for the length of a review, and deleted afterwards. The diff, the files Anvil reads, the PR description and CI log tails are sent to Anthropic's API to write the review. Nothing else receives it.

What does it cost?

There are no seats or plans. Every review is an Anthropic API call with a hard cap: $3 per review and $1 per question, inside a monthly budget per account, and you can set a lower cap per repository. The cost of each run is shown in the PR and in the dashboard.

Which code hosts does it work with?

GitHub: install the Anvil app on the repositories you choose, and reviews appear on your pull requests there. Or host the repository on Anvil itself. GitLab is not supported yet.

Can it change my code?

No. It reads the repository with read-only tools and never pushes. Each finding comes with a suggested change and a prompt you can hand to your own coding agent.

Do I have to set up a workflow or webhook?

No. On GitHub, installing the app is all it takes; on a repository hosted on Anvil, turn reviews on in Settings → Repositories. The next pull request is reviewed. Reviews don't use CI minutes.

Anvil

Open a pull request. Get a review in minutes.

Request access Sign in

21	const invite = await findInvite(body.token);
22	if (!invite) throw notFound();
23	-const user = await createUser(body);
23	+if (invite.used_at) throw gone();
24	+const user = await createUser(invite.email, body);