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/thevibeworks/deva/deva-cleannpx skills add thevibeworks/deva --skill deva-cleangit clone --depth 1 https://github.com/thevibeworks/devaWhat 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.00071 | $0.00869 |
| Opus 5 | $0.00036 | $0.00434 |
| Sonnet 5 | $0.00014 | $0.00174 |
| Haiku 4.5 | $0.00007 | $0.00087 |
Grade C, and why
deva-clean 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 yesterday.
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 on the wrong one destroys a live repo on the host. And because How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
deva-clean: mount-safe workspace disk cleanup
A deva workspace mixes two kinds of directories that look identical in
ls: bind mounts declared in .deva (live host repos) and local dirs
created during work (git worktrees, node_modules, package stores).
rm -rf on the wrong one destroys a live repo on the host. And because
the workspace root is itself a host mount, local dirs still consume
host disk - usually the disk that is actually full.
Two passes. Pass one is deterministic and scripted; pass two executes only what got approved.
Pass one: triage
Run the bundled script - read-only, emits the tiered plan, never deletes:
scripts/triage.sh [workspace] [--fetch]
It maps mounts from /proc/mounts (ground truth - .deva drifts), shows which disk is under pressure, walks the non-mount dirs, gives every candidate four verdicts (type, dirty, pushed, freshness), and finds stale worktree metadata in the mounted parent repos. Verdict semantics live in the script header; two encode traps worth knowing:
- The pushed test is live ls-remote SHA comparison plus ancestry in the default branch - never upstream config. A branch created off origin/develop shows "ahead 1" while never pushed itself.
- MERGED is monotonic, provable even against stale refs. Absence is not: a branch absent on remote with stale refs is UNVERIFIED, not safe. Rerun with --fetch for a definitive verdict.
Then layer the judgment the script refuses to automate:
- Pressure: container overlay genuinely full (rare - on shared-VM runtimes overlay df reports the whole VM disk) means container caches (~/.cache, package stores) are the target, not the workspace.
- Stray files: the script walks dirs only; shell-typo artifacts like "&1" are yours to spot.
- Promotions: KEEP entries flagged MODIFIED TRACKED FILES move to tier 2 only when you can name every dirty file as a generated artifact (lockfiles, test output) and say so in the plan.
- Demotions: tier 1/2 entries that are functionally live - symlink targets, open-PR checkouts - move to keep.
- Keepers: offer cache-prune (node_modules, dist, coverage) as the low-risk alternative; for LOCAL-ONLY work, say exactly what would be lost and suggest pushing it.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 76 lines · 71 tokens per session scan C de97f975c4b3
deva-clean is a skill published in the GitHub repository thevibeworks/deva (13 stars, last pushed 5d ago), licensed MIT. It adds 71 tokens to every session and 869 once invoked, about $0.0004 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-08-30.
Other skills, from other repositories
stop-slop
Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.
web3-audit
Smart contract security audit — 10 DeFi bug classes (accounting desync, access control, incomplete path, off-by-one, oracle, ERC4626, reentrancy, flash loan, signature replay, proxy), pre-dive kill signals (TVL < $500K etc), Foundry PoC template, grep patterns for each class, and real Immunefi paid examples. Use for…
report-writing
Bug bounty report writing for H1/Bugcrowd/Intigriti/Immunefi — report templates, human tone guidelines, impact-first writing, CVSS 3.1 scoring, title formula, impact statement formula, severity decision guide, downgrade counters, pre-submit checklist. Use after validating a finding and before submitting. Never use…
web2-recon
Web2 recon pipeline — subdomain enumeration (subfinder, Chaos API, assetfinder), live host discovery (dnsx, httpx), URL crawling (katana, waybackurls, gau), directory fuzzing (ffuf), JS analysis (LinkFinder, SecretFinder), continuous monitoring (new subdomain alerts, JS change detection, GitHub commit watch). Use when…
triage-validation
Finding validation before writing any report — 7-Question Gate (all 7 questions), 4 pre-submission gates, always-rejected list, conditionally valid with chain table, CVSS 3.1 quick reference, severity decision guide, report title formula, 60-second pre-submit checklist. Use BEFORE writing any report. One wrong answer…
pentest-checklist
Comprehensive checklist for planning, executing, and following up on penetration tests.