From sync-guard
Discipline for working in a git repo that other agents (or humans) may also be pushing to. Load this whenever editing files on a shared branch like main, especially when working directly to main rather than through a feature branch + PR. Covers when to use Edit vs Write, when to re-Read files, and how to respond when sync-guard's pre-push hook fires.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sync-guard:multi-agent-gitThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This repo has the `sync-guard` plugin installed. It catches a specific failure: two sessions both push to the same branch, the second one's `git pull --rebase` succeeds cleanly, but the files it writes contain content from *before* the first session's push landed — so the push silently rolls work back to a recent past state, with no merge conflict.
This repo has the sync-guard plugin installed. It catches a specific failure: two sessions both push to the same branch, the second one's git pull --rebase succeeds cleanly, but the files it writes contain content from before the first session's push landed — so the push silently rolls work back to a recent past state, with no merge conflict.
Three rules avoid this almost entirely.
Edit validates that old_string still matches the file on disk. If another session moved the branch and your in-context copy is stale, Edit fails loudly — that's the signal to re-Read before continuing. Write silently overwrites whatever's there.
Edit for any modification to a file that already exists.Write only for genuinely new files.Edit fails because old_string no longer matches, re-Read the file before retrying — don't just expand the match window. The mismatch usually means the file has legitimately changed.git pull --rebaseYour memory of file contents goes stale the moment another session pushes. Even if you read a file earlier this session, after a rebase that brought in new commits you have to re-Read every file you plan to edit. The rebase fast-forwards the local ref but doesn't refresh anything in your context window.
In practice: when working directly to a shared branch (no PR), the right sequence is:
git pull --rebase origin <branch>Read every file you plan to edit, even ones you read earlierEditgit pull --rebase origin <branch> && git push--no-verifyThe hook reports files where the push appears to revert recent work. The default response is:
git pull --rebase origin <branch> to pull in whatever you missedRead the named files to see what they actually contain nowgit push --no-verify bypasses the check. Only use it when you actually intend to revert — and in that case, prefer making the commit message start with Revert: so the hook recognises the intent without needing an override flag.
main). Feature branches rely on PR review.Rules 1 and 2 cover the in-session case; rule 3 is the boundary backstop.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub domvinyard/sync-guard --plugin sync-guard