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/cbdreamer11/cb-loop-kit-claude-plugin/loop-verifynpx skills add cbdreamer11/CB-loop-kit-claude-plugin --skill loop-verifygit clone --depth 1 https://github.com/cbdreamer11/CB-loop-kit-claude-pluginWrote 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/cbdreamer11/cb-loop-kit-claude-plugin/loop-verify)<a href="https://agentmods.dev/skills/cbdreamer11/cb-loop-kit-claude-plugin/loop-verify"><img src="https://agentmods.dev/badge/skills/cbdreamer11/cb-loop-kit-claude-plugin/loop-verify.svg" alt="Measured on agentmods" 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 | $0.00039 | $0.00635 |
| Opus 5 | $0.00019 | $0.00318 |
| Sonnet 5 | $0.00008 | $0.00127 |
| Haiku 4.5 | $0.00004 | $0.00064 |
Grade A, and why
loop-verify 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 — 57 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify for real
Read .loop/VERIFY.md and run the slots that apply to what changed. Then write down
what you observed, in the words of what you saw — not in the words of what you hoped.
The three things that are not verification
- A green build. It proves the code compiles. Nothing else.
- "I read the code and it looks right." The bug you are looking for is exactly the one that looks right.
- "It should work." Then it is not verified. Say that instead.
Add two more that fool people constantly:
- An exit code of 0 — a command can succeed while doing nothing.
- An HTTP 200 — many servers answer 200 for a page that does not exist. Verify by finding a string that only exists in the new behaviour, not by status code.
What counts
Each slot must produce an artifact or a direct observation:
- BUILD — the project's build/test command, green. Necessary, never sufficient.
- OBSERVE — the thing itself, doing its thing: a page rendered in a real browser with a clean console and a real interaction (click, type, navigate); a CLI run with its real output; an endpoint returning the new field. A screenshot or captured output is the artifact.
- DATA — query the store and confirm the effect: the row exists, the value changed, the wrong value is refused.
- MONEY — if money moves, use the provider's test mode and confirm the resulting state changed for real. Never test with live money.
Testing against a real system
If the project has a test database or a seeded environment, use it: set up, run,
tear down. That is the default. Working against a live system is an exception
that must be declared in .loop/VERIFY.md, and when it is unavoidable: wrap in a
transaction and roll back, or restore the fixtures afterwards and confirm nothing
was left behind.
Two traps worth naming: your own tooling may run with more privileges than a real user, which hides permission bugs — check with the actual role. And a check that passes for you may fail for a signed-out visitor — check both.
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 · 57 lines · 39 tokens per session scan A aaa8767af929
loop-verify is a skill published in the GitHub repository cbdreamer11/CB-loop-kit-claude-plugin (8 stars, last pushed 1mo ago), licensed MIT. It adds 39 tokens to every session and 635 once invoked, about $0.0002 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 skills, from other repositories
audit-context
Evaluates ambient context artifacts (CLAUDE.md, memory, local skills, settings hooks) for compatibility with swarm governance. Returns a classified report so users can address interference before launching a team.
agentic-workflow-audit
Use when reviewing or auditing an existing agent / LLM-pipeline architecture — e.g. 'is my workflow actually decomposed or secretly a mega-agent?', 'are my task boundaries and success criteria right?' — even without the word 'audit'. ｜ 要檢視／review／稽核既有 agent 或 LLM pipeline 的架構，或問「有沒有拆好」「是不是變成 mega agent」「task…
feature-execution
This skill should be used when the user asks to "orchestrate the feature", "run the phases", "resume implementation", "continue the plan", "the phase agent died", "the agent stopped on its usage limit", "accept this phase", "can these phases run in parallel", "is this phase done", "does this shortfall matter", or…
phase-agent
Use this agent when a phase of a zforge feature plan is ready to implement and its work should run in its own context. Typical triggers include $zforge:feature-orchestrate spawning a READY phase, resuming a phase whose agent was interrupted mid-run, and re-running a phase after a decision was rejected in review. See…
async-reasoning
This skill should be used when implementing or designing code with async data flows — "state management design", "async data flow", "stale data", "cache invalidation", "optimistic update", "init order", "race condition", "write then read", "data not updating", "cache not refreshing", "UI shows old data after save"…
retro
This skill should be used when the user asks to "retro", "evaluate zforge", "review plugin performance", "score this session", or wants to assess how well zforge's workflow served a feature. Evaluates zforge's workflow scaffolding, not the project's technical decisions or LLM reasoning quality.