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 skills add sjarmak/coding-agent-workflows --skill verification-loopgit clone --depth 1 https://github.com/sjarmak/coding-agent-workflowsWrote 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/sjarmak/coding-agent-workflows/verification-loop)<a href="https://agentmods.dev/skills/sjarmak/coding-agent-workflows/verification-loop"><img src="https://agentmods.dev/badge/skills/sjarmak/coding-agent-workflows/verification-loop/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/sjarmak/coding-agent-workflows/verification-loop"><img src="https://agentmods.dev/badge/skills/sjarmak/coding-agent-workflows/verification-loop.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.00033 | $0.00828 |
| Opus 5.5 | $0.00013 | $0.00331 |
| Sonnet 5.5 | $0.00007 | $0.00166 |
| Haiku 4.5 | $0.00003 | $0.00083 |
Grade A, and why
verification-loop 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 16d 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.
This is a copy
91% identical to verification-loop — 131 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 44 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verification Loop
Use the repository's configured quality gates. Preserve real exit statuses and enough output to diagnose failures; do not pipe a checker through head or tail and treat the pipeline's status as the check's result. Capture logs first if output needs summarizing. Missing tools and skipped checks are not passes.
Establish what must hold
For significant behavioral changes, list acceptance properties and connect each to relevant code and tests. For state/concurrency changes include event ordering, ownership, cancellation, retries, and cleanup where applicable. For core logic include boundary conditions and input/output contracts. Derive expectations from requirements, not from the implementation under test. For pure logic (parsers, codecs, round-trips, arithmetic, ordering, state machines) write the properties before reading the implementation and run them as property tests with the language's library (Hegel, or Hypothesis for Python; see the property-testing skill). A shrunk counterexample is a reproduced defect; pin it as an explicit regression test in the fix commit.
Use the formal-methods skill for targeted modeling when required by the task or justified by risk. Ordinary changes need proportionate tests, not mandatory Lean/TLA+ projects. Keep existing coverage requirements; coverage measures executed code, not whether the right property was asserted.
Run applicable gates
- Build: use the project's build command; resolve failures before claiming readiness.
- Types and lint: run configured checkers and report unresolved errors.
- Tests: run affected unit, integration, and critical-flow tests; check the project's coverage threshold (80% where required). For fixes, record the regression failing before the fix and passing after it.
- Behavioral properties: run adopted property-based, conformance, model, or proof checks affected by the change. Follow the formal-methods evidence rules for bounds, reachability, axioms, and implementation correspondence. Replay relevant counterexamples against real code.
- Security: run configured scanners and review affected security boundaries. Report secret locations with values redacted; do not print matching credential lines. Keyword searches alone do not establish security.
- Diff: inspect the whole task diff, including staged and new files, against the appropriate base. Check for unintended behavior, missing error paths, and model/test drift. Do not substitute the previous commit's diff for the current task.
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.
- 16d ago Changed · -83 lines · +21 tokens per session e7f754eddbd4
- 1mo ago First seen · 127 lines · 12 tokens per session scan A 01a9ae310ad4
verification-loop is a skill published in the GitHub repository sjarmak/coding-agent-workflows (6 stars, last pushed 17d ago), licensed MIT. It adds 33 tokens to every session and 828 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 91% identical to verification-loop, differing in 131 lines, and is treated as a copy.
Other skills, from other repositories
blinded-eval
Blinded evaluation of a Skill, rule, or prompt change. The parent designs the experiment, isolates candidates in throwaway directories, runs the same organic user prompt, and scores artifacts against a held-back rubric. Apply when the user invokes /blinded-eval, asks to eval or A/B a skill change, or authoring Phase 4…
tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
migrate-to-shoehorn
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
secops-detection-engineering
Author, validate, test, and deploy YARA-L 2.0 detection rules and evaluate end-to-end detection coverage gaps in Google SecOps. Use when writing new detection rules, tuning existing rules, validating syntax, testing logic against historical telemetry, or evaluating detection coverage against threat intelligence blogs…
rtvi-vlm-perf-testing
Plan, run, and diagnose reproducible RT-VLM GPU performance canaries and benchmarks. Use this skill when running fresh-container stream-capacity, semantic-isolation, latency, throughput, or regression experiments against an RTVI microservices checkout.
story-origin-check
Recover the first public timestamp and canonical major coverage for a newsjacking signal, then decide whether newer coverage is the same story, a different story, or a materially new development.