Pre-Push Checks
Choose evidence that covers the actual change and the repository's required checks. This skill does not authorize committing, pushing, rewriting history, or changing check policy.
Establish the scope
Confirm the checkout, branch, intended destination, and current worktree state. Identify the comparison base from the task and current branch or pull-request metadata; do not assume a branch named main or treat an unrelated upstream as the base.
git rev-parse --show-toplevel
git status --short --branch
git diff --stat <verified-base>...<candidate-head>
Inspect staged, unstaged, and relevant untracked files separately: a committed diff does not include them. Distinguish the tree tested from the commits being published, and preserve unrelated work. When the base or candidate changes, reassess the combined scope and rerun checks whose evidence is invalidated.
Select relevant evidence
Read the project's scripts, lockfiles, hooks, and CI definitions to discover required commands and their responsibilities. Do not assume hooks are narrow, CI is exhaustive, or local and remote checks are interchangeable.
- For behavior changes, choose owning tests or a runnable check that would detect the affected failure. Broaden for shared contracts, dynamic entry points, or cross-cutting changes.
- For documentation-only changes, use applicable document checks or direct review. Do not invent an application test requirement for a prose edit.
- For manifests, exports, build configuration, or packaged entry points, verify the affected build or artifact where source-only tests cannot establish runtime behavior.
- For integrations, distinguish local simulation from actual service evidence. Run external checks only within the task's authorization and available configuration; keep missing evidence explicit.
Reuse passing evidence when the tested tree, relevant environment, and command remain applicable. Inspect changes made by formatters or hooks and repeat only invalidated checks. Complete all project-required checks even when the optional test selection is narrower.
If coverage is relevant, select both owning tests and affected source scope. Test discovery alone may miss configuration, dynamic loading, subprocesses, or built artifacts. Do not lower thresholds, hide affected files, or accept an empty test selection as evidence. A full suite is appropriate when required or when a narrower selection cannot credibly cover the change.
Publish and verify
For an ordinary authorized push, run applicable checks before publication. On failure, diagnose the command and affected behavior; report environment limitations with evidence. Do not bypass required gates or label incomplete checks as passing. A requested diagnostic or draft publication may carry explicitly pending evidence where repository policy permits it.
For an authorized history rewrite, fetch and record the exact remote branch OID before rewriting. Protect publication with an explicit lease:
git push <remote> <local-head>:refs/heads/<branch> --force-with-lease=refs/heads/<branch>:<observed-oid>
If the lease fails, inspect the concurrent update before proceeding. Never replace it with raw force or refresh the expected OID merely to overwrite another update. When using a wrapper, verify its actual concurrency protections rather than assuming it supplies an equivalent lease.
After publication, query the remote itself, for example with git ls-remote <remote> refs/heads/<branch>, and compare its OID with the intended published commit. A stale local tracking ref does not prove the remote state. Check hosted results for that current head; pending or absent CI is not success. Investigate absent runs using the workflow triggers, permissions, and merge state instead of manufacturing empty commits or toggling metadata to retrigger blindly.
If established tooling combines rewrite and publication in one operation, determine that behavior beforehand and validate locally first where supported. When publication necessarily precedes validation, inspect every changed branch against its current base immediately afterward and keep readiness or merging blocked until the required evidence passes. Report and repair failed published changes within the authorized scope; do not blindly restore an old remote head.
Rewrites invalidate previous commit identities. Recheck affected review anchors, approvals, mergeability, and required checks against the live heads. Report the tested commit or tree, selected checks and results, remote verification, and any pending evidence without implying push, merge, or deployment acceptance beyond what was observed.