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 perniemann/pnCore --skill pn-loopgit clone --depth 1 https://github.com/perniemann/pnCoreWrote 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/perniemann/pncore/pn-loop)<a href="https://agentmods.dev/skills/perniemann/pncore/pn-loop"><img src="https://agentmods.dev/badge/skills/perniemann/pncore/pn-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/perniemann/pncore/pn-loop"><img src="https://agentmods.dev/badge/skills/perniemann/pncore/pn-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.00046 | $0.00798 |
| Opus 5.5 | $0.00018 | $0.00319 |
| Sonnet 5.5 | $0.00009 | $0.00160 |
| Haiku 4.5 | $0.00005 | $0.00080 |
Grade A, and why
pn-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 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 — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Loop
Overview
pn-loop runs an autonomous fix-until-pass cycle: work on the task, run verification, if it fails then fix and repeat. Completion is determined by verification command output, not by self-declared phrases. This aligns with pn-verification-before-completion: evidence before claims.
Inspired by the Ralph Wiggum technique but uses pnCore's verification-first approach: the loop ends when the verification command succeeds, not when the agent says "done."
When to use
- Fix CI until green — Run CI/tests each turn; fix failures; repeat until pass.
- Get tests passing — Run test command; fix failures; repeat until 0 failures.
- Complete a migration — Run migration verification; fix issues; repeat until clean.
- Build until success — Run build; fix errors; repeat until exit 0.
- Any task with clear, runnable verification and a known success condition.
Not a good fit: Tasks needing human judgment, ambiguous goals, or no single verification command.
Workflow
-
Define verification — Identify the command that proves success (e.g.
npm test,npm run build,npx playwright test). State the expected output (e.g. "0 failures", "exit 0"). -
Work — Implement or fix the task using relevant skills (pn-ci-fix, pn-tdd, pn-systematic-debugging, etc.).
-
Verify — Run the verification command. Read full output and exit code.
-
Decide
- Pass: Verification output confirms success → task complete. Use pn-verification-before-completion: state the evidence, then claim done.
- Fail: Verification shows failures → fix the issues, then go to step 3. Do not claim done.
-
Safety limit — If a max iteration count is specified (e.g. 10), stop after that many verification attempts and report remaining issues. Do not loop indefinitely without a cap when the user expects one.
Key principles
- Verification is the gate — The loop ends when the verification command succeeds. No shortcuts.
- Re-run verification each turn — Fresh run, full output. No "should pass" or extrapolation.
- Fix, then verify again — After each fix, run the verification command again before claiming anything.
- Evidence before completion — Follow pn-verification-before-completion: run the command, read output, then state result.
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 · 68 lines · 46 tokens per session scan A 6cd288969c63
pn-loop is a skill published in the GitHub repository perniemann/pnCore (0 stars, last pushed 2d ago), licensed MIT. It adds 46 tokens to every session and 798 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-09-03.
Other skills, from other repositories
t-800-run-gates
A set of machine checks for deciding whether a T-800 run is ready to finish. It covers different run modes, such as creating, patching, looping, or auditing.
implement-universal
Harness-agnostic version of /implement. Drives a single workshop ticket through the SWE→Tester loop in ONE conversation, with the role prompts bundled as agents/software-engineer.md and agents/tester.md instead of being launched as subagents. Resolves the ticket from implementyourself/tasks/, creates an…
resolve-author-fix
Find the root cause, implement a focused fix, and prove behavior with targeted tests and recordings.
otto-impact-assessment
Check the final diff's consumers, focused tests, evidence, and gaps.
feature-implement
Implement the design with focused tests mapped to each covered CUJ.
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…