Emergency Recovery Prompt Pack for AI-Built Apps

Inspect this project read-only. Report the current branch, Git status, recent commits, changed files, untracked files, and the difference between the last known-good commit and the current state. Do not edit, commit, reset, checkout, merge, push, pull, delete, or print secret values. Explain the result in plain English.

Investigate this failure: [DESCRIBE ERROR AND WHAT I DID]. Trace the user action through the relevant UI, code, API, database, environment, or deployment path. Give evidence, likely causes ranked by confidence, files involved, tests that would confirm each cause, and what you cannot verify. Do not edit anything or claim a cause without evidence.

Using the current Git status and recent history, identify the last known-good version for [FEATURE]. Compare the options of keeping the current changes, creating a branch, reverting specific files, or returning to a prior commit. Explain what each option could lose and what it will not restore, including database, environment, payment, or uploaded data. Do not run destructive commands or change history.

Fix only this verified error: [ERROR]. First inspect the relevant code and confirm the cause. Change the smallest number of files, do not refactor or clean up unrelated code, preserve existing behavior, run the narrowest useful test, and report the exact diff and remaining unknowns. Stop instead of guessing if the cause is not verified.

Compare the last known-good commit [COMMIT OR BRANCH] with the current project for [FEATURE]. Report changed files, behavior changes, data-flow changes, dependency or environment assumptions, and tests needed. Do not edit files, commit, or say the current version is better without evidence.

Explain these GitHub Desktop conflicts in plain English: [PASTE CONFLICT DETAILS]. For each conflict, identify the local behavior, incoming behavior, and decision I need to make. Do not choose “accept all,” resolve files, delete work, reset, or force-push. After I choose the intended behavior, give me a small resolution and test plan.

Prepare a rollback plan for [RELEASE OR CHANGE]. Include code version, database changes, environment variables, deployment, payment or auth impact, user communication, backups, and the point where rollback becomes unsafe. Separate steps I can verify locally from steps requiring GitHub, Supabase, Netlify, or payment-provider access. Do not execute the rollback.

Review the current project before I push. Report the branch, intended files, unrelated files, secrets risk, tests run, build result, remaining failures, and whether the original problem is actually resolved. Use READY, BLOCKED, UNKNOWN, or NOT APPLICABLE. Do not commit, push, or claim PASS unless the relevant test ran and its evidence is shown.