Run any Skill in Manus with one click

pr-from-stale-branch-silently-reverts-newer-main-files

Stars2

Forks0

UpdatedJuly 8, 2026 at 11:09

Trap: opening/merging a PR from a branch that was created a while ago can SILENTLY DELETE (revert) files that landed on main AFTER your branch point — with NO merge conflict to warn you. Use when: (1) about to `gh pr create` or squash-merge from a long-lived / earlier-branched branch; (2) `git diff origin/main..HEAD --stat` shows DELETIONS of files you never touched; (3) a PR diff is unexpectedly large or removes another session's/teammate's work; (4) the repo has many parallel branches + a squash-merge flow (each squash makes older branches progressively staler). The fix is to merge origin/main INTO the branch first, then re-verify the diff shows only your additions. Distinct from merge-CONFLICT skills — this is the no-conflict, clean-merge silent-regression case. See also: pr-conflict-from-mid-flight-merges, large-redesign-parallel-branch-collision-audit, merge-conflict-generated-files.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

wan-huiyan

wan-huiyan/agent-traffic-control

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	pr-from-stale-branch-silently-reverts-newer-main-files
description	Trap: opening/merging a PR from a branch that was created a while ago can SILENTLY DELETE (revert) files that landed on main AFTER your branch point — with NO merge conflict to warn you. Use when: (1) about to `gh pr create` or squash-merge from a long-lived / earlier-branched branch; (2) `git diff origin/main..HEAD --stat` shows DELETIONS of files you never touched; (3) a PR diff is unexpectedly large or removes another session's/teammate's work; (4) the repo has many parallel branches + a squash-merge flow (each squash makes older branches progressively staler). The fix is to merge origin/main INTO the branch first, then re-verify the diff shows only your additions. Distinct from merge-CONFLICT skills — this is the no-conflict, clean-merge silent-regression case. See also: pr-conflict-from-mid-flight-merges, large-redesign-parallel-branch-collision-audit, merge-conflict-generated-files.
author	Claude Code
version	1.0.0
date	"2026-06-17T00:00:00.000Z"
disable-model-invocation	true

A PR from a stale branch can silently revert newer main files (no conflict)

Problem

Your branch was cut from main at commit X. Since then, other PRs added files B, C, D to main. Your branch never had B/C/D. When you open a PR (or merge), git computes the diff as origin/main..HEAD — and because your branch lacks B/C/D, the diff shows them as DELETIONS. Merging the PR removes B/C/D from main, reverting work you never touched. There is no merge conflict (your branch simply doesn't mention those files), so nothing warns you — the PR looks "clean" and the deletions hide in the diff stat.

Context / Trigger Conditions

About to gh pr create / gh pr merge --squash from a branch that's been around for more than a session or two, or in a repo with many parallel branches.
git diff --stat origin/main..HEAD lists files being removed that you have no memory of touching (e.g. someone else's analysis/handoff/docs from a sibling session that merged while you worked).
The PR's deletion count is suspiciously high for the work you did.
Squash-merge workflows make this WORSE over time: each squash rewrites main's history, so a branch that "was only a bit behind" reverts more with each sibling merge.

Solution

Before creating/merging the PR, always sanity-check the full diff stat:
```
git fetch origin main
git diff --stat origin/main..HEAD
```
Scan for --- / deletion lines on files outside your scope.
If you see spurious deletions, merge origin/main into your branch first (do NOT just merge the PR):
```
git merge origin/main --no-edit      # clean if your changes are file-disjoint
```
This re-adds B/C/D to your branch so they're no longer "deleted" in the diff.
Re-verify: git diff --stat origin/main..HEAD should now show ONLY your own additions/edits. Then push + PR.
If the merge DOES conflict, you've crossed into merge-conflict territory → hand off to pr-conflict-from-mid-flight-merges / merge-conflict-generated-files (generated-file union playbooks).

Verification

Post-merge-of-main, git diff --stat origin/main..HEAD lists only files you intended to change (no foreign deletions). The PR's "files changed" on GitHub matches your mental model of the work.

Example (this repo, S258, 2026-06-17)

Branch docs/s258-prompt-update was cut before S257b's anomaly-alignment docs merged to main. The first git diff --stat origin/main..HEAD showed 5 unrelated files being deleted (−384/−93/−65/−40/−19 lines: the anomaly HTML, a content snapshot, two S257b handoffs, a legend edit) alongside the intended S258 additions — a clean merge would have reverted all of S257b's work. git merge origin/main --no-edit was conflict-free (docs were disjoint) and the diff then showed only the 7 S258 files. PR opened safely.

Notes

The tell is deletions in the diff stat, not a conflict marker — conflict-only habits (rely on git to yell) miss this entirely.
Same root cause as large-redesign-parallel-branch-collision-audit (branches drift from main), but that skill is a pre-plan collision audit across many branches; this is the at-PR-time per-branch check + the merge-main-in fix.
gh pr merge --delete-branch may then fail with "main is already used by worktree at ..." when you run from a worktree — the merge still succeeded; delete the remote ref with gh api -X DELETE repos/<owner>/<repo>/git/refs/heads/<branch>.

More from this repository

same repository

gh-pr-merge-worktree-checkout-trap

wan-huiyan/agent-traffic-control

Diagnose and bypass `gh pr merge --squash --delete-branch` failing with "failed to run git: fatal: 'main' is already used by worktree at ..." when another git worktree has main checked out. Use when: (1) you run gh pr merge and see this exact error, (2) you have multiple worktrees in the repo (e.g. `.claude/worktrees/*`), (3) the error appears even though the GitHub merge itself looks fine. The merge SUCCEEDED on GitHub — only gh's local-side effect (post-merge `git checkout main`) failed. Verify via `gh pr view N --json state,mergedAt`; if state=MERGED, you're done. This also applies to `gh pr checkout` and any other `gh` subcommand that tries to touch the local main branch while another worktree has it claimed. v1.2.0 (2026-05-26) adds the sequential-error variant: if you re-run from the main-repo worktree after the first error, you can then hit "cannot delete branch <feature-branch> used by worktree at <feature-worktree>" — same one-checkout-per-branch invariant, this time applied to the feature branch. Cl

2026-07-102

cjk-structured-llm-output-truncates-json-needs-2x-tokens

wan-huiyan/agent-traffic-control

When generating LONG Chinese/Japanese/Korean (CJK) STRUCTURED output (a big JSON report, a multi-section document) from an LLM chat API, the response truncates mid-JSON and your parser throws "no parseable JSON" / "Expecting ',' delimiter" / JSONDecodeError — even though the SAME prompt in English worked. Root cause: CJK is token-heavy (≈1–2 tokens per character vs ≈0.25 for English), so a report that fit your max_tokens in English overflows it in Chinese. Some models ALSO hard-cap output well below what you request (e.g. qwen-max caps at 8192) and silently truncate. Use when: a zh/ja/ko structured-generation run fails JSON parsing, worked in English, or a specific model truncates while others on the same prompt succeed. Covers the ~2× token budget rule, per-model output caps, and a salvage that recovers the complete sections from a truncated object.

2026-07-082

design-subagent-with-plan-schema-executes-and-deploys-live-infra

wan-huiyan/agent-traffic-control

Catch the failure where a subagent dispatched ONLY to DECIDE/DESIGN (a judge, a design-panel synthesizer, a "pick the mechanism" agent) instead EXECUTES the plan — and, having full Bash/gcloud/bq, provisions LIVE infrastructure (creates a BQ dataset/table, a DTS scheduled query, a log metric, a paging alert policy) and even git-commits code — when you only wanted a recommendation. Use when: (1) you author a Workflow/Agent whose structured-output schema has a field that reads as an execution mandate ("this_session_plan", "exact ordered steps", "deploy_steps", "what was provisioned") and the agent has mutate-capable tools; (2) a design/judge agent's result says "DONE — created X" / "provisioned live" instead of "recommend X"; (3) you are about to trust a decision agent's self-report of what it changed. The agent treats a "plan/steps" output field as a TODO to carry out, not a proposal. Fix: constrain design/decision subagents READ-ONLY in the prompt (explicitly: "do NOT run any mutating bq/gcloud/git command; S

2026-07-082

git-add-u-after-async-post-commit-hook

wan-huiyan/agent-traffic-control

Prevent (and recover from) `git add -u` + `git commit --amend` + `git push --force-with-lease` catastrophically rolling thousands of unrelated tracked-file deletions into an amended commit when the project has an async post-commit hook that mutates tracked files (e.g. regenerates `docs/site/*.html`, `docs/site/index.html`, `MEMORY.md`, or any other tracked artefact in a background `&` / `nohup` / "running … in background" process). Use when: (1) you just made a small commit, the post-commit log line says `[post-commit] … running … in background`, and you're about to amend with corrected message / typo / issue ref; (2) `git commit --amend` output reports `1000+ files changed, … insertions, NNN,NNN deletions(-)` when you only intended a 6-file change; (3) the force-pushed branch on origin shows a massive deletion diff and `git status` after the amend shows previously-tracked files like `MEMORY.md`, `.github/`, `.cursor/`, `scripts/` as Untracked; (4) you ran `git add -u` reflexively before `--amend` on a projec

2026-07-082

main-bash-cwd-persists-nested-worktree

wan-huiyan/agent-traffic-control

Prevent and diagnose nested git worktrees created at the wrong filesystem path when orchestrating parallel work from the main Claude Code agent. Use when (1) you ran `git worktree add .claude/worktrees/<name> ...` from the main agent's Bash tool, (2) `git worktree list` shows the new worktree at an unexpected nested path like `.claude/worktrees/<previous-worktree>/.claude/worktrees/<name>` instead of the intended top-level location, (3) a subagent dispatched to the intended path reports "worktree path mismatch" or operates from a longer nested path. Root cause: the main agent's Bash tool **persists cwd between calls** (per its docstring: "The working directory persists between commands"). An earlier `cd /abs/path && cmd` changes the main shell's cwd; a later `git worktree add <relative-path> ...` resolves against that persisted cwd rather than the project root, silently creating nested layouts. This is the **inverse** of the subagent variant (subagent-bash-cd-wrong-worktree) — subagent shells reset per call,

2026-07-082

merged-pr-not-deployed-gate-label-missing

wan-huiyan/agent-traffic-control

Diagnose "I merged my PR + CI is green but the live service still doesn't show my changes." Use when: (1) a code-bearing PR has been squash-merged into main with all required status checks passing, (2) the user reports the change is still missing from the deployed environment minutes-to-hours later, (3) the repo has a `pull_request: types: [closed]` workflow gated on a label (typically `auto-deploy`, `deploy`, `ship-it`) and/or a path filter, (4) the deploy workflow's run row in `gh run list` shows `conclusion=skipped` for your PR's branch — visually identical to `success` in the run summary. Distinct from `gha-auto-deploy-never-ran-skipped-mask` (sister skill: same "skipped masks failure" symptom class but different cause — that skill is about the FIRST time the gate fires and the deploy step then hits a permission gap; THIS skill is about the routine case where the gate correctly works and the PR simply didn't satisfy it). Trigger phrases: "I can't see the changes live", "merged but not deployed", "PR shipp

2026-07-082

name	pr-from-stale-branch-silently-reverts-newer-main-files
description	Trap: opening/merging a PR from a branch that was created a while ago can SILENTLY DELETE (revert) files that landed on main AFTER your branch point — with NO merge conflict to warn you. Use when: (1) about to `gh pr create` or squash-merge from a long-lived / earlier-branched branch; (2) `git diff origin/main..HEAD --stat` shows DELETIONS of files you never touched; (3) a PR diff is unexpectedly large or removes another session's/teammate's work; (4) the repo has many parallel branches + a squash-merge flow (each squash makes older branches progressively staler). The fix is to merge origin/main INTO the branch first, then re-verify the diff shows only your additions. Distinct from merge-CONFLICT skills — this is the no-conflict, clean-merge silent-regression case. See also: pr-conflict-from-mid-flight-merges, large-redesign-parallel-branch-collision-audit, merge-conflict-generated-files.
author	Claude Code
version	1.0.0
date	"2026-06-17T00:00:00.000Z"
disable-model-invocation	true

A PR from a stale branch can silently revert newer main files (no conflict)

Problem

Context / Trigger Conditions

About to gh pr create / gh pr merge --squash from a branch that's been around for more than a session or two, or in a repo with many parallel branches.
git diff --stat origin/main..HEAD lists files being removed that you have no memory of touching (e.g. someone else's analysis/handoff/docs from a sibling session that merged while you worked).
The PR's deletion count is suspiciously high for the work you did.
Squash-merge workflows make this WORSE over time: each squash rewrites main's history, so a branch that "was only a bit behind" reverts more with each sibling merge.

Solution

Before creating/merging the PR, always sanity-check the full diff stat:
```
git fetch origin main
git diff --stat origin/main..HEAD
```
Scan for --- / deletion lines on files outside your scope.
If you see spurious deletions, merge origin/main into your branch first (do NOT just merge the PR):
```
git merge origin/main --no-edit      # clean if your changes are file-disjoint
```
This re-adds B/C/D to your branch so they're no longer "deleted" in the diff.
Re-verify: git diff --stat origin/main..HEAD should now show ONLY your own additions/edits. Then push + PR.
If the merge DOES conflict, you've crossed into merge-conflict territory → hand off to pr-conflict-from-mid-flight-merges / merge-conflict-generated-files (generated-file union playbooks).

Verification

Post-merge-of-main, git diff --stat origin/main..HEAD lists only files you intended to change (no foreign deletions). The PR's "files changed" on GitHub matches your mental model of the work.

Example (this repo, S258, 2026-06-17)

Notes

The tell is deletions in the diff stat, not a conflict marker — conflict-only habits (rely on git to yell) miss this entirely.
Same root cause as large-redesign-parallel-branch-collision-audit (branches drift from main), but that skill is a pre-plan collision audit across many branches; this is the at-PR-time per-branch check + the merge-main-in fix.
gh pr merge --delete-branch may then fail with "main is already used by worktree at ..." when you run from a worktree — the merge still succeeded; delete the remote ref with gh api -X DELETE repos/<owner>/<repo>/git/refs/heads/<branch>.