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 commands/intentdriven/abcd/banlistgit clone --depth 1 https://github.com/intentdriven/abcdWhat 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.00050 | $0.01727 |
| Opus 5 | $0.00025 | $0.00864 |
| Sonnet 5 | $0.00010 | $0.00345 |
| Haiku 4.5 | $0.00005 | $0.00173 |
Grade A, and why
banlist 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 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.
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 — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/abcd:banlist — banned names, two layers
Some names must not appear in what a repo publishes: a specific agent harness (so the surface stays host-agnostic), a partner's product, a private project whose very name is confidential — and, most sensitively, the user's own machine identifiers: hostnames, device names, and the addresses or prefixes of their private network.
Enforcement splits by sensitivity, because a deterministic CI gate is the right tool for a public banned name and the wrong place for a private one: the rule would have to contain the very string it forbids.
| layer | store | enforced by | visibility |
|---|---|---|---|
| public | .abcd/docs-lint.json (the banned_tokens family) |
abcd docs lint in CI, with a per-line escape |
entries render in full |
| private | .abcd/.work.local/private-names.txt (gitignored) |
the committed .githooks/pre-commit and .githooks/pre-merge-commit guards, on this machine only |
entries render by key only |
Render both layers (bare)
"${CLAUDE_PLUGIN_ROOT}/abcd" banlist --json
Summarise the JSON: for private, its present flag and each entry's key —
never ask for or repeat a private pattern value, which the binary does not
emit; for public, each entry's id, severity, pattern, and whether it is
managed (verb-owned, id under names/) or hand-curated.
State the private layer's reach as the binary states it: relay the reach
sentence the render carries rather than paraphrasing it. Paraphrase drops the
second half, and the way it drops is by omission — "protects only machines that
have opted in" alone leaves a reader believing an opted-in machine is fully
covered. It is not: a hook sees the commits git asks it about, so a fast-forward
git pull, a rebase, a git am, a git revert or a cherry-pick bypasses it, as
does --no-verify, and that list is not exhaustive. When private.present is
false, say that the layer is inactive on this machine — an absent store checks
nothing, and silence must never look like protection.
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 · 122 lines · 50 tokens per session scan A 45720fd39485
banlist is a command published in the GitHub repository intentdriven/abcd (3 stars, last pushed 2d ago), licensed MIT. It adds 50 tokens to every session and 1,727 once invoked, about $0.0003 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-31.
Other commands, from other repositories
legal
Primary entry point for all BetterCallClaude requests — classifies intent, resolves jurisdiction (via swiss-legal-research), runs inline briefing for complexity 4–6, activates full briefing session when complexity ≥ 7 (via legal-intake skill), and routes to specialist agents or workflow pipelines. Invoked explicitly…
briefing
Structured pre-execution briefing session -- collects case context through specialist panel, builds execution plan, supports resume and depth control.
help
Show complete BetterCallClaude command reference, available agents, skills, and usage examples.
legal-5step
Execute the BetterCallClaude 5-step Swiss legal framework: intake → research → strategy → adversarial → draft. A complete end-to-end pipeline for any Swiss legal matter, from document analysis through final legal output.
legal-loop
Iterate a worker-evaluator cycle against a Goal Record until the success condition is met or a stop limit is reached. The evaluator (a different agent than the worker) judges each iteration using MCP verification tools. Produces an auditable verdict trail and a final MET / NOT MET status.
workflow
Define and execute multi-agent legal workflows -- due diligence, litigation prep, contract lifecycle, real estate closing.