First time on the repo? The /welcome page is the why before this is the what.
00—— NAMED-STACK TEARDOWNS · MIT · FREE

The defaults vibe-coding ships broken.

Five stacks scoped — Lovable, v0, Bolt.new, Cursor, Replit Agent — with human-audited teardowns of real outputs. The companion specialist runs in your Claude Project: it navigates the case files, generates pre-flight checklists, walks through severity grading. It does not audit your code. The first Lovable teardown is in production; index page pending teardown #2.

5stacks covered
teardowns live
12cross-stack failure shapes
5specialist jobs
MITlicense
02—— THE FIVE STACKS

Five named vibe-coding tools. One library each.

Each stack's pattern library is scaffolded with the structural template. Pattern claims fill in as teardowns accumulate — a pattern entry requires N=3+ independent teardowns of that stack confirming the same failure shape. Until that threshold is met, observations stay in the individual teardowns and the per-stack pattern files hold the scaffolded structure. Generic AI-audit checklists describe vulnerability classes; this library names tool-default patterns specific to the stack that produced them.

Stack 01 · Lovable.dev
lovable

React + Supabase + Tailwind scaffolder. Browser-based, prompt-driven, full-stack output. Pattern library scaffolded; awaits teardown-grounded fill.

Stack 02 · Vercel
v0

UI-first React + Next.js component generator. Server-action surface plus client component output. Pattern library scaffolded; awaits teardown-grounded fill.

Stack 03 · StackBlitz
bolt.new

In-browser full-stack scaffolder via WebContainers. Preview-environment delta from production deploy. Pattern library scaffolded; awaits teardown-grounded fill.

Stack 04 · Anysphere
cursor

Agentic Composer mode in the Cursor editor. Mixed human-edited and AI-generated codebase shape. Pattern library scaffolded; awaits teardown-grounded fill.

Stack 05 · Replit
replit/agent

Cloud-hosted agentic builder in Replit. Hosted-deploy default configuration distinct from self-hosted. Pattern library scaffolded; awaits teardown-grounded fill.

Plus the cross-stack baseline: 12 patterns observed across stacks — a slim baseline so the specialist can cross-reference patterns that recur regardless of which tool generated the code.

03—— TEARDOWN INDEX

Browse the case files.

Each teardown follows the same structure: header (stack, audit date, app type), severity summary, findings (with rubric application), methodology adherence, consent + disclosure timeline. Template at teardowns/_TEMPLATE.md.

· teardown index pending ·
The first teardowns are in production. Lovable leads the queue.

Empty is correct at scaffold time. Pattern claims require N=3+ teardowns per stack before they're added to the per-stack pattern files. When the first teardown lands, the row template is: ID · stack · app type · audit date · highest severity · findings count · read →.

04—— THE SPECIALIST · 5 JOBS

The repo is also a specialist. It navigates the case files.

Load the repo into a Claude Project; the specialist holds the register of a trusted senior auditor and routes your request to one of five named jobs. The specialist does not audit your code. The library tells builders what to look for; it doesn't look for them. That refusal is the differentiation moat against the saturated auto-auditor lane.

JOB 01 · brief

Brief me on a stack

Trigger phrase: "Brief me on Lovable." Output: ranked failure patterns from patterns/<stack>-default-failures.md, severity-tagged, with the first teardown to read.

JOB 02 · walkthrough

Walk me through a teardown

Trigger phrase: "Walk me through TD-LV-001." Output: linear walkthrough mirroring the teardown's section order. Anonymized excerpts clarified; fix-pattern shapes surfaced.

JOB 03 · severity

Severity Q&A

Trigger phrase: "Is this finding CRITICAL or HIGH?" Output: the 5-question rubric applied to your scenario top-to-bottom, with verdict per methodology/severity-rubric.md.

JOB 04 · pre-flight

Pre-flight checklist

Trigger phrase: "Give me a pre-flight for my Lovable SaaS." Output: a personalized checklist with severity tags and "check yourself" vs. "hire someone" markers. Does not run on your code.

JOB 05 · methodology

Methodology walkthrough

Trigger phrase: "How do you do these audits?" Output: overview of the 6-step process, anonymization rules, severity rubric. You pick which document to deep-read.

REFUSALS

Six refusal gates — load-bearing one is Gate 1

Gate 1: Never audit user code directly. If you paste your code, the specialist refuses with verbatim language and offers a pre-flight checklist instead. Gates 2–6 cover: never invent findings, never make legal/regulatory determinations, never name real apps, never claim AI replaces human audit, never pre-sell a paid service. Full text in rules.md.

05—— METHODOLOGY

Six steps. Same six every time.

Every teardown follows the same audit protocol. The point isn't to be clever — the point is reproducibility. If you can repeat these six steps on your own scaffold, you can run the audit on your own code (or hand the methodology to someone you hire).

01 —— INTAKE

Intake the target

Characterize the app before touching it: stack, data classes, auth shape, payment flow, third-party integrations. Time-box and scope agreed with the owner.

02 —— MAP

Reachability map

Enumerate the externally-reachable surface. Every route, every request type, what's exposed unauthenticated. The route table is the audit's spine.

03 —— SCAN

Credential surface scan

Find credentials reachable from the browser or otherwise leaked. Bundle grep, localStorage inspect, JWT decode. Service-role-key-in-client is the canonical finding.

04 —— ISOLATE

Data-isolation check

Confirm user A cannot read or write user B's data. Two test identities, direct API calls with mismatched IDs. The longest step on most audits.

05 —— PROBE

Input-handling check

For every form / API input: injection payloads, missing/oversized/wrong-type input, rate-limit testing. Webhook signature + idempotency are separate checks.

06 —— WRITE-UP

Write up + anonymize

Fill the teardown template. Anonymization gate before submission: a reader who knows the live app shouldn't recognize it from the teardown alone.

Full methodology at methodology/how-we-audit.md · anonymization + consent at methodology/how-we-anonymize.md · severity rubric at methodology/severity-rubric.md.

06—— RUN THE SPECIALIST IN YOUR CLAUDE PROJECT

Five steps. No install, no API key, no cost beyond your Claude subscription.

The repo loads as-is into a Claude Project. The specialist reads identity.md, rules.md, examples.md, welcome.md, all patterns/*.md, all teardowns/*.md, all methodology/*.md.

01
Fork or clone the repo

git clone https://github.com/<handle>/vibe-code-audits.git

02
Open Claude → Projects → New Project

Name it whatever fits. "Vibe Code Audit Navigator" is the canonical name.

03
Upload the repo contents as project knowledge

The full file set goes into the project. As new teardowns merge, pull from the upstream repo and re-upload to refresh.

04
Paste identity.md into project instructions

The field labeled "Custom instructions" or "Project instructions" depending on Claude version. This is what makes the specialist hold its register and routing-table behavior.

05
Open a chat and ask one of the five jobs

"Brief me on Lovable." "Give me a pre-flight checklist." "Walk me through the methodology." Full menu at welcome.md.

Want to run an audit on your own scaffold? The 6-step methodology above is reproducible by hand. The specialist won't run it on your code; you run it yourself, or you hand the methodology to someone you hire. Patches in teardowns are MIT-licensed — copy, adapt, ship.

07—— FAQ

What this repo is and isn't.

Can I paste my code and get a security review?
No. The library tells builders what to look for; it does not look for them. That's the differentiation moat. The specialist offers a pre-flight checklist (Job 4) for your stack instead — that's the on-scope alternative.
Is this a paid audit service?
No. The repo is free, MIT-licensed, and intentionally non-commercial.
Is this a replacement for hiring an auditor?
No. Pattern recognition is upstream of an audit, not a substitute. The library tells you what categorical patterns to look for; confirming whether your specific app has those failures is human-audit work — yours, or someone you hire.
Why named stacks instead of a generic AI-audit checklist?
Generic checklists describe vulnerability classes — SQL injection, XSS, auth bypass. Named-stack teardowns describe tool-default patterns — "Lovable's onboarding wizard ships service-role connections client-side." Generic advice doesn't tell you where to look first. Named patterns do.
Will you take down a teardown if a stack patches the default?
No. The teardown updates to reflect the new default and adds a "patched on YYYY-MM-DD by <stack>" note. The original finding stays as historical context. Anyone running an older scaffold version still needs the patch.
Will you tell me if a specific real app is safe?
No. Teardowns are anonymized; live-product naming is out of scope. If you're worried about a specific real app you use, the pre-flight checklist for its stack will surface the categorical patterns to look for.
How do I contribute a teardown or report a new pattern?
Open an issue or PR on GitHub. The contribution flow is documented in CONTRIBUTING.md. Documented consent (Category A or B), methodology adherence, anonymization gate — same bar as internal teardowns.
Why MIT and not something more restrictive?
MIT is permissive enough. The patches and methodology should be reusable, attribution preserved, no warranty implied. If you fork it and ship it inside your own audit practice, that's the design.
08—— WANT YOURS AUDITED?

The reproducible methodology is the answer.

Right now there's no paid audit service to sell you. The 6-step methodology is what you'd run yourself, or hand to someone you hire. The library stays free under MIT regardless of what future layers launch.