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/thurbeen/thurbox/thurbox-agentsnpx skills add Thurbeen/thurbox --skill thurbox-agentsgit clone --depth 1 https://github.com/Thurbeen/thurboxWrote 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/thurbeen/thurbox/thurbox-agents)<a href="https://agentmods.dev/skills/thurbeen/thurbox/thurbox-agents"><img src="https://agentmods.dev/badge/skills/thurbeen/thurbox/thurbox-agents.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 | $0.00000 | $0.02390 |
| Opus 5 | $0.00000 | $0.01195 |
| Sonnet 5 | $0.00000 | $0.00478 |
| Haiku 4.5 | $0.00000 | $0.00239 |
Grade A, and why
thurbox-agents 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 today.
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 — 156 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Thurbox agent definitions
Working reference extracted from CLAUDE.md, which indexes it. The rationale behind these decisions is owned by the docs under docs/; a change that invalidates what this says updates it in the same PR.
Agent Definitions
Per-agent reference + the "adding a new built-in" checklist:
docs/AGENTS.md(each built-in's exact config, ID model, and status-hook mechanism, plus every file to update when promoting a CLI to a built-in).
The set of launchable coding agents is declared as data in
~/.config/thurbox/agents.toml, seeded with built-ins
(claude, codex, antigravity, opencode, aider, copilot, vibe, pi, omp)
plus shell on first run.
shell is the one seeded entry that is not a coding agent: the platform's own
interactive shell (bash -i, or powershell -NoLogo on native Windows, where
the multiplexer is psmux). It exists so a session can be anything, and it is
the ready-made form of session create --command. Because it declares no
resume_args/fork_args, it also documents the rule by example: those groups
are the conversation address, and an entry without them can be restarted but
never resumed. A raw --command session behaves identically — thurbox builds it
a synthetic AgentDef with empty arg groups and persists the recipe on the
session row, since there is no agents.toml entry to re-resolve at restart.
Each [[agents]] entry is an AgentDef:
default = "claude"
[[agents]]
name = "claude"
command = "claude"
args = [] # always passed; bake a model here if you want one
resume_args = ["--resume", "{id}"] # emitted when resuming
fork_args = ["--resume", "{id}", "--fork-session"]
new_session_args = ["--session-id", "{id}"] # emitted on a fresh spawn
[[agents]]
name = "codex"
command = "codex"
resume_args = ["resume", "--last"] # id-less: resumes the last session in cwd
fork_args = ["fork", "--last"]
resume_latest = true
Each *_args group is appended only when its driving value is
present, with {id} substituted; args is always passed. No
model is ever passed — each agent uses its own default config
(put ["--model", "opus"] in args if you want to pin one).
A second token, {home}, expands (at spawn, on the spawn worker —
session_ops::expand_home_in_def, called from
spawn::adapt_def_for_launch, which both a fresh launch and
session_ops::restart go through) to the resolved home dir — the remote home for an
SSH/WSL host — so an agent that wants a session file path rather than a
bare id (the built-in omp, below) launches against a concrete,
quote-safe absolute path (a literal ~ would never expand — args are
POSIX-quoted).
Agents that omit resume_args simply start fresh on restart (the
live tmux process is what carries state across TUI restarts). Add
your own [[agents]] entry to support any CLI — no recompile.
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.
- today Changed · +11 lines 8e77daa19239
- 4d ago First seen · 145 lines · 0 tokens per session scan A 04e3cecce6c3
thurbox-agents is a skill published in the GitHub repository Thurbeen/thurbox (60 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,390 tokens. 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…