Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

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

Estrellas2

Forks0

Actualizado8 de julio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

wan-huiyan

wan-huiyan/agent-traffic-control

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·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>.

Más de este repositorio

mismo repositorio

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>.