Test your app before your users do.
The setup I run before anything I build goes out. Greptile reviews the code and clicks through the app, Claude fixes what it finds, and nothing ships until the review is clean.
Made in partnership with Greptile.
Why the app breaks when the code looks fine
Claude writes code that works on your screen, with your account and your data. Your users don't have any of that. These are the six places it breaks most often.
Onboarding and first run
The agent tests with your account, which already has data. New users start empty, and that path is the one nobody opens.
A new signup lands on a dashboard that expects a project to exist and shows a blank screen.
Login, logout and permissions
The happy path works, so the agent moves on. Expired sessions, wrong roles and direct links to pages you shouldn't see get skipped.
A logged-out visitor opens /settings from a bookmark and sees another user's data.
Empty, loading and error states
The agent builds the screen with data in it. What happens with zero items, a slow network or a failed request is an afterthought.
The page spins forever when the API returns an error instead of saying what went wrong.
Things that only exist in production
Environment variables, secrets, database migrations and webhooks are set up on your laptop and forgotten on the server.
Stripe payments work locally and fail live because the webhook secret was never added.
Screens you didn't touch
The agent changes a shared component or helper to fix one screen and quietly breaks three others that use it.
A button style change for the new feature breaks the checkout form on mobile.
Phones and small screens
Everything gets built and checked in a wide desktop window. Most of your users are on a phone.
The signup button is pushed off screen on an iPhone, so nobody can finish onboarding.
The loop
Nothing goes straight to users. Every change sits on a pull request, gets reviewed and tested, and goes back to Claude until it's clean.
Claude CodeBuild
Claude writes the feature on a branch.
- GitHub
Open a pull request
The change waits there instead of going live.
- Greptile
Review and run it
Reads the code, then T‑Rex runs the app in a sandbox and clicks through it.
- Claude Code
Fix
Claude fixes what came back, screenshots included.
- Greptile
Review again
Pushing the fix triggers a fresh review.
- Your users
Ship
Merge once the review is clean.
I was adding a new feature to my Content OS app. Greptile sent back a screenshot of a broken onboarding screen, something Claude had completely missed. I sent it back to Claude, it fixed the problem, I ran it through Greptile again, and pushed the update to all my users.
Set it up in 10 minutes
You need your code on GitHub (GitLab, Bitbucket and a few others work too). If you built in Lovable, Bolt or Replit, connect the project to GitHub first.
Create a free Greptile account
Sign up at greptile.com with GitHub. The free Starter plan covers one developer, unlimited repos and 50 credits a month. A normal review costs 1 credit and a T-Rex run costs 3.
Connect your repo
Go to Code Providers, choose Connect GitHub Cloud and install the Greptile app on the repos you want reviewed. Back in Greptile, click Link on your account, pick the repos and click Enable.
Turn on T-Rex
In Settings, open T-Rex and switch it on. This is the part that runs your app in a sandbox, clicks through it and attaches screenshots, videos or logs to the review.
Open your first pull request
Greptile only reviews pull requests. If you've been pushing straight to main, paste this into Claude Code once and it'll set up the habit for you. It uses the GitHub CLI, so install it first (cli.github.com) and run
gh auth login. The first review lands in a few minutes.Prompt: move my work onto a pull requestI've been pushing straight to main. From now on I want every change reviewed before it goes live. 1. Create a new branch for the work I just did, named after what it does. 2. Commit the changes there with a clear message. 3. Write a pull request description with: what changed, numbered steps to test it in the running app (include a brand-new user and one thing going wrong), and anything that must be set up on the live server first. 4. Show me the description, then push and open the pull request with gh. Don't merge anything.Connect Greptile to Claude Code
So Claude can read the review and fix it without copy-pasting. Run the plugin commands inside Claude Code:
In Claude Code/plugin marketplace add greptileai/claude-plugin /plugin install greptile@greptile-claude-plugin /greptile:loginFor the automatic loop, also add the MCP server and Greptile's skills in your terminal:
In your terminalclaude mcp add --transport http greptile https://api.greptile.com/mcp claude mcp login greptile git clone https://github.com/greptileai/skills.git ~/.claude/skills/greptile
Close the loop with Claude
Three ways to get from a review to a clean pull request.
Let it loop on its own
With the MCP server and skills installed, type /greploop in Claude Code. It triggers a review, fixes the comments, pushes, and repeats until Greptile gives the pull request 5/5 with nothing left open, or stops after 5 rounds.
One click from the review
Every Greptile comment has a Fix with your agent button, and the summary has Fix All. It sends the file, lines and suggested fix to Claude Code. It needs npm install -g greptile on your machine.
Paste it in yourself
Works anywhere, and it's the best way to handle a T-Rex screenshot. Paste the comments, drag in the images, then this:
Greptile reviewed my pull request. Here's what it found:
[paste the comments, and drag in any screenshots T-Rex attached]
For each finding:
1. Tell me if it's a real bug, worth fixing, or something you disagree with, and why in one line.
2. For screenshots, work out which screen, which user state and which action produced it, then find the cause in the code.
3. Fix the real bugs and the worth-fixing ones. Run the project's checks.
4. Show me what you changed and how to check each fix by hand.
Then wait. I'll push and let Greptile review it again.Talk to it on the pull request
@greptileai- Review it again, for example after a fix
@greptileai review this draft- Review a draft pull request before it's ready
@greptileai is this safe if two users save at once?- Ask anything about the change
A thumbs down on a comment teaches it what you don't care about. Replying with context works too.
Free downloads
Two files that make the whole loop sharper. Both are plain text, so read them before you use them.
The ship-check skill for Claude Code
Say “ship check” before anything goes to review.
- Runs your project's own typecheck, lint, tests and build
- Lists every user flow the change can break, including screens you didn't touch
- Checks the diff for what AI agents miss: first run, auth, empty and error states, live-only config, mobile
- Writes the “how to test it” steps T-Rex and human reviewers follow
- Moves the work onto a pull request, and asks before it pushes anything
- Say “fix review” afterwards and it pulls the review comments and fixes them
Install by unzipping it into your Claude Code skills folder:
mkdir -p ~/.claude/skills && unzip ~/Downloads/ship-check-skill.zip -d ~/.claude/skills/Review rules for apps built with AI
Tells Greptile to look hardest where AI agents slip.
A .greptile folder for the root of your repo. rules.md points the reviewer at first-run screens, missing auth checks, silent errors, live-only config and mobile. config.json keeps comments to real problems and the tier on Base so T-Rex runs. Changes apply from the next pull request.
The folder is hidden on Mac, so unzip it straight into your project from the terminal:
unzip ~/Downloads/greptile-starter.zip -d .Custom rules are a Pro feature on Greptile ($30 a month, with a 14-day free trial).
One more prompt worth keeping
A reviewer, human or AI, tests better when you tell it how. Run this before you open a pull request and paste the result into the description.
Before I open a pull request, write the "How to test it" section for the reviewer.
Look at the diff against main and list the exact steps to test every user-facing change in the running app:
- as a brand-new user with no data
- as an existing user
- on a phone-sized screen
- when something fails (bad input, no network, logged out)
Also list anything that has to exist on the live server first: environment variables, database changes, webhooks.The pre-ship checklist
The 16 things to check before a change goes live. Tick them off here. Your progress is saved in this browser.
0 of 16 checked
Questions
Is this sponsored?
Yes. Greptile is a paid partner on this one. It's also what I run before I ship my own apps. The prompts, skill and checklist work with any reviewer.
Is it free?
The Starter plan is free for one developer: unlimited repos and 50 credits a month, which is about 50 normal reviews, or roughly 15 with T-Rex on. Pro is $30 a month per developer with a 14-day trial. Open-source projects can apply to use it free.
Does T-Rex test everything?
No. The reviewer decides what looks risky, and T-Rex runs a test for each of those in a throwaway sandbox. It's in beta. For now it mocks outside services like payments instead of using your real accounts, so still test logins and payments yourself with the checklist above.
When does the review run?
When you open a pull request and each time you push to it. That's the point of the pull request: the change is on GitHub and reviewed, but not live yet. You merge once it's clean. To review a branch locally before a pull request exists, run /greptile:review in Claude Code.
Does this replace tests?
It replaces the tests you were never going to write. If you have real tests, keep them: the ship-check skill runs them, and T-Rex uses your existing test setup.
I use Cursor, Codex or Lovable, not Claude Code.
Greptile reviews the pull request, so it doesn't care what wrote the code. The prompts work in any AI tool, and Fix with your agent also supports Cursor and Codex. The ship-check skill is written for Claude Code.
Greptile features and prices from Greptile's docs and pricing page, checked 30 September 2026.