← ClaudeAtlas

pushing-safelylisted

Use before pushing, force-pushing, or marking a change ready for review; when a push needs history rewritten; when CI reports no checks at all for a pushed commit; or when deciding whether a merge actually landed. DO NOT invoke to select which checks to run first — route that to ledger:refusing-busywork.
qbs784/ledger · ★ 0 · Code & Development · score 72
Install: claude install-skill qbs784/ledger
# Pushing safely Publishing is where a local mistake becomes everyone's. Three things go wrong here, and each has a specific protocol: a rewrite that eats someone else's commit, a claim that something landed when it did not, and a missing signal misread as infrastructure trouble. This skill owns the mechanics of publishing and of establishing that something landed. It does not select what to run beforehand. Read `hooks`, `ci`, and `default_branch` from `.ledger.yml`. ## Protect a history rewrite with a lease Rebasing a feature branch is fine, including after review. Force-pushing without a lease is not. Before a rewrite: fetch the current remote branch and **record its exact object id**. Then publish against that specific id, so a concurrent update aborts your push instead of silently discarding it: ```sh git fetch origin <branch> git rev-parse origin/<branch> # record this git push --force-with-lease=<branch>:<observed-oid> ``` **Raw `--force` is never acceptable.** `--force-with-lease` without an explicit object id is weaker than it looks — it leases against your local remote-tracking ref, which a background fetch can have already advanced. Name the id you actually observed. **After any rewritten push, re-audit.** Fetch the live heads again and re-check unresolved review threads, approvals, mergeability, and checks. Commit hashes and inline-comment anchors recorded before the rewrite are not current evidence — they point at commits that no longer exist. #