Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add wan-huiyan/agent-traffic-control --skill working-tree-edits-stranded-on-squash-mergegit clone --depth 1 https://github.com/wan-huiyan/agent-traffic-controlWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/wan-huiyan/agent-traffic-control/working-tree-edits-stranded-on-squash-merge)<a href="https://agentmods.dev/skills/wan-huiyan/agent-traffic-control/working-tree-edits-stranded-on-squash-merge"><img src="https://agentmods.dev/badge/skills/wan-huiyan/agent-traffic-control/working-tree-edits-stranded-on-squash-merge/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/wan-huiyan/agent-traffic-control/working-tree-edits-stranded-on-squash-merge"><img src="https://agentmods.dev/badge/skills/wan-huiyan/agent-traffic-control/working-tree-edits-stranded-on-squash-merge.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00236 | $0.01833 |
| Opus 5 | $0.00118 | $0.00916 |
| Sonnet 5 | $0.00047 | $0.00367 |
| Haiku 4.5 | $0.00024 | $0.00183 |
Grade A, and why
working-tree-edits-stranded-on-squash-merge scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 176 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Working-tree edits stranded by a squash-merge
Problem
You're iterating on a PR through an acceptance pass. The user surfaces a bug; you make an Edit() call; the bug is fixed locally; the user confirms; you move on to the next bug. A few iterations later you squash-merge the PR. The user reloads the page and says "the bug is back."
The fix is sitting in your working tree, never staged, never committed.
The squash captured everything committed on the branch — but Edit() and
Write() don't auto-stage. When you did git add <other_file> for the
follow-up bug, only that file went into the commit; the earlier Edit'd
file stayed in the working tree as a modified-but-uncommitted change.
After merge: git status shows M <file_you_edited>, the merged squash on
<base_branch> has the old content, and the user sees the bug return.
Context / Trigger Conditions
All of these together strongly indicate this pattern:
- You used Edit() or Write() on a file during an interactive PR-review pass (i.e. you applied the fix to "make the live server / preview reflect it" for the user to verify, but didn't think of it as a commit-worthy unit).
- The user later flagged a different bug; you fixed THAT one with
git add <different_file>+git commit. - Now the PR is merged but the working tree (when you re-enter the
worktree) shows
M <file_from_step_1>. - The squash commit on
<base_branch>does NOT include the changes from step 1. - User-facing symptom: the original bug reappears as if the fix never landed.
Solution
Prevent — pre-merge audit
Before any gh pr merge, run:
git status --short # any `M` or `??` lines?
git diff # any uncommitted hunks?
git diff origin/<base_branch> # confirm the diff matches your mental model
If git status shows un-staged modifications, decide for each one:
- Should it be part of THIS PR? →
git add <file>+ commit + push (then merge). - Should it stay local? → stash or .gitignore it explicitly so you know it's intentionally not in the PR.
- Is it a leftover from a prior session? → triage (rarely common but happens in long-running worktrees).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 176 lines · 236 tokens per session scan A 9eda90a4cb0f
working-tree-edits-stranded-on-squash-merge is a skill published in the GitHub repository wan-huiyan/agent-traffic-control (3 stars, last pushed 6d ago), licensed MIT. It adds 236 tokens to every session and 1,833 once invoked, about $0.0012 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-05.
Other skills, from other repositories
misuzu
Respond to PR review comments semi-automatically. Fetches all review threads and comments, splits them into logical units, fixes and commits one unit at a time, then replies and resolves review threads. Use when the user wants to address PR review feedback or respond to review comments.
pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
claude-code-bash-patterns
Claude Code Bash tool patterns with hooks, automation, git workflows. Use for PreToolUse hooks, command chaining, CLI orchestration, custom commands, or encountering bash permissions, command failures, security guards, hook configurations.
simplify
Use when the user says "simplify this diff" or asks for a compression pass over a change-set. Not for dead-code sweeps: use deslop.
pr-check
PR review compliance: fetch review comments from an open PR, categorize as resolved/unresolved/dismissed, critically evaluate fixable items, implement approved fixes, and reply inline. Pass --unattended to halt on human-judgment items (emitted as Pending-Human) instead of prompting via AskUserQuestion.