skill
ship-ready
Production-readiness audit for web apps, as an agent skill: 111 production terms + 8 modern-stack extras, tiered by stage, checked against your code with file:line evidence.
Set up
Skills are installed by placing their folder where your agent loads skills.
The download comes from github.com/munnangiraveena-beep/ship-ready itself, not from our server, so what you get is exactly what its author published.
Install instructions come from the README
README
synced Oct 26, 2026ship-ready
A production-readiness audit for web apps, as an agent skill.
111 production terms (rate limiting, timeouts, idempotency, backups, CORS, migrations and the rest) plus 8 modern-stack extras for apps built on hosted platforms, managed Postgres and LLM APIs. Each one is tiered by when it actually matters, so you fix the five things that will hurt you this week instead of reading about Kubernetes.
Point your coding agent at a repo and it reads your code, cites file:line evidence for every finding, and tells you what to fix first.
> /ship-ready
# Ship-ready report: invoice-helper · launched · quick
Score: 🔴 12/28 (2 N/A)
## Fix first
1. ❌ Row-Level Security (B2): supabase/migrations/20260903_init.sql:41 creates
`invoices` without RLS. Anyone with the public anon key can read every invoice.
2. ❌ Webhooks (#101): app/api/stripe/route.ts:12 trusts the body with no
signature check, so anyone can POST "invoice paid".
3. ❌ Idempotency (#14): Stripe redeliveries insert duplicate payments.
...
Why a skill and not just a checklist?
A checklist gets read once. A skill gets run: every time you ship a feature, add a webhook or wire up a new agent. It also does the boring part a checklist can't: grepping for fetch( calls without timeouts, finding tables without row-level security, spotting secrets in client bundles, and turning all of that into a short, ranked to-do list.
The checklist is still here for humans: CHECKLIST.md.
The three tiers
| Tier | Meaning | |
|---|---|---|
| 🔴 | Now | Bites small apps today. Check every one. |
| 🟡 | Growing | Matters once you have paying clients, real traffic or a teammate. |
| ⚪ | Later | Big-company scale. Know the word, skip the work. |
The skill shifts tiers with your stage: a weekend prototype gets only the security and backup basics; an app with several instances and a team gets 🟡 promoted to 🔴.
The short list
If you do nothing else:
- Secrets management: keys in environment settings or a vault, never in code, chat or the browser bundle.
- Backups and disaster recovery: database and uploads, off-provider, with a restore you have tested.
- Rate limiting, timeouts, retries, backoff: on every route and agent that calls an LLM or paid API.
- Idempotency: a retry must not double-send, double-charge or double-post.
- Webhooks: verify signatures, deduplicate, log.
- Logging, monitoring, alerts: know an agent died before a client does.
- IAM and OAuth: least access for every person, agent and token.
- Cost optimization: spend caps, the right model per job, no runaway builds.
- Migrations, indexing, row-level security: database basics.
- SQL injection, XSS, CORS, auth on every route: the big holes in AI-generated apps.
Install
Claude Code (plugin)
/plugin marketplace add munnangiraveena-beep/ship-ready
/plugin install ship-ready@ship-ready
Claude Code (manual)
git clone https://github.com/munnangiraveena-beep/ship-ready.git
cp -r ship-ready/skills/ship-ready ~/.claude/skills/ # for all your projects
# or
cp -r ship-ready/skills/ship-ready your-app/.claude/skills/ # for one project, shared with your team
Other agents
The skill follows the open Agent Skills format: a folder with a SKILL.md, reference files and a script. Copy skills/ship-ready/ into wherever your agent loads skills from. Agents without skill support can be pointed at it directly:
Read skills/ship-ready/SKILL.md and follow it to audit this repository.
No agent at all
bash skills/ship-ready/scripts/scan.sh path/to/your-app
prints the raw evidence (grep leads grouped by checklist number), and CHECKLIST.md works with a pen.
Usage
Ask in plain words, or name a mode:
| Say | What happens |
|---|---|
"Is this ready to ship?" / /ship-ready | quick: all 🔴 items, ranked fixes |
| "Full ship-ready audit" | full: 🔴 and 🟡, ⚪ in one line each |
"Ship-ready check on idempotency" / #14 | deep dive on one item |
| "Ship-ready the changes on this branch" | diff: only items the branch touches |
Every finding gets a status:
✅ pass · ⚠️ partial · ❌ missing · ❓ can't tell from code (it asks you) · ➖ not applicable · 💤 not yet
Things that live in dashboards (backups, alert rules, spend caps, who has admin) can't be seen from code, so the skill asks you a concrete question instead of guessing.
What's inside
ship-ready/
├── CHECKLIST.md the human checklist: all 119 items, one line each
├── skills/ship-ready/
│ ├── SKILL.md how the agent runs the audit
│ ├── references/ per-section detail: look for, pass, red flags, fix
│ │ ├── 01-traffic-resilience.md 1–14
│ │ ├── 02-async-realtime.md 15–24
│ │ ├── 03-data-concurrency.md 25–40
│ │ ├── 04-runtime-scaling.md 41–50
│ │ ├── 05-releases.md 51–57
│ │ ├── 06-observability.md 58–66
│ │ ├── 07-security.md 67–80
│ │ ├── 08-schema-recovery.md 81–87
│ │ ├── 09-cost-performance-network.md 88–100
│ │ ├── 10-apis-infra-people.md 101–111
│ │ └── 11-bonus-modern-stack.md B1–B8
│ ├── scripts/scan.sh read-only evidence scanner (bash 3.2+, no dependencies)
│ └── examples/sample-report.md
└── .claude-plugin/ Claude Code plugin and marketplace manifests
The agent loads only the reference files for the sections it is checking, so a quick audit stays fast.
Principles
- Evidence or it didn't happen. Every pass and every failure cites
file:line. No citation means "can't tell", never a guess. - Secrets never leave the file. The scanner prints locations of suspected keys, not values, and the skill never repeats them.
- Smallest fix first. Use what the project already has before adding a dependency.
- Stage-aware. A prototype doesn't need canary releases. An app taking payments does need idempotent webhooks.
Contributing
Corrections, new red flags, better scanner patterns and stack-specific notes are all welcome. See CONTRIBUTING.md.