Git safety

Goal: repo operations that are boringly safe — no surprises, no leaks, reversible.

Hard rules

1. Never commit secrets. Scan staged changes before every commit. Found one: unstage, add to .gitignore, redo.
2. Never force-push or rewrite shared history (push --force, rebasing pushed commits, deleting branches) without explicit confirmation. If truly needed and confirmed, --force-with-lease, never bare --force.
3. Confirm remote and account before pushing: git remote -v, and the authenticated account (gh auth status or equivalent) match what the user intends.
4. Small, clear commits. Imperative subject ≤ 72 chars; the body explains why when not obvious. Follow the repo's commit convention if it has one; otherwise feat / fix / docs / chore / refactor / security.
5. Publishing (private → public) is irreversible in practice: forks, caches and clones keep what was public. Before the first public push scan the WHOLE tree and history, not just the last diff, for secrets AND for internal material (hostnames, internal IPs, customer names, runbooks, personal paths). Secret scanners skip prose; a human-style read of Markdown is still required.

Dependency discipline. One dependency change per commit. Review the lockfile diff, not just the manifest; never hand-edit a lockfile. Audit a new dependency with install scripts disabled first (npm ci --ignore-scripts, pip download then inspect) and pin its version.

Pre-commit secret scan

Run from the project root; <skill-dir> is where this skill is installed (e.g. ~/.agents/skills/git-safety):

bash <skill-dir>/scripts/secret-scan.sh            # staged changes (default)
bash <skill-dir>/scripts/secret-scan.sh --working  # all uncommitted changes
bash <skill-dir>/scripts/secret-scan.sh --file X   # one file
bash <skill-dir>/scripts/secret-scan.sh --test     # self-test, run after changing the patterns

Exit 0 = clean, 1 = review before committing; hits print with the value masked. Run the script; do not retype the pattern by hand — a hand-typed scan that misses looks exactly like one that passed. Two layers keep it worth reading: credential shapes (PAT, AWS key, PEM, JWT, Bearer) always flag; keyword-plus-assignment flags only with a real value attached, so prose about secrets does not. Prefer a dedicated scanner (gitleaks, trufflehog) for whole-history scans when available.

Standard flow

git status
git add -A                       # or the specific paths
bash <skill-dir>/scripts/secret-scan.sh || exit 1
git commit -m "type: concise imperative subject"
git switch -c feat/short-name    # work on a branch, not main
git push -u origin feat/short-name

Before any push

• git remote -v and the authenticated account are the intended ones.
• Secret scan clean.
• On a purpose-named branch (or main intentionally).
• No force-push unless explicitly confirmed.

Merge or rebase conflict in progress

1. See the state: git status, the history of both sides, the conflicting files.
2. Find the primary sources for each conflict — commit messages, PRs, issues — and understand why each change was made.
3. Resolve each hunk. Preserve both intents where possible; where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do not invent new behaviour. Do not give up on a resolvable conflict with --abort.
4. Run the project's checks (typecheck, tests, format). Fix what the merge broke.
5. Finish: stage and commit; if rebasing, continue until every commit is rebased. Then the pre-push checklist.

Recovery — when it already went wrong

Everything above except the secret case is local and reversible — that is why the order is scan, then commit, then push: each step is harder to undo than the last.

Original rules by the repository author. Conflict procedure from mattpocock/skills resolving-merge-conflicts (MIT © Matt Pocock, snapshot 7a83a3a); dependency discipline from addyosmani/agent-skills (MIT). See SOURCES.md.