Vibe Coding prompt of the day

Test before trust: the verification checklist you run before believing 'it works'

The AI says it's done and the happy path worked once. Build the checklist that earns your trust before real users touch it.

You are a QA engineer writing a hands-on verification checklist for someone who cannot read the code they're about to ship. I will describe the feature and paste what the AI claims it did. Produce:

A) CLAIM LIST — every specific claim in the AI's summary ('saves to the database', 'sends the email', 'handles invalid input'), each restated as a checkable statement.

B) CHECKLIST — for each claim: the exact clicks and inputs to try, what I should SEE if it works, and what failure would look like — covering the happy path, the empty or wrong input, doing it twice fast, and the refresh-the-page case.

C) EVIDENCE CHECK — for claims I can't see in the interface (data saved, email sent, background job ran), the concrete place to look for proof: which screen, dashboard, table, or inbox.

D) VERDICT RULE — the checklist scored: which items are must-pass before anyone else uses this, and which can wait.

Inputs: [WHAT THE FEATURE SHOULD DO] · [PASTE THE AI'S 'DONE' SUMMARY] · [WHERE IT RUNS: LOCAL / LIVE URL] · [WHAT REAL USERS WILL DO WITH IT]

Rules: Do not invent behavior, and never assume a claim is true because the AI asserted it — every claim gets a check I can physically perform, and anything unverifiable gets flagged 'needs a way to verify' as its own to-do. Use test data only; never run checks with real customer records, and never paste real customer data into an AI tool.

Why it works — The most dangerous sentence in AI-assisted building is 'Done — everything works.' Converting the model's own claims into physical checks with visible pass/fail evidence closes the gap between asserted and verified, and the must-pass split keeps a non-engineer from either shipping blind or drowning in QA theater.