--- name: git description: Stages and commits scoped changes, fetches and integrates branches, resolves conflicts, pushes authorized history, and writes PR descriptions while preserving others' work. Applies to Git operations and commit messages, not permission to publish ordinary file edits. --- 1. Establish the authorized operation, repository root, branch, upstream and intended remote. Read project rules, signing requirements and PR templates. Inspect `git status --short --branch`, staged and unstaged diffs, untracked files and unfinished merges, rebases or cherry-picks. Do not take over someone else's unfinished operation. Use `git --no-pager` for log, diff, show and other paged output, and prevent unexpected editor or credential prompts. 2. Identify pre-existing work, including staged changes. Stage only task-owned paths or hunks after reviewing them. Never stage an entire mixed-ownership file. Broad `git add .`, `git add -A` and `git commit -a` require review of everything they include. For non-interactive partial staging use a reviewed patch with the existing tool, not a hung interactive prompt or a working-tree reset. 3. Before preparing a commit message or PR description, read [message guidance](references/messages.md). Keep each commit coherent and independently understandable. Include related tests and required documentation, without unrelated cleanup. 4. Verify the prospective commit's full file list and diff, including new files, and run `git diff --cached --check` plus relevant project checks. Account for unstaged changes on which working-tree tests depend. Preserve unrelated staged work. `git commit --only -- ` takes current working-tree contents for those paths and loses partial-staging boundaries within them. Use it only for wholly task-owned paths after inspecting the exact proposed content. 5. Commit only when authorized, with an explicit message that will not open an editor. Preserve configured authorship, signing and required hooks. Inspect the resulting SHA, message, files and remaining status. A requested commit does not authorize push, release, deployment or notifications. 6. For an authorized update fetch the intended remote, then inspect divergence from the intended branch. Do not integrate over unreviewed uncommitted changes. Use an explicit fast-forward-only update for non-divergent history, such as `git pull --ff-only `. For divergence apply repository policy and task authorization before choosing merge or rebase. Never interpret a rejected fast-forward as permission to rewrite history. 7. For merge preserve both histories and review the resulting tree. For an authorized rebase identify the exact unpublished range and new base before replaying it. Published-history rewriting needs specific authorization. In conflicts read base and both sides, preserve their intent, stage only resolved task files and rerun affected checks. Use the operation's continue command with the reviewed message and non-interactive editor settings where needed. Abort only an operation started by this task when that is the chosen recovery. Do not auto-select ours/theirs or skip a conflicting commit to obtain a green status. 8. Before push review the destination and complete outgoing range, including commits predating the task, and workflows/notifications publication triggers. Use an explicit remote and refspec. If rejected because the remote advanced, fetch and inspect the new work. Only for an explicitly authorized rewrite use targeted `--force-with-lease=:`. An implicit lease can be weakened by background fetches. Never use blind force or bulk branch/tag publication as a rejection fix. 9. Honor notification restrictions. Inspect existing suppression mechanisms only for the authorized publication. Do not disable workflows permanently or bypass required checks. GitHub skip markers apply only to certain events and can leave required checks pending, so do not add them by default. Verify current applicability when suppression is requested. 10. When a PR is requested follow its template and the final implementation. After push verify the remote SHA. Use the host's required PR linking and status mechanisms and, if waiting is required, its watcher. Report commit, push, CI and deployment as separate outcomes, with only observed checks and concrete blockers. Never discard or hide others' work with reset, restore, clean or stash. Without an explicit request do not amend or rewrite existing history, delete branches/tags, force-push, create a commit, publish a branch or open a PR. Do not invent coauthors, acknowledgments or sign-offs, bypass hooks with --no-verify, disable signing, change global Git configuration, or suppress checks to finish the task. Existing authorization persists within its stated scope and does not need repeated confirmation. Use the installed Git version's [add](https://git-scm.com/docs/git-add), [commit](https://git-scm.com/docs/git-commit), [pull](https://git-scm.com/docs/git-pull), [merge](https://git-scm.com/docs/git-merge), [rebase](https://git-scm.com/docs/git-rebase) and [push](https://git-scm.com/docs/git-push) references when option behavior matters.