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 agentmods add skills/scarletkc/agents/worktree-prnpx skills add scarletkc/agents --skill worktree-prgit clone --depth 1 https://github.com/scarletkc/agentsWhat 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 | $0.00148 | $0.01011 |
| Opus 5 | $0.00074 | $0.00505 |
| Sonnet 5 | $0.00030 | $0.00202 |
| Haiku 4.5 | $0.00015 | $0.00101 |
Grade A, and why
worktree-pr 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 3d 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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Worktree & PR
A worktree buys two things: the main working copy stays usable while the task runs, and the untouched copy remains available as a baseline to compare against. Both are worth real setup cost, and neither applies to every change.
This covers the isolation mechanics. How large the change itself should be is
scoped-change,
and it applies inside a worktree exactly as it does anywhere else.
Deciding
Consider a worktree when at least one holds: the task is large enough that a half-finished state would block other work, several tasks need to progress on the same repository at once, the result has to be compared against current behavior, or the change is risky enough that abandoning it should cost nothing.
Skip it when the change is small, self-contained, and reviewable in one pass. Setting up an isolated copy for a typo fix or a one-line config edit costs more than it saves, and the extra branch, directory, and PR are all overhead that someone pays later. When the requester says to work directly on the current branch, that decision is already made.
Running
- Branch from the integration branch, not from whatever is checked out. The point of the isolated copy is a clean starting state; inheriting unrelated in-progress edits forfeits it and makes the eventual diff unreadable. Fetch first so the base is current, not a stale local ref.
- Leave the main working copy alone while the task runs. Editing both defeats the isolation and destroys the baseline. If the task turns out to need a change in the main tree, stop and say so rather than reaching across.
- Parallel worktrees stay independent only while they stay disjoint. Two copies of one repository editing the same files converge into a conflict nobody scheduled, and the cost lands at merge time rather than now. Before opening a second one, check what the first is touching.
- Name the artifacts' destination explicitly. Screenshots, builds, and exports produced inside a worktree vanish with it. Anything the requester needs to see must be written somewhere durable, or attached to the PR, and the location has to be stated rather than assumed.
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.
- 3d ago First seen · 78 lines · 148 tokens per session scan A fafbbc4f786a
worktree-pr is a skill published in the GitHub repository scarletkc/agents (191 stars, last pushed 6d ago), licensed Apache-2.0. It adds 148 tokens to every session and 1,011 once invoked, about $0.0007 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-08-30.
Other skills, from other repositories
map-plan
ARCHITECT phase - decompose complex tasks into atomic subtasks with research, spec, and branch-scoped plan artifacts under .map.
map-review
Interactive 4-section code review using monitor, predictor, and evaluator agents plus the user and maintainer role reviewers on current changes. Use when reviewing a diff, PR, or staged work before merge. Do NOT use to plan or implement; use map-plan or map-efficient.
map-learn
Capture reusable lessons after a completed MAP workflow. Use when a MAP run has finished and you want rules written to .claude/rules/learned/ from a workflow summary or handoff. Do NOT use during active implementation.
map-efficient
State-machine MAP execution workflow for Codex. Use when implementing an approved MAP plan end to end, resuming from branch MAP taskplan or stepstate.json artifacts, or running non-trivial multi-subtask work. Use map-fast for tiny one-shot edits.
map-task
Execute a single subtask from an existing MAP plan via Actor and Monitor. Use when map-plan has decomposed work and you want fine-grained control over one subtask. Do NOT use without an existing plan; run map-plan first.
ubiquitous-language
Maintain a project thesaurus (domain glossary) following DDD ubiquitous language principles. Use PROACTIVELY when naming anything: variables, functions, classes, modules, database fields, API endpoints, events, files, or directories. Also use when the user asks to "create thesaurus", "update glossary", "add term"…