Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/jfrog/agent-beltnpx agentmods add skills/jfrog/agent-belt/beltWrote 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/jfrog/agent-belt/belt)<a href="https://agentmods.dev/skills/jfrog/agent-belt/belt"><img src="https://agentmods.dev/badge/skills/jfrog/agent-belt/belt/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/jfrog/agent-belt/belt"><img src="https://agentmods.dev/badge/skills/jfrog/agent-belt/belt.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00116 | $0.04086 |
| Opus 5.5 | $0.00046 | $0.01634 |
| Sonnet 5.5 | $0.00023 | $0.00817 |
| Haiku 4.5 | $0.00012 | $0.00409 |
Grade A, and why
belt 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 2mo 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 — 327 lines — stays where its author put it; the contents beside it link to each section on GitHub.
agent-belt
belt is a CLI that evaluates headless coding-agent CLIs by running multi-turn scenarios against
them and scoring the results with rule-based checks plus optional LLM judges. The belt console
script is the only public surface - never import internals.
1. Verify install before doing anything
belt doctor
Checks Python, registered agents (auth + reachability), LLM scoring providers (cloud keys + Ollama),
and which belt clone the command resolves to. If doctor is unhappy, fix what it reports
before attempting anything else - most user-reported problems are solved by reading its output.
belt agent list # registered agents (entry-point discovered)
belt agent info <name> # capabilities of one agent (cli_options, env vars, fields it supports)
2. Run an evaluation
belt eval chains run → score → aggregate in one command. Start here.
belt quickstart # auto-detect, single rules-only
belt eval examples/scenarios/showcase --modes rules --tags real-runnable # whole runnable showcase
belt eval my-scenarios/ --modes rules,llm --workers 3 # rules + LLM judge, parallel
belt eval my-scenarios/ --dry-run # list matched scenarios, no run
belt eval my-scenarios/ --modes rules --export junit:report.xml # JUnit report for CI test reporters
--modes rules runs without any judge or API key - use it for fast feedback and CI smoke tests.
--modes llm (or rules,llm) requires an LLM judge configured (see §5).
Scenario filtering is path-relative to the directory passed as <path>; if the path itself is a group
(contains _config.json), --scenarios takes the bare scenario name. Tag filters use AND semantics
across the listed tags.
Subcommand index, common workflows, and progress modes:
docs/glossary/CLI.md.
The canonical per-flag reference is belt <subcommand> --help.
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.
- 2mo ago First seen · 327 lines · 116 tokens per session scan A 2046876b4744
belt is a skill published in the GitHub repository jfrog/agent-belt (19 stars, last pushed 22d ago), licensed Apache-2.0. It adds 116 tokens to every session and 4,086 once invoked, about $0.0005 per session on Opus 5.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
verify-work
Prove that code, a script or a page you just produced actually runs — execute it, read the real output, and fix what breaks before reporting. Use after writing or changing anything executable, and whenever you are about to say something is done, working, or fixed.
agent-eval
Use when measuring whether an LLM or agent system actually got better and gating merges on it: golden sets, fixing an inflated LLM-as-judge, scoring RAG (faithfulness, contextual recall) or agent trajectories (tool correctness, completion), or picking an eval framework. NOT building the agent loop, tools or RAG…
meter-benchmark
Measure per-stage success probability before iterating on CocoFlow templates. Supports $meter benchmark --flow .
browser-qa
Testing web apps through a real browser: reconnaissance before acting, selector discovery, state capture, console errors and screenshot evidence. Use on a web surface end to end, or to reproduce a front-end bug.
test-driven-development
Writing code with tests first: RED-GREEN-REFACTOR, reproduce bugs as failing tests before fixing, and avoid testing anti-patterns. Use when implementing behaviour, fixing a defect, or asked to add tests.
verification-before-completion
Proving work works before claiming it does: exercise the real path, read the actual output, gather fresh evidence per claim, and say what remains unverified. Use before reporting done, handing off, or posting results.