Ship Ready

---
name: ship-ready
description: Production-readiness audit for web apps against a 111-item checklist (rate limiting, timeouts, retries, idempotency, secrets, backups, migrations, CORS/XSS/SQL injection, logging, alerts, cost and more), tiered by what actually matters at the app's stage. Use when the user asks whether an app is production ready, wants a pre-launch or pre-client review, asks to "ship-check", "audit" or "harden" a web app, or is adding LLM/agent calls, webhooks, payments, cron jobs or a database to a web app.
---

# Ship Ready

Audit a web app's codebase against the ship-ready checklist and report what is missing, with evidence, in the order it should be fixed.

The goal is not to make every app look like a big company's. Most of the 111 items are ⚪ for most apps. The value is in finding the handful of 🔴 gaps that will hurt this week.

## Tiers

| Tier | Meaning | Treatment |
|---|---|---|
| 🔴 **Now** | Bites small apps today: hosted platforms, a managed Postgres, AI agents calling LLM APIs | Check deeply, every one |
| 🟡 **Growing** | Matters once there are paying clients, real traffic or a second developer | Check briefly; flag only real gaps |
| ⚪ **Later** | Big-company scale. Know the word, skip the work | Mark 💤 unless the code already needs it |

## Modes

The user may name a mode; default to `quick`.

- `quick`: 🔴 items plus 🔴 bonus items. The everyday pre-launch check.
- `full`: all 🔴 and 🟡 items; ⚪ items get one line each.
- `<term or number>`: deep dive on one item, e.g. `idempotency` or `#14`.
- `diff`: only items touched by the current branch (`git diff main...HEAD`). Good before merging a feature.

## Workflow

1. **Profile the app.** Read the package manifest(s), framework config, hosting files (`vercel.json`, `netlify.toml`, `fly.toml`, `Dockerfile`, `docker-compose*`, `render.yaml`), `supabase/`, `prisma/`, `drizzle/`, `migrations/`, `.github/workflows/`, `.env.example`. Write a profile of at most five lines: framework, hosting, database, auth, external calls (LLM providers, payments, email), async work (cron, queues, webhooks).

2. **Settle the stage.** Use what the user said. Otherwise infer it and say so:
   - *prototype*: no production domain, no real users. Check only secrets, auth, injection and backups among the 🔴 items.
   - *launched* (default): real users or clients. Use the tiers as written.
   - *scaling*: several instances, a team, sustained traffic. Treat 🟡 as 🔴 and check ⚪ items briefly.

3. **Run the scanner.** `bash <this skill's dir>/scripts/scan.sh <repo root>`. It is read-only and prints grep leads grouped by item number. Leads are not verdicts: open each relevant hit before judging. Secret values are masked; keep it that way.

4. **Check the items.** For each section in scope, load its reference file (map below) and follow each item's **Look for** and **Pass** lines. Read the code paths that matter (API routes, server actions, LLM clients, webhook handlers, DB access, cron entry points), not just the grep hits.

5. **Write the report** in the format below.

6. **Offer fixes.** Don't edit code during the audit unless the user asked for that. After the report, offer to fix the "Fix first" items one at a time, smallest diff first.

## Reference map

| Items | Section | File |
|---|---|---|
| 1–14 | Traffic and resilience | [references/01-traffic-resilience.md](references/01-traffic-resilience.md) |
| 15–24 | Async and real-time | [references/02-async-realtime.md](references/02-async-realtime.md) |
| 25–40 | Data and concurrency | [references/03-data-concurrency.md](references/03-data-concurrency.md) |
| 41–50 | Runtime, scaling, caching | [references/04-runtime-scaling.md](references/04-runtime-scaling.md) |
| 51–57 | Releases | [references/05-releases.md](references/05-releases.md) |
| 58–66 | Observability | [references/06-observability.md](references/06-observability.md) |
| 67–80 | Security | [references/07-security.md](references/07-security.md) |
| 81–87 | Schema, backups, recovery | [references/08-schema-recovery.md](references/08-schema-recovery.md) |
| 88–100 | Cost, performance, network | [references/09-cost-performance-network.md](references/09-cost-performance-network.md) |
| 101–111 | APIs, infrastructure, people | [references/10-apis-infra-people.md](references/10-apis-infra-people.md) |
| B1–B8 | Modern stack bonus (LLMs, RLS, auth) | [references/11-bonus-modern-stack.md](references/11-bonus-modern-stack.md) |

## Statuses

| | Status | Use when |
|---|---|---|
| ✅ | Pass | Evidence in code or config. Cite it. |
| ⚠️ | Partial | Some paths are covered and some are not. Cite the gap. |
| ❌ | Missing | It applies and nothing handles it. Cite where it should be. |
| ❓ | Can't tell from code | It lives in a dashboard or a habit (backups, alerts, spend caps, restore drills). Ask one concrete question. |
| ➖ | N/A | Doesn't apply to this stack. Say why in under ten words. |
| 💤 | Not yet | ⚪ at this stage and nothing in the code needs it yet. |

## Rules

- Every ✅, ⚠️ and ❌ cites `file:line`. No citation means ❓, never a guess.
- Never print a secret value, not even partially. Report the file, line and kind of key.
- Platform defaults count, with a note: Vercel, Netlify and Cloudflare give TLS, CDN and basic DDoS protection; managed Postgres gives encryption at rest. Mark ✅ "(platform)" but still check for config that undoes them (a custom server without TLS, a public bucket).
- Weigh blast radius: money moving twice, data leaking across users, a total outage and a silent agent failure rank above slowness or style.
- Prefer the smallest fix that closes the gap, using a library already in the project before suggesting a new one.
- Don't pad. A static site with no backend has most items ➖; say so in one line per section and spend the words on what applies.

## Report format

```markdown
# Ship-ready report: <app> · <stage> · <mode>

**Profile:** <framework> on <host> · <database + auth> · <external APIs> · <async work>

**Score:** 🔴 <passed>/<applicable> · 🟡 <passed>/<applicable> · ⚪ <n> not yet

## Fix first
1. ❌ **<Item> (#n)**: `<file:line>` <what is wrong and what happens when it goes wrong>. Fix: <one line or a short snippet>.
(at most five, ordered by blast radius, then by ease)

## Results
| # | Item | Tier | Status | Evidence / note |
|---|---|---|---|---|
(🔴 rows first, then 🟡, then ⚪ collapsed into one line per section)

## Questions only you can answer
- <one line each, for every ❓>
```

See [examples/sample-report.md](examples/sample-report.md) for a filled-in report.