Fix-prompts for when it goes wrong

Your last change broke the app. Before doing anything else: don't write new code, and don't try to fix forward. Show me exactly which files you changed in that last edit and what they looked like before. Then restore those files to their previous state, one at a time, and tell me when the app is back to how it was.

Some files seem to be missing from my project. Do NOT recreate anything from memory yet. First: list every file you deleted, moved or renamed in this session. Then check the editor's local history, any checkpoints, and git history for versions of those files. Show me what you found and where, and wait for me to choose what to restore.

Stop rewriting files from memory. Regenerating a file overwrites the version I might still be able to recover, which makes the damage permanent. From now on: never replace an existing file without showing me its current contents and asking first. If you think a file is missing or broken, tell me and wait.

The app worked earlier today and doesn't now. Walk backwards through every change made since it last worked, newest first, and for each one tell me in one plain sentence what it changed and whether it could plausibly have caused this. Don't change any code yet — I want the list first, then we'll undo the culprit only.

I have more than one copy of this project and I've lost track of which is current. Compare them: list the files that differ, and for each difference say which copy looks newer and why (dates, features present, code that references things the other doesn't). Recommend which copy to keep as the real one, and tell me what would be lost by discarding the other. Don't delete anything.

A secret key was exposed in this project and I've already rotated it with the provider. Now: find every place the old key appears (code, config, committed files, built output), remove them all, and change the code so the new key is read from a server-side environment variable that never reaches the browser. Show me each place you changed, and tell me if any part of the app genuinely needs that key client-side, because that would be a design problem to solve differently.

Audit this project for secrets that would be visible to anyone who opens the site: API keys, tokens, passwords, private URLs, database credentials. Check the source, any config files, and the built output. For each finding tell me: what it is, whether it's meant to be public (like a Supabase anon key or a Stripe publishable key) or genuinely secret, and what the consequence would be. Don't change anything yet, just report.

My app uses Supabase and has user accounts. Write me a test script that logs in as one test user and tries to read every table, then tells me plainly whether it can see rows belonging to other users. Run it and show me the result. If any table leaks data across users, list them and write the row-level security policies that would fix it, but explain each policy in plain English before applying anything.

Check every page in this app that shows management, admin or settings functionality. For each one tell me whether it requires the visitor to be logged in AND authorized, or whether someone who simply knows the URL could open it. Test it the way an outsider would, not by reading the code alone. Then add a proper auth check to any page that needs one, and tell me how to verify it myself in a private browser window.

Before you change anything about my database: take a full backup or export first and confirm it completed. Then show me exactly what you're about to change (tables, columns, data), what would be lost or transformed, and how I'd reverse it if it goes wrong. Wait for my explicit yes before running anything. If a change is irreversible, say so clearly in those words.

My deployed site was working and now it isn't, and no code changed. Before touching anything, diagnose in this order and tell me what you find: (1) are any third-party services it depends on failing, expired or over quota, (2) what do the browser console and network requests show on the live site, (3) has anything about the hosting or domain changed. Give me the single most likely cause in plain English and how to confirm it before we fix anything.

Explain this error to me as if I don't code, in three parts: (1) what the computer is actually complaining about, in one sentence, (2) the most likely cause given this project, (3) exactly what to change to fix it. If there's more than one plausible cause, tell me how to tell them apart. Here's the error:

My project runs fine locally but fails when it's built for the web. Find the difference: check for files that exist locally but aren't committed, case-sensitivity problems in file names or imports, environment variables that exist on my machine but not in the build, and anything that depends on my local setup. Tell me which one it is and fix it, explaining what was wrong in plain English.

My site published without errors but shows a blank white page. Check the usual causes in order: JavaScript errors in the browser console, wrong base path or asset URLs (files loading from the wrong place), a router expecting a server that isn't there, and missing environment variables at build time. Tell me which one it is, show me the evidence, then fix it.

My site looks broken on mobile. Check for the standard causes: a missing viewport meta tag, fixed pixel widths, content wider than the screen causing sideways scrolling, text too small to read, and tap targets too close together. List what's actually wrong with this project specifically, fix them, and tell me how to check the result on my phone.

I'm about to share this site with real people. Check it like a careful professional would and give me a list of what's missing or embarrassing: page title (not 'Vite App' or 'Untitled'), description, social preview image, favicon, a 404 page, mobile layout, obvious typos, placeholder text or lorem ipsum left in, broken links, and anything that would look unfinished. Sort by how embarrassing it would be, and fix the mechanical ones.

When I paste my site's link into messaging apps it shows no image and the wrong text. Add proper Open Graph and Twitter card tags: title, description, and an image at 1200x630. If there's no suitable image, create a simple one using the project's name and colors, and put it in the right place. Then tell me how to test that it works before I share the link again.

Explain this project to me as if I'm the owner but not a programmer. Cover: what the app does and for whom, what it's built with, which outside services it depends on and what each one does, what the main pages are, and 3-5 things that are fragile or would break if something external changed. Plain English, no jargon, and be honest about anything that looks half-finished.

I'm handing this project to a developer. Write a README that gets them productive in 15 minutes: what the app does, how to run it locally, what environment variables are needed and where each comes from, how it gets deployed, which parts are fragile, and what you'd fix first if you were them. Be honest about the messy parts rather than making it sound tidier than it is.

I want my site at my own domain. Tell me exactly what records to add at my registrar, in plain terms: what to type in each field, and what each record actually does. Then tell me how long it takes, how I'll know when it's working, and the three most common mistakes people make with this. Don't assume I know what DNS terms mean.

For this whole session: before deleting any file, replacing the contents of an existing file, running a command that changes things outside this project, or touching the database, stop and ask me first, and tell me what would change if I say yes. Small edits to files we're actively working on are fine without asking. If you're unsure which category something falls into, ask.

You're changing too much at once, which makes it impossible for me to tell what broke things. New rule for this project: make one focused change at a time, tell me what you changed and why, and let me confirm it works before moving on. If a task genuinely needs many files changed, list the plan first and let me approve it, then work through it in steps I can check.

Before we attempt this change, save the current working state as a version I can return to, and confirm it's saved. If this project isn't set up to save versions anywhere, tell me now and give me the simplest way to set that up before we continue, because I don't want to lose the working version we have.

Before you write any code for this, explain your plan in plain English: what you'll change, why that approach, and what could go wrong. Keep it under a paragraph and skip the jargon. Then wait for me to say go. If I ask a question about the plan, answer it before starting.

Summarize everything you changed in this session, in plain English, grouped by what it does for the app rather than by file. For each group, tell me whether it's tested or assumed working, and flag anything you changed that I didn't explicitly ask for. If you made a decision I might disagree with, say so now.