multi-worktree-file-url-stale-contentlisted

When a user opens a `file://` URL bookmark to a file in a repo with multiple git worktrees, the browser shows whatever the targeted worktree's branch contains — NOT main, NOT the latest merge. Use when: (1) user reports "I don't see my change" or "the fix isn't there" right after a PR was merged, (2) you've confirmed via `git show origin/main:<path>` that main has the fix but the user-visible file:// view doesn't, (3) the file path mentioned by the user contains `.claude/worktrees/<name>/`, `worktrees/`, or any other multi-checkout root, (4) `git worktree list` shows 2+ paths and the bookmarked one is on a feature branch. Distinguishes from: `worktree-outer-ls-mistaken-for-main-state` (about `ls` outside any worktree), `flask-debug-cross-worktree-edit-stale` (about Flask debug reload reading wrong worktree). This skill specifically covers the user-bookmarks-a-file-URL variant where neither `ls` nor a server reload is in play — the browser opens whatever exists on disk in that worktree at that path.
wan-huiyan/agent-traffic-control · ★ 2 · Data & Documents · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# Multi-worktree `file://` URL stale content ## Problem The user opens a `file://` URL pointing to a deliverable / static HTML / docs file in the repo. They see old content. They report "the fix isn't there" or "I still see the thing we removed". They are correct about what they see — but the file IS fixed on `origin/main`. The disconnect is that the `file://` URL doesn't know what git branch is checked out at that path. The browser just reads whatever bytes are on disk. In a repo with multiple `git worktree` checkouts, each worktree is on a different branch. The primary checkout at the repo root is *also* on a branch — usually the last feature branch someone was working on, NOT main. After a PR merges to main, none of the on-disk paths automatically update. The user's bookmark keeps showing the same stale content. ## Context / Trigger Conditions All of: - Repo uses git worktrees (`git worktree list` shows 2+ entries) - File in question is a deliverable / static asset / docs file that humans open directly (HTML, MD-rendered-to-HTML, JSON viewer, PDF), not a service-rendered URL - User opens it via `file://` URL bookmark (not via a running web server, not via VSCode preview) - Recent merge to main updated that file - User reports the file looks wrong / old / unchanged Smoking-gun signal: the user-reported file path contains `.claude/worktrees/<name>/`, `worktrees/`, `.git/worktrees/`, or you can see `2+` worktrees via `git worktree list` and the bookmarked path is one o