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 FlorianBruniaux/claude-code-plugins --skill git-worktree-statusgit clone --depth 1 https://github.com/FlorianBruniaux/claude-code-pluginsWrote 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/florianbruniaux/claude-code-plugins/git-worktree-status)<a href="https://agentmods.dev/skills/florianbruniaux/claude-code-plugins/git-worktree-status"><img src="https://agentmods.dev/badge/skills/florianbruniaux/claude-code-plugins/git-worktree-status.svg" alt="Measured on agentmods" 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.00017 | $0.01260 |
| Opus 5 | $0.00009 | $0.00630 |
| Sonnet 5 | $0.00003 | $0.00252 |
| Haiku 4.5 | $0.00002 | $0.00126 |
Grade C, and why
git-worktree-status scanned grade C with 1 finding 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 2d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf .worktree-logs/*.log How it starts
The opening of the file, as written. The whole thing — 167 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Worktree Status
Check background verification tasks (type check, tests, build) launched by /git-worktree.
Core principle: Non-blocking feedback on worktree health without interrupting development flow.
Part of: Worktree Lifecycle Suite | /git-worktree | /git-worktree-remove | /git-worktree-clean
Process
- Detect Current Worktree: Verify we're inside a git worktree
- Check Log Files: Read
.worktree-logs/for background task results - Parse Results: Extract pass/fail counts, errors
- Report Status: Color-coded summary with actionable next steps
Worktree Detection
# Check if inside a worktree (not main repo)
git rev-parse --git-common-dir 2>/dev/null | grep -q "\.git/worktrees" || {
echo "Not inside a worktree. Use from a worktree directory."
exit 1
}
# Get worktree info
WORKTREE_PATH=$(git rev-parse --show-toplevel)
BRANCH=$(git rev-parse --abbrev-ref HEAD)
MAIN_REPO=$(git rev-parse --git-common-dir | sed 's|/\.git/worktrees/.*||')
Background Task Checks
Type Check Status
LOG=".worktree-logs/typecheck.log"
if [ -f "$LOG" ]; then
if grep -q "error TS" "$LOG"; then
ERROR_COUNT=$(grep -c "error TS" "$LOG")
echo "Type check: FAIL ($ERROR_COUNT errors)"
# Show first 5 errors
grep "error TS" "$LOG" | head -5
else
echo "Type check: PASS"
fi
elif pgrep -f "tsc --noEmit" > /dev/null; then
echo "Type check: RUNNING..."
else
echo "Type check: NOT RUN"
fi
Test Status
LOG=".worktree-logs/tests.log"
if [ -f "$LOG" ]; then
if grep -q '"numFailedTests":0' "$LOG"; then
TOTAL=$(grep -o '"numTotalTests":[0-9]*' "$LOG" | cut -d: -f2)
echo "Tests: PASS ($TOTAL tests)"
else
FAILED=$(grep -o '"numFailedTests":[0-9]*' "$LOG" | cut -d: -f2)
echo "Tests: FAIL ($FAILED failures)"
# Show failed test names
grep '"fullName"' "$LOG" | head -5
fi
elif pgrep -f "vitest run" > /dev/null; then
echo "Tests: RUNNING..."
else
echo "Tests: NOT RUN"
fi
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.
- 2d ago First seen · 167 lines · 17 tokens per session scan C b2686006a0eb
git-worktree-status is a skill published in the GitHub repository FlorianBruniaux/claude-code-plugins (40 stars, last pushed 5d ago), licensed MIT. It adds 17 tokens to every session and 1,260 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other skills, from other repositories
workflow-patterns
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
verify-implementation
A workflow that runs a project’s verification skills to produce a report on coding patterns, architecture rules, and project conventions. It is intended for work after implementation, before a pull request, or during code review.
security-pipeline
Use when security verification is needed - pre-commit security checks, vulnerability scanning, STRIDE threat analysis. Integrates with /handoff-verify --security and /commit-push-pr. CWE Top 25 based.
testing-conventions
Test conventions across this portfolio — regression-test comment format, property-test setup for TS and Python, the financial-math arbitrary settings that were tuned by measurement, and why a failing check may be pinning a defect rather than reporting one. Load before writing tests, adding a regression test to a bug…
dependency-upgrade
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
fix
Bug-fix fast lane — the entry point for fixing something already broken (a red test, a prod error, a reported defect), not building a new feature. Does the bug-specific part — reproduce as a failing test, find the root cause, write a minimal fix-plan — then hands off to the existing pipeline (/implement → /review →…