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 olddonkey/olddonkey-skills --skill implementation-loopgit clone --depth 1 https://github.com/olddonkey/olddonkey-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/olddonkey/olddonkey-skills/implementation-loop)<a href="https://agentmods.dev/skills/olddonkey/olddonkey-skills/implementation-loop"><img src="https://agentmods.dev/badge/skills/olddonkey/olddonkey-skills/implementation-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/olddonkey/olddonkey-skills/implementation-loop"><img src="https://agentmods.dev/badge/skills/olddonkey/olddonkey-skills/implementation-loop.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Rogue Agent · line 53 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Excessive Agency · line 111 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00233 | $0.06680 |
| Opus 5.5 | $0.00093 | $0.02672 |
| Sonnet 5.5 | $0.00047 | $0.01336 |
| Haiku 4.5 | $0.00023 | $0.00668 |
Grade A, and why
implementation-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 13d 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 — 231 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementation loop
One model writes the code, a model from another vendor reviews it, and you own the judgment. The implementer (Codex, or Claude Code in a sandboxed copy) is fast at implementation but it self-reports success, cannot commit, and will hang a machine if pointed at a long test suite. You give it a precise spec, make sure the review comes from a different vendor than the code, then be the thing that actually verifies and ships: you read the diff, run the gate, and publish. Both directions work: Codex implements and you review, or the claude backend implements and Codex cross-reviews. What matters is that the writer and the reviewer are different models. This includes bug fixes: a bug found at review, at the gate, or later is a unit like any other — you diagnose and spec, the implementer implements. Editing code directly "because it's faster" silently inverts the division of labor and costs review its independence.
The loop: decompose → dispatch → review (yours, plus a cross-review when the writer is your own vendor) → iterate → gate → publish → next.
Non-negotiables
- Review is mandatory and independent. The implementer's summary is a claim; the diff is the evidence. Never skip review because it says it's done. The writer's own model never gives the only review: when the implementer comes from your own vendor (the claude backend under a Claude session), every round also gets a read-only cross-review from the other backend (§3).
- An assumed default never leaves the machine. With no explicit user choice, stop at the working tree — even a local commit can fire hooks/signing. Commit, push, PR, and merge each need the user to have said yes once for this repo, asked at kickoff, not discovered at publish time. Once is once: that authorization is per-repo, persists across sessions until revoked or the work changes character — never re-ask per unit.
- Never push straight to the default branch.
- The full-suite gate is yours, run by you, with the real exit code. A fix means the code satisfies the test — a weakened assertion, deleted case, or widened tolerance to turn red green is a stop, not a pass.
- Don't let the implementer run the full test suite by default — focused subsets only, unless calibration showed the suite is small and fast.
What ships with it
24 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- backends/backends.tsv 199 B
- backends/claude/dispatch.sh 27 KB runs code
- backends/claude/fixture-driver.sh 4.2 KB runs code
- backends/claude/runtime.md 5.9 KB
- backends/claude/selftest.sh 34 KB runs code
- backends/codex/dispatch.sh 50 KB runs code
- backends/codex/fixture-driver.sh 3.8 KB runs code
- backends/codex/runtime.md 17 KB
- backends/codex/selftest.sh 63 KB runs code
- references/dials.md 8.2 KB
- references/dispatch-contract.md 3.6 KB
- references/dispatch-prompt.md 1.0 KB
- references/gate.md 5.0 KB
- references/review-checklist.md 1.7 KB
- references/running-anywhere.md 1.2 KB
- scripts/codex-dispatch.sh 267 B runs code
- scripts/run-gate.sh 22 KB runs code
- scripts/selftest.sh 353 B runs code
- tests/codex-cases.tsv 2.7 KB
- tests/contract-core.sh 17 KB runs code
- tests/contract-negative.sh 5.6 KB runs code
- tests/gate-selftest.sh 45 KB runs code
- tests/integration-test.sh 52 KB runs code
- tests/shim-selftest.sh 4.9 KB runs code
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.
- 13d ago Changed · -8 lines 3835d4fec391
- 14d ago Changed · +7 lines · +18 tokens per session d1fdce8a097c
- 24d ago Changed a514e68a35fe
- 28d ago Changed · +7 lines d86ce615f0e7
- 2mo ago First seen · 225 lines · 215 tokens per session scan A 10cbe125720b
implementation-loop is a skill published in the GitHub repository olddonkey/olddonkey-skills (17 stars, last pushed 14d ago), licensed MIT. It adds 233 tokens to every session and 6,680 once invoked, about $0.0009 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-30.
Other skills, from other repositories
forge-eng
A Chinese-language review workflow for analysing a completed coding session and saving lessons in project documents and a learning log. It uses a local web page where the user chooses the topics and depth before the review continues.
meta-review
Audits any SKILL.md against SKILL-SPEC.md, the repo's skill authoring standard, and returns a scored checklist with prioritized fixes. Trigger on: "review this skill", "audit this SKILL.md", "does this skill meet spec", "is this skill done", "quality check this skill", or any request to validate a skill file against…
meta-verify
Runs a second-pass quality check on a skill's output before it goes out, re-checking it against the originating skill's Quality Gate and Operating Rules and returning specific fixes, not just pass/fail. Trigger on: "verify this", "check this before I send it", "second-pass this brief", "did that pass quality gate", or…
forge-review
A pre-release review guide for comparing the current code branch with its base branch, meaning the branch the changes are intended to merge into. It looks for structural problems that tests may not catch and can fix findings directly.
kelly-pr-review
GitHub pull request review desk (Busabase App-in-Skill) using the gh CLI for real GitHub access, an AirApp review UI for human approval, and a trusted gh pr review execution step. Use when the user invokes /kelly-pr-review or $kelly-pr-review, asks to review GitHub PRs, generate a PR review batch…
pr-review
Review a PR, branch, commit, or uncommitted changes for correctness bugs, structural regressions, security and performance problems. Reports findings grouped by severity with file:line and a concrete fix. Use when asked to review a PR / branch / diff / "my changes" before merge.