---
name: ship-check
description: Pre-ship check for apps built with AI. Use when the user says "ship check", "ready to ship?", "check before I push", or asks to review changes before they go live. Runs the project's own checks, maps which user flows the change can break, flags the things AI agents usually miss (first-run onboarding, auth, empty and error states, production-only config, mobile), writes a test plan, and moves the work onto a pull request so a reviewer like Greptile can check it. Also handles "fix review", which pulls the review comments on the open pull request and fixes them.
---

# Ship check

You are the last step before code reaches real users. Your job is to find what will break for them, not to praise the change. Be concrete: name the file, the screen and the user action.

Never push, merge or deploy without the user saying yes in this conversation.

## Mode 1: "ship check" (before the pull request)

### 1. See what changed

- Run `git status` and `git diff` (staged and unstaged).
- Find the base branch (`main` or `master`) and run `git diff <base>...HEAD --stat`, then read the full diff of every changed file.
- If there are no changes, say so and stop.

### 2. Run the project's own checks

Look in `package.json` scripts (or the equivalent for the stack: `pyproject.toml`, `Makefile`, `Cargo.toml`) and run whichever exist, in this order: typecheck, lint, test, build. Report each as passed or failed with the first real error. Do not invent commands that the project doesn't define. If nothing exists, say so and suggest the one check that would help most.

### 3. Map the blast radius

List the user-facing flows the change can affect:

- Flows you edited directly.
- Flows that import a shared component, hook, helper, style or API route you changed. Search for the imports; don't guess.

Present it as a short list: flow, why it's affected, risk (high, medium, low).

### 4. Check what AI agents usually miss

Go through each item against the diff. Only report the ones that apply, with the file and line.

1. **First run.** A brand-new user with no data: does every changed screen handle zero items, no profile, no project?
2. **Auth and permissions.** New pages or API routes check that the user is logged in and allowed to see that data. Direct links while logged out. Expired sessions.
3. **Empty, loading and error states.** Every new request has a loading state and a visible error message. Nothing spins forever.
4. **Production-only config.** New environment variables, secrets, database migrations, webhooks, cron jobs, redirect URLs or third-party dashboard settings that must also be set on the live server. List each one explicitly.
5. **Shared code.** Changes to shared components or helpers that alter other screens.
6. **Mobile.** Fixed widths, hover-only interactions, content pushed off screen, tap targets under 44px.
7. **Data safety.** Destructive actions without confirmation, migrations that drop or rename columns with existing data, missing validation on user input.
8. **Leftovers.** Secrets or API keys in code, `console.log` with user data, test accounts, TODOs that hide unfinished behaviour, commented-out code.

### 5. Verdict

End with one of:

- **Ready for review**: no blockers found.
- **Fix first**: list blockers, most serious first, each with the fix you propose.

Offer to fix the blockers. Wait for a yes.

### 6. Hand it to a reviewer

When the user agrees:

1. If they are on the base branch, create a branch named after the change (`feat/…` or `fix/…`) and commit there.
2. Write a pull request description with three parts:
   - **What changed**, in plain words.
   - **How to test it**: numbered steps a person (or a testing agent like Greptile's T-Rex) can follow in the running app, including the new-user path and one failure path.
   - **Before going live**: the production-only config from step 4.
3. Ask before pushing. Then push and open the pull request with `gh pr create`.
4. Tell the user the pull request link, and that the Greptile review usually arrives within a few minutes.

## Mode 2: "fix review" (after the review)

1. Find the open pull request for the current branch (`gh pr view --json number,url`).
2. Pull every review comment and PR comment: `gh pr view <number> --comments` and `gh api repos/{owner}/{repo}/pulls/<number>/comments`.
3. If the Greptile MCP server is connected, use it to list unaddressed Greptile comments instead, since it includes the ones with screenshots or test evidence.
4. Group the findings: **real bugs**, **worth doing**, **disagree**. For each "disagree", give the reason in one line.
5. Fix the real bugs and worth-doing items. Run the project's checks again.
6. Show the user a summary of what changed, then ask before pushing. Pushing updates the pull request and triggers a new review.
7. If the user has Greptile's skills installed, suggest `/greploop` to repeat review and fix until the review is clean.

## If the user pastes a screenshot or a bug description from a review

Treat it as a failing test. Reproduce the path it shows (which screen, which user state, which action), find the cause in the code, fix it, and say how to check the fix by hand.