I Built a Claude Code Plugin That Audits Vibe-Coded Apps for Production Readiness
Vibe coding got us shipping in hours. Then the launches started breaking.
AI coding assistants are incredible at getting a working prototype on screen. What they're terrible at is the part that comes after: the quiet, boring, unglamorous work of making sure the thing is safe to put in front of real users. I've watched the same failure patterns repeat across AI-generated apps — broken Supabase RLS policies that leak one tenant's data to another, API keys committed straight into the repo, Stripe integrations that handle the happy path and fall over on webhooks and refunds, auth that lives in the frontend while the API trusts everyone, and public endpoints with no rate limiting at all.
The prototype works. Nobody checked whether it's safe to launch. That's the gap I built prod-readiness to fill.
What it is
prod-readiness is a Claude Code plugin that runs a read-only, whole-repository production-readiness audit. It answers one question: is this app safe to launch?
It works in three stages:
- One shared evidence pass over the repo, so every finding is grounded in actual code, not vibes.
- Eight specialist lenses — security, backend, database, DevOps, QA, frontend, AI security, and runtime — each writing evidence-tagged findings from that shared pass.
- A verdict: SHIP, FIX THEN SHIP, or HOLD. CTO-readable, backed by an absence ledger that distinguishes controls that are confirmed, not found, or unverified.
It's deliberately read-only. It never touches your code — it produces the audit trail under .readiness-audit/ and tells you what's wrong and where. There's also an optional local dashboard if you want to watch the audit run in your browser.
Why a plugin, not another scanner
Keyword scanners catch secrets in code. They don't catch the structural stuff that actually kills launches: missing recovery paths, unsafe trust boundaries, untested webhook handlers, operational blind spots. The eight-lens design exists because production readiness is a systems question, not a grep question. Each lens looks at the same evidence from a different angle, the way a real review team would.
Try it on your own app
You only need Claude Code installed. Three commands:
/plugin marketplace add Taimoorkhan1122/prod-readiness
/plugin install prod-readiness@prod-readiness-marketplace
/reload-plugins
Then point it at any repo and run:
/prod-readiness:production-readiness-audit
If the idea of running a full multi-agent audit makes your laptop fans spin up, there's a sequential mode too:
/prod-readiness:production-readiness-audit sequential
What I'm looking for
This is early and I'm actively improving it. If you vibe-code apps — especially ones heading toward real users and real payments — run it and tell me what it missed. The findings that matter most are the ones I haven't thought of yet.
Repo: https://github.com/Taimoorkhan1122/prod-readiness — stars and issues both welcome.
Top comments (2)
The absence ledger (confirmed / not found / unverified) is the best idea in here. "Not found" and "not there" are different claims, and most scanners collapse them into a green tick.
Two failure classes I'd want a runtime lens to catch, because they don't show up in a static read of the repo:
Stale pooled connections on hosts that scale to zero. The app sleeps, the database drops its side of the connections, and the first request after waking waits on validating dead sockets. We measured 12.7 s on the first request before changing the pool settings (no idle connections, retry once), 2.3 s after. Nothing in the code looks wrong.
"Started" reported as "healthy". A process that boots and then crash-loops a second later can still be marked live by a deploy pipeline that only checks start. Worth a lens that asks: what does this app's deploy consider success, and how long after start does it check?
Also +1 on keeping it read-only. An audit that edits code turns the report into a diff nobody reviews.
Really appreciate this, @mythex The stale pooled connections example is exactly the kind of failure a static read misses, nothing in the code looks wrong until the first request after a scale-from-zero. Adding both of these to the backlog.
The goal is to make the audit as deterministic as I can, so the LLM sits there as the driver rather than the judge.