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/encod3d-sec/torch/fuzznpx skills add Encod3d-Sec/TORCH --skill fuzzgit clone --depth 1 https://github.com/Encod3d-Sec/TORCHWhat 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.00177 | $0.01463 |
| Opus 5 | $0.00088 | $0.00732 |
| Sonnet 5 | $0.00035 | $0.00293 |
| Haiku 4.5 | $0.00018 | $0.00146 |
Grade A, and why
fuzz 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 — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
fuzz - adaptive web fuzzing
0. Profile (do this first)
Read engagement_type from the active targets/<eng>/state.md frontmatter and set the profile:
- ctf - loud/fast, ignore WAF, recurse deep, exhaust the big list.
- pt - calibrated rate, obey RoE flags (
no_bruteforce/no_dos-> SKIP the brute tiers entirely). - bb - stealth: low rate + jitter, watch for the ban BEFORE it lands, request-budget aware.
wl-pick.shemits the profile flags; you apply them.
1. Two axes
- Surface (widen): content, files, vhost, api, artifacts. Recursive by default.
- Parameter (deepen): once an endpoint takes input, fuzz hidden params. Triggered by OBSERVING a param-accepting endpoint, never blind.
2. Select (deterministic) - always via wl-pick.sh
# what to run for a surface, given the engagement type and any fingerprint:
bash scripts/wl-pick.sh content "" ctf # generic content discovery
bash scripts/wl-pick.sh content wordpress bb # WordPress-aware, BB-stealth
bash scripts/wl-pick.sh vhost "" pt
bash scripts/wl-pick.sh params "" bb
It prints the seclists base, the profile flags line, and the ordered absolute paths (T0 harness -> T3 fingerprint list -> T1 surface lists, size-ordered). NEVER hand-pick a list from memory and NEVER start with directory-list-2.3-medium (220k). The size order is already correct in the output; run top-to-bottom, stop climbing when you have enough signal.
3. Calibrate (native first, backstop with judgment)
- Default to ffuf
-ac/-accand feroxbuster auto-filtering. - If a wildcard/soft-404 fools
-ac(everything returns 200 with varying size): fire 2-3 known-bogus random paths first, read status/size/words, then set explicit-fs/-fwon the catch-all baseline, or-mc 200,301,302,401,403on a clean 404. - READ tool output END-TO-END, never a grep. A real hit hides in the noise.
4. Climb tiers on SIGNAL (the adaptive core)
Climb T0 -> T1 -> T2 -> T3 when the current tier is exhausted OR a fingerprint unlocks a better list:
- T2 cewl when T0/T1 run dry:
cewl -d 3 -m 5 --lowercase -w targets/<eng>/custom-words.txt https://TARGETthen feed that list back through the same axis. See [[cewl]]. - T3 app-specific the moment you fingerprint a known product: re-run
wl-pick.sh <surface> <product> <type>to jump straight to its shipped list. For a product with no shipped list,Skill(wiki-arsenal)for its known paths, then cewl its docs / proberobots.txtsitemap.xmlswagger.jsonopenapi.json.
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 · 55 lines · 177 tokens per session scan A 5d448e65d763
fuzz is a skill published in the GitHub repository Encod3d-Sec/TORCH (282 stars, last pushed 5d ago), licensed MIT. It adds 177 tokens to every session and 1,463 once invoked, about $0.0009 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
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…