VIBE⌇BRATOR
Take the Vibe Check
The Vibe Check

Is this build ready to ship?

Twelve yes-or-no questions about the code you just vibed. Answer honestly — nobody is watching. Scored on your machine. Nothing is sent anywhere, nothing is stored.

12 questions3 ship-blockers~2 minutesclient-side only
  1. Verifyweight 2

    Did you read every generated file before you ran it?

    Reading is the only step the model cannot do for you. Skipped reading is how a 400-line refactor you never asked for gets into main.

    FixOpen the diff. Read it top to bottom. If it is too long to read, it is too long to accept. Prompt: Stop Refactoring →
  2. VerifyShip-blockerweight 3

    Is there a test for the business logic, and did you watch it fail before it passed?

    A test that has never failed has never proved anything. “It runs” is not “it works.”

    FixAsk for one failing test that pins the behaviour you care about. Run it red, then green. Prompt: Define Done →
  3. SecurityShip-blockerweight 3

    Are there zero secrets in the source and zero in git history?

    A key committed once is compromised forever; rewriting history does not un-leak it. Rotate, then scan.

    FixSearch the repo and history for key-shaped strings. Move everything to environment variables. Rotate anything that was ever committed. Prompt: Security Boundary →
  4. SecurityShip-blockerweight 3

    Does every route check both who the user is and what they are allowed to touch?

    Most generated apps check the ID and forget the badge. Authentication without authorization is a door with a greeter and no lock.

    FixFor each route, name the owner check. If you cannot, the route is open. Add the check server-side, not in the UI. The Stack: the membership desk →
  5. Securityweight 2

    Is every user input validated on the server, not only in the form?

    The browser is the attacker’s computer. Client-side validation is a courtesy, not a defence.

    FixValidate shape, size and type at the API boundary. Reject, do not sanitise into something else. Prompt: Security Boundary →
  6. Verifyweight 2

    Does the app fail loudly — no empty catch blocks, no swallowed exceptions?

    “except: pass” is not error handling. It is a cover-up, and it turns every later bug into a mystery.

    FixGrep for empty catches and bare excepts. Each one either logs with context or re-throws. Prompt: Hand It An Error →
  7. Own itweight 2

    Can you say, in one sentence each, why every dependency the model added is there?

    Models reach for packages the way a nervous cook reaches for salt. Each one is attack surface and upgrade debt you now own.

    FixList the new dependencies. Remove any you cannot justify. Check the rest exist and are maintained — hallucinated packages are a real supply-chain attack. Prompt: Verify The Imports →
  8. Own itweight 2

    Does it run from a fresh clone using only the README?

    If it only works on your machine, you do not have software. You have a demo.

    FixClone into a new folder. Follow the README literally. Every step you had to remember goes into the README. Prompt: Lock the Stack →
  9. Own itweight 2

    Will you know it broke in production before a user tells you?

    No logging, no error tracking, no uptime check means every incident is reported by your angriest customer.

    FixOne error tracker, one uptime ping, structured logs with request ids. Free tiers cover all three. Toolbox: Utilities →
  10. Own itweight 1

    Is every file under 800 lines?

    A god file is where the next bug hides and the next agent gets lost. Size is the cheapest smell to measure.

    FixSplit by responsibility, not by line count. One concern per file so one can change without shutting the mall. Prompt: The Titan Audit →
  11. Verifyweight 2

    Did the last change touch only what you asked for?

    Scope creep is the model’s default. Unasked-for changes are untested changes.

    FixDiff before accept, every time. Reject any hunk you did not request and say so in the next prompt. Prompt: Hunt Regressions →
  12. Own itweight 1

    Would you put your name on it?

    Ferrari’s question. If the answer is no, you already know what to fix; the rest of this list is just the order.

    FixWrite down the one thing that makes you hesitate. Fix that first. How we scored ourselves →

How the score works

Each question carries a weight of 1, 2 or 3. Your score is the weight of your yeses over the total, as a percentage. Three questions are ship-blockers — tests, secrets, and authorization. A no on any of them caps the result at Blocked no matter what the number says, because a 92% with a leaked key is not a 92%.

The “fix first” list is every no, ordered blockers first, then by weight. Each links to the prompt or page on this site that addresses it. The generated prompt follows the four-part shape every prompt here uses: Context / Constraints / Success Criteria / Format Spec.

The rules table is a JSON file and the scorer is a pure function with a unit test for every branch — the same standard the self-audit holds the rest of the site to. If you think a weight is wrong, that is a one-line change and we would like to hear the argument.