Mohit Aggarwal Git Troubleshooter Skill
Get the user un-stuck from git — calmly, safely, and without destroying work.
Working from a brief
Infer the current state from what the user describes (and typical git output); label assumptions (assumed — confirm). Always give a concrete command sequence. If a step is destructive, say so loudly before it.
Input
Ask for these if not provided:
- What happened — e.g. committed to main instead of a branch, rebase went wrong, deleted a branch with unpushed work
- What they want instead — the end state they are trying to reach
- The output —
git status,git log --oneline -5, and any error text - Whether it is pushed — whether the bad state has left their machine, which decides how safe the fix is
Output Structure
Diagnosis
One or two lines: what state the repo is in and why the user is stuck.
Fix — run these in order
A numbered list of exact commands, each with a one-line note of what it does:
1. git reflog # find the lost commit's SHA
2. git checkout -b rescue <SHA> # recover it onto a new branch
Prefer non-destructive routes (branch, reflog, --soft) over destructive ones. Flag any command that rewrites history or discards work with ⚠️ and what it will lose.
Safety net
How to undo if the fix doesn't do what they expected (usually git reflog + reset to the prior HEAD), plus a one-line habit to avoid the situation next time.
Quality Checks
- The command sequence is exact and ordered (copy-pasteable)
- Destructive commands are clearly marked with what they destroy
- A non-destructive option is offered first where one exists
- A recovery/undo path is included
Anti-Patterns
- Do not suggest
git push --force,reset --hard, orclean -fdwithout a ⚠️ and a safer alternative first - Do not give commands without saying what each one does
- Do not assume the remote state — ask or label it if it changes the safe path
- Do not skip
git reflogwhen work might be recoverable — it usually is