No force push a reviewed pr
Skill serhiy-bzhezytskyy/contrib-receipts/skills/no-force-push-a-reviewed-pr
Claude Code skills for contributing to someone else's repo — each rule backed by a real receipt. Bring help, not noise.
npx -y skills add serhiy-bzhezytskyy/contrib-receipts --skill no-force-push-a-reviewed-prAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
On a PR that already has reviewers, push follow-up changes as plain new commits only — never `git commit --amend`, never `git push --force` / `--force-with-lease`. Force-push rewrites the commits reviewers' inline comments anchor to, resets the GitHub review state, and forces a cold re-read — the opposite of the incremental trust you are building. Use whenever you push any change to a PR someone has already looked at. Trigger terms: force-push, --amend, --force-with-lease, rebase, "clean up history", pushing to an under-review PR.
SKILL.md
4.5 KB, as published. Nobody here has run it
No force-push on a reviewed PR
Purpose
Once a reviewer has read your PR, GitHub anchors their inline comments to specific commits and diff positions. A force-push (or an amend followed by a force-push) rewrites those commits, so GitHub can no longer tell what changed since their last look — comments go "outdated", the diff resets, and the reviewer has to re-read the whole thing cold. That cold re-read is exactly the cost incremental commits exist to prevent. On a shared PR, force-push is not a style choice: it breaks other people's review-in-progress.
Squashing/cleanup, if the house wants it, happens at merge time by the committer — not mid-review by you.
When to use
- Any push to a PR that has at least one reviewer or review comment.
- Any urge to
--amend"just to fix the commit message" on a shared branch. - Any rebase that would rewrite already-reviewed commits.
When NOT to use
No reviewer or review comment is on the branch yet (or it's your own solo repo) — before anyone has looked, a rebase/amend anchors nothing and is fine.
The practice (checklist)
- Default to a new
git commitfor every follow-up change, so each reviewer sees exactly the delta since their last look. - No
git commit --amendon a shared branch — even to fix a stale message. - No
git push --force/--force-with-leaseon a shared branch. - Leave squashing/history cleanup to the committer at merge time.
- If you already force-pushed, own it in the thread and switch to incremental commits from that point on.
Note (corpus): this is receipt-backed etiquette, not a statistically validated lever — the Solr/Lucene corpora record no force-push event, so it cannot be tested against merge outcomes. It stands on the maintainer's own words, below.
Rationalizations
| Shortcut | Why it fails |
|---|---|
| "Force-push gives a cleaner history." | It resets the GH review state and orphans reviewers' inline comments as "outdated" — forcing a cold re-read, the exact cost incremental commits prevent. |
"It's just a commit-message fix, --amend is harmless." | Amend still rewrites the commit reviewers anchor to; on a shared branch that breaks their in-progress review the same way a force-push does. |
| "I'll squash before merge so it's tidy." | Squashing is the committer's call at merge time — not yours mid-review; do it early and you rewrite commits people are still reading. |
RECEIPT
A Solr committer, apache/solr PR #4632 (corpus-solr-prs/pr-solr-4632.json, issue
comment) — verbatim:
"Please don't force-push to PRs, especially once someone has looked at it. It resets the GH review state for the reviewer, making it impossible to be sure what changed since the last reviewed changes."
Recovery (same PR, Serhiy): acknowledged the mistake and committed to incremental commits only from that point. Context (journal): the SOLR-3284 branch (PR #4632) had been amended + force-pushed three times with three readers on it before the correction landed.
Lifecycle
- Signals it worked: reviewers' prior inline comments stay anchored and non-"outdated" across your follow-up pushes; no maintainer asks "what changed?".
- What to log on a misfire: the PR#, how many reviewers were already on it, and
which command rewrote history — force-push, amend, or rebase.
Record it in
LEDGER.md. - Death criterion: retire only if GitHub changes so that review state survives history rewrites (it does not today).
- Relates to: history-rewrite hygiene once a PR is under review (prefer a plain
git push; a force-push breaks reviewers' incremental view and comment anchoring). Pairs with the commit-hygiene rule for someone else's house (strip auto-appendedCo-Authored-By/ "Generated with" trailers on Apache commits; the human contributor owns the commit).