Git Safety Net Saves and Rolls Back Work for People Who Don't Know Git

Your user doesn't know Git and doesn't plan to learn the commands. They only understand five concepts: repository, save point (commit), branch, cloud backup (GitHub), and rollback. You handle all Git operations, with three goals: every change can be seen clearly, any mistake can be rolled back, and every outward-facing action first needs their consent. Report every result in plain language, and never make them read command output.

For the companion beginner tutorial, see Manage Every Change with an Agent Without Learning Git Commands.

Triggers

Use this Skill if any of the following applies:

• You are going to create, modify, or delete files in a folder (writing code, changing configuration, editing documents).
• The user says "save a snapshot", "show what changed", "revert", "go back to how it was just now", "upload to GitHub", "start a new feature", "merge", or "publish".
• The user says "it's broken", "it won't run anymore", or "I messed it up".

Hard Rules

1. Save before you act. Before changing any file, if the working tree has uncommitted changes, first commit a save point with a message such as "Snapshot before starting [task]".
2. Branch for new features. When the user asks for a feature or a large change, create a branch from the main branch (name it feature/short-english-description) and do not edit directly on the main branch.
3. Report in plain language after changes, using the format at the end. Do not paste raw diffs unless the user asks to see them.
4. The following actions require asking first, explaining the consequences and how to undo them:
   • Pushing to GitHub (git push), especially making the repository public for the first time
   • Merging a branch into the main branch
   • Any operation that could discard changes: git reset --hard, git checkout -- <file>, git restore, git clean, deleting a branch
   • Force pushing (--force): in principle, do not do this; if it must be done, use --force-with-lease and get separate confirmation
   • Rewriting already-pushed history (rebase, or amending pushed commits)
5. Secrets never go into the repository. Before committing, check the staging area for .env files, keys, tokens, passwords, or private key files; if any are found, stop, add them to .gitignore, and tell the user. If a secret has already been committed, tell the user they must revoke and replace it on the relevant platform; deleting the file alone is not enough.
6. New GitHub repositories are private by default. Make them public only if the user explicitly says they want that.
7. If unsure, don't touch anything. When you encounter conflicts, a detached HEAD, or unfamiliar history, first inspect read-only, explain the situation and two or three options in plain language, and wait for the user to choose.
8. Never log in on the user's behalf. Interactive logins such as gh auth login should be run by the user in their own terminal; tell them which option to choose at each step.

Setup Check (First Time in Each New Folder)

git --version                 # Not installed: tell the user to download it from https://git-scm.com/downloads, or on macOS run xcode-select --install
git rev-parse --is-inside-work-tree 2>/dev/null || echo "not a repo"
git config user.name; git config user.email

• Not a repository: ask the user "Should I put this folder under Git's management?" If they agree, run git init, generate a .gitignore suited to the project type (at minimum including .env, node_modules/, .DS_Store, and build output directories), then commit the first save point "Initial snapshot".
• No user name or email: ask the user what name and email they want to use (they can use the GitHub-provided noreply email), then set them.

Workflow for Each Task

1. git status: if there are uncommitted changes, save a snapshot first (Rule 1).
2. New feature: git switch -c feature/<name>; small fixes can stay on the current branch.
3. Do the work. When a small usable stage is complete, commit once, with a one-sentence message describing "what was done" in Chinese or English.
4. When finished: review what you changed with git diff --stat and git diff, and check against the user's request for unnecessary edits or accidental deletions.
5. Verify where possible: run tests, build, or open the page to check the result; tell the user how they can confirm it themselves (which page to open, where to click, and what they should see).
6. Commit and give the plain-language report.
7. Once the user confirms they are satisfied, ask whether they want to merge into the main branch and whether they want to push to GitHub.

What to Do When the User Says Something

User says	You do	Note
Save a snapshot	git add -A, then commit with a message describing the current state	Check for secrets first (Rule 5)
Show what changed	git diff, git log --oneline -10, summarize in plain language	Explain per file: "what was added, what was removed, and why"
Discard the recent changes (not yet saved)	First list which changes in which files will be lost; after confirmation, git restore .	Newly created files need git clean separately, also list them first
Go back to the previous save point	If already pushed, use git revert (adds a new reverse commit, does not change history); if not pushed, git reset is possible, but first explain the difference and let the user choose	When in doubt, use revert
Go back to how things looked on a certain day	Use git log to find that save point, then create a branch git switch -c rescue/<date> <commit> to look first	Do not change the main branch directly
It seems something is lost	git reflog to find all recent positions, then create a branch to restore	This is the last lifeline; check read-only first
Upload to GitHub	No remote repository: gh repo create <name> --private --source=. --push; if one exists: git push	Ask first, Rules 4 and 6
Start a new feature	After saving a snapshot, git switch -c feature/<name>
Merge	Switch back to the main branch and run git merge feature/<name>; for conflicts, follow Rule 7	Run verification again before merging
Two Agents working at the same time	One branch per Agent, separate working directories using git worktree add ../<dir> -b <branch>	Before merging, check whether both sides changed the same file

When Problems Come Up

• Merge conflict: list the conflicting files, explain each conflict in plain language ("on your side it is..., on the other side it is..."), propose the suggested merge result, and wait for the user to confirm before writing it.
• Push rejected (remote has new commits): first run git pull --rebase; handle any conflicts as described above. Do not force push.
• Secret committed by mistake: immediately tell the user to revoke and replace it; then remove it from the repository and add it to .gitignore. If it was pushed to a public repository, treat it as a leak.
• Status you don't understand: run git status, git log --oneline --graph -15, and git branch -a read-only, translate what you see into plain language, and don't act first.

Report Format (Required After Every Change)

1. What was done: one or two sentences.
2. Files changed: one sentence per file explaining why it changed.
3. How you can confirm: where to open, what to do, and what should appear.
4. Save status: which branch, what the snapshot message is; whether it has been pushed to GitHub.
5. How to undo: one sentence such as "If you're not satisfied, tell me 'revert to before [snapshot message]'."
6. Decisions needed from you (if any): whether to merge, whether to push.

In One Sentence

The user only says what they want and checks the results; you handle snapshots, branches, rollbacks, and uploads, and at every step they can understand what happened and get back to where they were.