I Built a Claude Code Plugin That Audits Vibe-Coded Apps for Production Readiness

Introduction

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 Is prod‑readiness?

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.

The plugin is 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.

Getting Started

You only need Claude Code installed. Run these 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

Sequential Mode

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

Feedback & Contribution

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.

Repository

Repo: https://github.com/Taimoorkhan1122/prod-readiness - stars and issues both welcome.