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 rainmanjam/poka-yoke --skill retrogit clone --depth 1 https://github.com/rainmanjam/poka-yokeWrote 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/rainmanjam/poka-yoke/retro)<a href="https://agentmods.dev/skills/rainmanjam/poka-yoke/retro"><img src="https://agentmods.dev/badge/skills/rainmanjam/poka-yoke/retro/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/rainmanjam/poka-yoke/retro"><img src="https://agentmods.dev/badge/skills/rainmanjam/poka-yoke/retro.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00039 | $0.00952 |
| Opus 5 | $0.00019 | $0.00476 |
| Sonnet 5 | $0.00008 | $0.00190 |
| Haiku 4.5 | $0.00004 | $0.00095 |
Grade A, and why
retro 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 9d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Retro: Structural Lessons From an Incident
An incident is expensive information. Most of the value is lost because the write-up records what happened and the fix records what changed, and neither records why the code allowed it.
The structural question is not "what went wrong" but "what about the shape of this code made that failure available, and is that shape used elsewhere".
Separate the timeline from the analysis
The timeline is what happened, in order, with times. It is a record, and it should be boring: who noticed, when, what they did, what the system did back. Write it first and do not interpret it while writing it.
The analysis is what you concluded. Keep it separate, because a timeline with interpretation woven through it cannot be re-read later by someone who disagrees with the interpretation.
Find the structural cause, not the last change
The last change before the incident is rarely the interesting one. Ask instead:
What made this failure expressible? A function that accepted an argument it could not validate, a module that could observe state it had no business observing, a default that silently applied.
Why did the code look correct? If the failing code passed review, understand what it looked like to the reviewer. That perception is the thing to change, and it is usually a naming or a structure problem rather than a knowledge problem.
How far can this shape travel? The same shape almost certainly exists elsewhere. Finding the second and third instance is the difference between a fix and a lesson.
The write-up
Aim it at someone six months from now who was not there.
- Lead with the structural finding, not the chronology. "A helper returned
Nonefor both 'absent' and 'failed', and three callers could not distinguish them" is the sentence worth remembering. - Say what was ruled out, and why. A retro that lists only the cause reads as though it was obvious, which teaches the reader nothing about how to look.
- Name the changes and their limits. A fix that closes one path should say which paths it does not close.
- Record disagreements. If two people read the cause differently and one view won, the other view is evidence about how the code reads.
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.
- 9d ago First seen · 88 lines · 39 tokens per session scan A 59cb0547c869
retro is a skill published in the GitHub repository rainmanjam/poka-yoke (22 stars, last pushed 7d ago), licensed MIT. It adds 39 tokens to every session and 952 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-30.
Other skills, from other repositories
Nullability Contract Review
Detect null/undefined/empty handling gaps where callers or consumers may receive unexpected nullish values.
skill-audit
Audit codebases for quality, consistency, and broken patterns — use for pre-release or tech debt review.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
critical-code-reviewer
Rigorously review code or pull requests for correctness, security, accessibility, maintainability, tests, and edge cases. Use when users request a critical code review, want a guided walkthrough of findings, need implementer-facing feedback, or want to prepare, create, or submit a GitHub pull request review.
second-pass-review
Independent audit of sanitized specs in workspace/output/. Three parallel LLM-based reviewer roles check structural leakage, content contamination, and behavioral completeness. Run AFTER Layer 5 sanitization, BEFORE implementation handoff.
check-pr
Read-only inspection of a single GitHub PR lifecycle — checks CI, review threads, description sync, and mergeability, and returns PASS or FAIL with per-gate findings. Never invokes the merge button. Use when verifying a PR is ready to merge, polling lifecycle progress, checking mergeability, or babysitting a GitHub PR…