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 Rohit-ATS/Airlock --skill code-review-loopgit clone --depth 1 https://github.com/Rohit-ATS/AirlockWrote 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/rohit-ats/airlock/code-review-loop)<a href="https://agentmods.dev/skills/rohit-ats/airlock/code-review-loop"><img src="https://agentmods.dev/badge/skills/rohit-ats/airlock/code-review-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/rohit-ats/airlock/code-review-loop"><img src="https://agentmods.dev/badge/skills/rohit-ats/airlock/code-review-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.00047 | $0.01228 |
| Opus 5.5 | $0.00019 | $0.00491 |
| Sonnet 5.5 | $0.00009 | $0.00246 |
| Haiku 4.5 | $0.00005 | $0.00123 |
Grade A, and why
code-review-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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
The code review loop
A schema migration is half a change.
Dropping users.plan_name is not finished when the column is gone. It is finished when the
fourteen places that read it no longer do. AIRLOCK already computed those fourteen places —
that is what the blast radius is — so leaving them as a to-do list for a human afterwards is
leaving the job half done and calling it proven.
So: write the code, open a pull request, get it reviewed by something that is not you, fix what it finds, and only then ask for approval.
Why the review is somebody else's job
You are the worst available reviewer of your own diff, for the same reason the requester is the worst available approver of their own change. Not because you are careless — because you already believe the thing is right, and a reviewer's entire value is not sharing that belief.
A second prompt to the same model is not an independent reviewer. It is you, warmed up.
The reviewer's findings on your code are treated the same way AIRLOCK treats every other claim: a positive finding is believed on sight, and a claim that it went away is recomputed. A finding counts as addressed only when a commit landed after it was raised.
The loop
1. Read the blast radius
airlock_get_change gives you blast_radius — repository, file, line, enclosing symbol, for
every reference the scout found. That is your work list. If it is empty there is nothing to
do here and the gate does not ask for a review.
2. Write the changes, expand/contract shaped
Load the expand-contract skill. The application changes follow the same three phases as the
migration, and the important property is the same: every intermediate state is deployable.
The code must be correct against the database before the migration and after it, because there is a window — possibly a long one — where both are true somewhere. Code that only works after the column is gone is code that breaks the moment you deploy it and the migration has not run yet.
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 · 126 lines · 47 tokens per session scan A 75a07112bf79
code-review-loop is a skill published in the GitHub repository Rohit-ATS/Airlock (1 stars, last pushed today), licensed MIT. It adds 47 tokens to every session and 1,228 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-08-31.
Other skills, from other repositories
reweave-operator
Operate a Reweave self-healing web-data fleet — run pipelines, triage structural-drift incidents, review repair proposals, and manage the human approval workflow. Use whenever a monitored source is broken, a heal is pending, or the operator asks about pipeline health or impact.
oma-refactor
Restructure existing code while preserving observable behavior. Use for targeted technical debt or hotspot work with characterization tests.
address-pr-comments
Work through the review comments on a pull request: check each point against the code, make the changes that are right, answer the ones that are not, and hold every reply for approval before it is posted.
code-review
A code-review procedure for examining supplied code or a change diff for evidence-based bugs, compatibility problems, and data risks.
gentle-ai-judgment-day
Trigger: judgment day, judgement day, dual review, adversarial review, juzgar. Run explicit blind dual review with at most two scoped fix/re-judgment rounds.
gentle-ai-work-unit-commits
Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code.