docs(pr-workflow): follow-up push to an auto-merged branch is silently lost

[CybotTM]

What

Promoted learning (/retro promote, batch 5): with auto-merge armed, a fast merge + head-branch auto-delete can land the PR before a follow-up commit is pushed — git push then silently re-creates the deleted branch off a stale base, commit dangling, no PR, no error. Adds the check (gh pr view --json state before follow-up pushes to an armed branch) and the recovery (fresh branch + cherry-pick) next to the Arming Gate section.

Came from /retro: yes

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[Copilot]

🟡 Not ready to approve

The added guidance should be aligned with existing doc conventions and made unambiguous (state extraction, non-OPEN handling, and consistent placeholders) to avoid misleading readers in the failure scenario described.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

Adds operational guidance to the GitHub PR workflow reference to prevent “lost” follow-up commits when auto-merge/merge-queue merges quickly and the head branch is auto-deleted before a developer pushes additional commits.

Changes:

• Documented the failure mode where pushing to an auto-deleted PR branch silently re-creates the branch with no PR attached.
• Added a recommended pre-push check (gh pr view ... state) and a recovery path (new branch + cherry-pick).

File summaries

File	Description
skills/git-workflow/references/pull-request-workflow.md	Adds a new subsection warning about follow-up pushes to armed PR branches and how to detect/recover from the silent branch re-creation case.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

🟡 Not ready to approve

The new doc text uses Git-specific “dangling” terminology in a way that’s technically inaccurate and may confuse readers about what happens after the branch is re-created.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (2)

skills/git-workflow/references/pull-request-workflow.md:1266

• Same terminology issue here: a “dangling re-created branch” isn’t dangling; it’s just a re-created branch that’s no longer associated with a PR. Rewording will make the recovery steps clearer.

fresh branch off updated main and open a new PR. If a dangling re-created
branch already exists, delete it and rescue the commit via cherry-pick.

skills/git-workflow/references/pull-request-workflow.md:1256

• “Dangling” is misleading here: after a push, the follow-up commit is still reachable from the re-created remote branch; the real issue is that the branch has no PR attached and won’t be merged automatically. Consider rephrasing to avoid the Git-specific meaning of “dangling commit”.

This issue also appears on line 1265 of the same file.

then silently **re-creates it** — off a now-stale base, with your commit
dangling and no PR attached; nothing errors and nothing merges.

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.