Paste one at the start of a job and your AI works in the order that shipped, with the rules that held up. Under each prompt, the traps it will not catch on its own, so you know what to watch.
Use it when: When you just published an update and need to know it truly went live.
I just deployed [site or instrument] to [URL]. Verify the deploy in this order. First, fetch the actual file, such as the real index.html or the real changed asset, and not a directory URL with a trailing slash, because that can return a tiny redirect stub that looks like a failed deploy. Compare what you fetched with what I meant to ship: show me the version string or a distinctive line from the new change. Second, tell me exactly what you fetched and what you saw. Third, give me a short checklist for confirming in a real browser, including clicking through any enter overlay, and tell me what I should see on screen if the deploy worked. Do not call the deploy failed or successful from a redirect response alone.
What this prompt will not catch
The update looks failed but the real file is actually fine
The page opens but still behaves the old way
Emails and customers
Collect every email address into one list
Use it when: When buyers, chat leads, newsletter signups and accounts each sit in a separate list.
Help me build one list of people for [my site or store]. Before writing anything, ask which doors collect an email today (buying, chat, newsletter form, accounts, anything else) and which database I use. Then create one capture table with these columns: id, email, source, source_id, metadata (json), is_test, created_at. Limit source to a fixed set: purchase, chat_lead, subscribe, community_submit, account_signup, magic_link, manual, other. source_id holds the order or conversation id. Make it duplicate-proof with a unique index on lower(email), source, and coalesce(source_id, ''). Lock it down so only server roles can read it and visitors never can. Whether a person may get marketing is a separate record, so do not put consent in this table. Show me the SQL and explain each choice in one line before I run it.
What this prompt will not catch
A signup route was never connected, so those people are missing
Imported people got marketing email without anyone checking their agreement
Get found on Google and AI search
Remove a wrong claim from every place AI reads
Use it when: When you corrected a claim on a page and want it gone from every file machines read.
I am correcting this claim on [page URL]: [old claim] becomes [new wording or removal]. Do not stop at the page.
1. Search every machine-facing file for the old claim and any paraphrase of it: llms.txt, the ai-catalog descriptions, the markdown twins of pages, the product feed, and structured data. List each hit with file and line.
2. Check the new wording against the product itself, not only against a live page. A live page can be wrong.
3. Apply the same correction in every file in the same change, in the same wording.
4. Fetch each file from the live site afterwards and confirm the old claim is gone and the file still serves correctly, with llms.txt as text/plain.
Report the hit list, what changed, and anything you could not verify.
What this prompt will not catch
The old claim still sits in the descriptions AI helpers read
Your product list keeps the old price or wording
The prompt starts the work. The field journal finishes it.