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 haidrrrry/loop-engineering-skills --skill loop-verifiergit clone --depth 1 https://github.com/haidrrrry/loop-engineering-skillsWrote 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/haidrrrry/loop-engineering-skills/loop-verifier)<a href="https://agentmods.dev/skills/haidrrrry/loop-engineering-skills/loop-verifier"><img src="https://agentmods.dev/badge/skills/haidrrrry/loop-engineering-skills/loop-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/skills/haidrrrry/loop-engineering-skills/loop-verifier"><img src="https://agentmods.dev/badge/skills/haidrrrry/loop-engineering-skills/loop-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.00121 | $0.01122 |
| Opus 5.5 | $0.00048 | $0.00449 |
| Sonnet 5.5 | $0.00024 | $0.00224 |
| Haiku 4.5 | $0.00012 | $0.00112 |
Grade A, and why
loop-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 1mo 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 — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Loop Verifier
The checker half of the maker/checker split. Turns "the agent says it's done" into "the gates say it's done." Built on one anti-cheating rule from the research: checks must be derived from the TASK, before or independently of the implementation — an agent that writes its checks after coding tends to write checks that mirror its own mistakes.
The protocol
1. Before implementing: write the checks
From the task description and .loop/GATES.md, produce the concrete check
list for this task:
- Which universal gates apply (they all do) and what they mean here
- Which task-type gates apply (code / bug fix / refactor / docs / dependency)
- The project-specific commands (build, test, lint) that must exit clean
- 3–5 task-specific checks: edge cases, invariants, a worked example with a known expected result
Write this list down BEFORE writing any implementation. This ordering is the whole defense against self-confirming verification.
2. After implementing: run the gates
- Execute every runnable check for real (tests, build, lint). Paste actual output, not a summary of expected output.
- For non-runnable checks, walk each one explicitly: state the check, quote the evidence from the work, mark pass/fail.
- The Decompose audit is always included: every requirement in the task gets a quote from the output that satisfies it. No quote = gap = fail.
3. Verdict rules
- PASS requires: all applicable gates green, all checks walked, no check skipped silently.
- FAIL must name which gate failed and why — that line feeds the retry.
- A check you couldn't run (missing env, no test framework) is reported as UNRUN, and UNRUN on a required gate means the verdict is FAIL, not PASS. Unverifiable is not verified.
- Never soften a verdict because effort was high. The verdict describes the work, not the attempt.
4. Escalation triggers (hand to the human immediately)
- Any action on the GATES.md "Never" list would be required to proceed
- The same gate has failed 3 times for the same root cause
- The task requires changing the gates themselves
- Trust level is L1 and the fix requires applying changes
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.
- 1mo ago First seen · 104 lines · 121 tokens per session scan A 67c58b57eeb5
loop-verifier is a skill published in the GitHub repository haidrrrry/loop-engineering-skills (4 stars, last pushed 3mo ago), licensed MIT. It adds 121 tokens to every session and 1,122 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-31.
Other skills, from other repositories
istio-traffic-management
Configure Istio traffic management including routing, load balancing, circuit breakers, and canary deployments. Use when implementing service mesh traffic policies, progressive delivery, or resilience patterns.
postgresql-table-design
Use this skill when designing or reviewing a PostgreSQL-specific schema. Covers best-practices, data types, indexing, constraints, performance patterns, and advanced features.
event-store-design
Design and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
workflow-orchestration-patterns
Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.
make-pr-easy-to-review
Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for "make this easy to review", "tidy this PR", "clean up commits", or "annotate the diff".
poteto-mode
Bundled skills live at ../ /SKILL.md from this file, so put this file's absolute path in every poteto-agent prompt.