GitHub for People Who Don't Code

NOTE

Use this page as a prompt reference. Every file below is built to be handed straight to an AI. Download it, drop it into Claude, ChatGPT, Cursor, or Lovable, and say "use this as my playbook." The prompts on this page are copy-paste ready.

PAYOFF

The one-line pitch: without GitHub, a bad AI session can genuinely delete your app. With GitHub, the worst case is 10 confusing minutes. That trade is the whole kit.

Set up version control for this project. Initialize git if needed, create a private GitHub repo for it under my account, connect the two, and push everything. If I'm not authenticated with GitHub yet, walk me through logging in one step at a time and wait for me after each step. When you're done, tell me the repo's web address.

Save my work: commit everything with a clear one-line message describing what changed since the last commit (look at the actual changes to write it), then push to GitHub. Then confirm the push succeeded and tell me the commit message you used.

My app is broken and I want to go back to a version that worked. Show me the last 10 commits as a numbered list, each with its date and message, in plain English. I'll tell you which number was the last good one. Then restore the project to that version in the safest possible way: do not delete history, do not force anything, create an undo commit instead. Before you run each command, tell me what it does in one sentence and wait for my OK.

I want to try something risky: [DESCRIBE THE EXPERIMENT]. Before we start, create a new branch named after this experiment and make sure all current work is committed and pushed on main first, so main is safe no matter what. Do all the experimental work on the branch. When we're done, I'll say either "keep it" (then merge it into main and push) or "abandon it" (then take me back to main exactly as it was and delete the branch). Confirm the setup is done before touching any code.

I've connected you to my repository [OR: the project in this folder]. Before we do anything else, read the codebase and give me a plain-English tour: what this app does, how it's organized, the 5 most important files and what each one is for, and anything that looks fragile or half-finished. Assume I didn't write the code and don't know the vocabulary. No changes yet, just the tour.

Something has gone wrong with git in this project and I need your help. I do not code. Treat me accordingly: plain English, no jargon without a one-line explanation, one step at a time.

Here's what happened, as best I can describe it: [WHAT YOU DID / WHAT THE AI DID / WHAT THE SCREEN SAYS. Paste any error messages in full. "I don't know, it just broke" is an acceptable answer.]

Do this, in this order:

1. DIAGNOSE FIRST, TOUCH NOTHING. Inspect the state of the repository using only read-only commands. Then explain to me, in plain English and under 10 sentences: what state my project is in, how it got there (best guess), whether any of my work is at risk of being lost, and what the last few saved versions are (dates and messages).
2. PROPOSE A PLAN. Tell me which saved version you recommend returning to and why, plus what, if anything, we would lose by doing that (for example: work done after that version that was never committed). If there is uncommitted work worth keeping, your plan must stash or back it up first, and you must tell me where the backup lives.
3. WAIT FOR MY GO-AHEAD. Do not run anything that changes state until I say yes to the plan.
4. THEN EXECUTE ONE STEP AT A TIME. Before each command: one sentence on what it does and why. After each: confirm it worked. Wait for me to say "next" between steps.

Hard rules, no exceptions:
- Never delete anything, discard changes, or force-overwrite anything without telling me first, in plain English, exactly what would be lost, and getting an explicit yes from me for that specific action.
- Prefer reversible moves over clean ones. An extra "undo commit" in the history is fine; erased history is not.
- No force push, no hard reset, no deleting branches, unless you have explained the consequence and I have said yes to that exact command.
- If at any point you are not sure what state we're in, stop and say so rather than guessing.

We are done when: the app is back to a version that worked, that version is committed and pushed to GitHub, and you have given me a two-sentence summary of what went wrong and what we did, so I can avoid it next time.

WATCH OUT

After any recovery: save immediately (commit and push, message: "Recovered to working version"). The most common cause of a scary recovery is a long gap since the last save. Commit more often and this prompt becomes something you never need.

Get the next drop

Every new Vault system ships to the list first. Twice a week, free.