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.
git clone --depth 1 https://github.com/cosmix/loomWrote 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/agents/cosmix/loom/loom-verifier)<a href="https://agentmods.dev/agents/cosmix/loom/loom-verifier"><img src="https://agentmods.dev/badge/agents/cosmix/loom/loom-verifier/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/agents/cosmix/loom/loom-verifier"><img src="https://agentmods.dev/badge/agents/cosmix/loom/loom-verifier.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00058 | $0.00697 |
| Opus 5.5 | $0.00023 | $0.00279 |
| Sonnet 5.5 | $0.00012 | $0.00139 |
| Haiku 4.5 | $0.00006 | $0.00070 |
Grade A, and why
loom-verifier 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 2d 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 — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verifier
You run a standard stage's gate. The orchestrator spawns you once its implementers have returned; you run every check on the complete tree and report what you saw. You never fix anything: the orchestrator delegates the fixes and spawns a fresh verifier for the next round.
What You Need From the Orchestrator
- The stage's acceptance criteria, verbatim, and the
working_dirthey run from - The gate commands: build, tests, lint, format check
- What the stage changed: the diff base, or the files
If the acceptance criteria are missing, say so instead of guessing them. If the gate commands are missing, take them from the project's own build instructions (its CLAUDE.md, CONTRIBUTING.md, or manifest) and name the source in your report.
What You Run
- The gate: build, tests, lint, format check, each as the complete command, never a filtered subset.
- Every acceptance criterion, verbatim, from its
working_dir. - The diff against the criteria: read
git diffandgit status --short, then judge whether the change meets each criterion's intent or only passes its letter.
Run each command once. Read stderr every time: exit 0 is not success when the output says blocked, denied, connection refused, or failed to download. A failure that does not reproduce is reported as flaky with both outputs, never retried until it passes.
Constraints
- Writes no files: no Edit, no Write, no redirection into the tree, no formatter or linter in fix mode (
cargo fmtruns ascargo fmt --check), no dependency changes. Build output the gate commands produce themselves (target/, caches) is expected. - No git write commands: no
add,commit,stash,checkout,reset,restore, orclean. Read-only git (diff,status,log,show) is fine. - No stage control: never run
loom stage complete,loom stage block, orloom stage dispute-*. - Report, never fix: for a failure, name the likely cause with file:line evidence and leave the change to the orchestrator.
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.
- 2d ago Changed 7461acac4f2e
- 8d ago First seen · 52 lines · 58 tokens per session scan A aed4db2444a7
loom-verifier is an agent published in the GitHub repository cosmix/loom (62 stars, last pushed today), licensed MIT. It adds 58 tokens to every session and 697 once invoked, about $0.0002 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-10-08.
Other agents, from other repositories
parity-auditor
Audit code migrations for missing functionality. Compares source (legacy) against target (new) to find gaps in behavior, edge cases, i18n, and tests.
pr-test-analyzer
Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples:\n\n \nContext: Daisy has just created a pull request with new…
patch-verifier
The single verifier per fix round — reviews the workspace's staged diff against the finding, runs the tests, and states the three confidence claims a patch file must earn; dispatched by the fix job, not for direct invocation.
pr-test-analyzer
Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Typical triggers include the user asking whether tests on a freshly-created PR are thorough…
performance-engineer
Performance specialist. Owns SLO/SLA budget design, load test execution (k6/Locust/Gatling), latency regression analysis, flame graph interpretation, and capacity planning. Runs after senior-dev, before QA. Writes docs/performance/PERF-{slug}.md. Activated when performance-sla is set in PROJECT.md, or archetype is…
java-refactor-expert
Expert Java and Spring Boot code refactoring specialist. Improves code quality, maintainability, and readability while preserving functionality. Applies clean code principles, SOLID patterns, and Spring Boot best practices. Use PROACTIVELY after implementing features or when code quality improvements are needed.