multi-worktree-file-url-stale-content

Diagnoses stale file:// bookmark content caused by git worktrees parked on old branches.

3|Updated May 8, 2026
One-click install
npx skills add https://github.com/wan-huiyan/agent-traffic-control --skill multi-worktree-file-url-stale-content-wan-huiyan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: multi-worktree-file-url-stale-content
Source: https://github.com/wan-huiyan/agent-traffic-control/tree/main/plugins/agent-traffic-control/skills/multi-worktree-file-url-stale-content
Command: npx skills add https://github.com/wan-huiyan/agent-traffic-control --skill multi-worktree-file-url-stale-content-wan-huiyan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? In repos with multiple git worktrees, a user who bookmarks a file:// URL to a deliverable file sees whatever branch that worktree is parked on — not main. After a PR merges, the user reports "the fix isn't there" even though origin/main is correct, because the browser simply reads the stale bytes on disk in that worktree. ## Core Features & Use Cases - Stale-content diagnosis: Confirms via git fetch + git show origin/main:<path> that the fix landed on main, then matches the user's file path against git worktree list to identify which worktree and branch the bookmark actually resolves to. - Canonical worktree setup: Establishes one worktree (usually the primary checkout) as the always-on-main bookmark target, including a safe audit (clean status, no unpushed commits, tracked .claude-memory/) before removing a worktree that holds main. - Use Case: A PM walkthrough HTML file still shows a removed card after PR #911 merged. The bookmark pointed at .claude/worktrees/quick-verify/ on a stale feature branch; the fix was to reclaim main on the primary checkout and hand the user a new bookmark URL. ## Quick Start Ask the assistant to check why a file:// bookmark still shows old content after a PR merged, and have it verify the file on origin/main and inspect git worktree list.

Frequently Asked Questions about multi-worktree-file-url-stale-content

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does my file:// bookmark show old content after the PR merged?▼

The file:// URL reads whatever bytes exist on disk at that path, and in a multi-worktree repo that path belongs to a worktree parked on an old branch. The merge updated origin/main, but no local worktree updates automatically.

How do I check which git worktree a file path belongs to?▼

Run git worktree list and match the absolute path from the file:// URL against the listed worktree paths. The branch shown in the third column is the content the browser is actually displaying.

How do I verify a fix is actually on main before blaming the worktree?▼

Run git fetch origin main, then git show origin/main:<path> and grep for the stale string. If the count is zero on main but the user's view still shows it, the problem is a stale worktree, not the merge.

Is it safe to remove a git worktree that is holding the main branch?▼

Yes, after auditing: confirm git status is clean, git log origin/main..HEAD shows no unpushed commits, and any .claude-memory files are tracked in git. Stashes are repo-wide and survive worktree removal.

Does this apply to pages served by a local Flask dev server?▼

No. This skill covers only file:// URLs opened directly in a browser. For Flask debug servers reading the wrong worktree, use the flask-debug-cross-worktree-edit-stale skill instead.

What is an alternative to bookmarking a local file:// path?▼

Bookmark the GitHub blob URL (https://github.com/<owner>/<repo>/blob/main/<path>), which always reflects main without local sync. The tradeoff is losing local-only rendering and slower access.