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 ayberkcansever/ai-skills --skill thermo-nuclear-code-quality-reviewgit clone --depth 1 https://github.com/ayberkcansever/ai-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/ayberkcansever/ai-skills/thermo-nuclear-code-quality-review)<a href="https://agentmods.dev/skills/ayberkcansever/ai-skills/thermo-nuclear-code-quality-review"><img src="https://agentmods.dev/badge/skills/ayberkcansever/ai-skills/thermo-nuclear-code-quality-review/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/ayberkcansever/ai-skills/thermo-nuclear-code-quality-review"><img src="https://agentmods.dev/badge/skills/ayberkcansever/ai-skills/thermo-nuclear-code-quality-review.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.00066 | $0.03062 |
| Opus 5 | $0.00033 | $0.01531 |
| Sonnet 5 | $0.00013 | $0.00612 |
| Haiku 4.5 | $0.00007 | $0.00306 |
Grade A, and why
thermo-nuclear-code-quality-review 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 12d 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 — 226 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Thermo-Nuclear Code Quality Review
Review current branch changes through five lenses, in order (the checkout you were launched in — execute-plan launches the reviewer in the ticket worktree). Phases 0–3 are review-first: report findings, change code only if the user says "fix". Phase 4 (docs) is always applied where a feature-docs flow exists.
Maker/checker is unconditional for agent-authored diffs: if any part of
the diff was written by an agent in any session (execute-plan or otherwise —
resumed agent-authored branches included), run the review as a read-only
subagent — the reviewer must not
share the implementer's context or be able to edit. Manual invocation on a
human-authored diff may run inline. Number every finding
N | file:line | severity | problem | fix so accepted findings can be appended
to the plan file as structured remediation tasks (see the review loop below).
Pinned review model: the reviewer subagent is launched with a pinned review model — record your chosen slug here (pick the strongest reasoning/thinking model available in your tool) — never inherit the implementer session's model (auto included). If the slug is unavailable, stop and ask the user; never silently substitute. This section is the single source of truth for the slug — write-plan and execute-plan reference it instead of hardcoding it; when the model changes, update it here only.
Persist the verdict: when a plan file exists for the branch, the
invoking session (orchestrator) appends the 3-line rollup, the model used,
the full-suite command + result, reviewed @ <HEAD SHA> and base @ <base SHA> (both captured in Step 0), and the reviewer subagent link to the plan
under a ## Review section (one entry per cycle) — the reviewer subagent is
read-only and cannot write the plan; on standalone inline runs the session
itself appends. A review that leaves no ## Review entry did not happen —
execute-plan's resume check depends on it.
A ship verdict is valid only for its recorded HEAD and base SHAs — any
later commit invalidates it and requires a new cycle, except commits touching
only docs/ paths that leave spec decisions unchanged (doc sync, plan/spec
promotion, ## Review entries). A docs commit that edits decisions in
spec.md / design.md un-reviews the code; if the base branch moved,
re-review before merge.
Step 0 — preconditions, then the diff.
- Re-run guard: if the plan's last
## Reviewentry recordsVerdict: shipat the current HEAD (or differing from it only by docs-only commits that leave spec decisions unchanged), report "already reviewed at this commit" and stop — re-review only if the user explicitly forces it. - Clean tree required:
git status --porcelainmust be empty. Staged, unstaged, and untracked changes are invisible togit diff <base>...HEADand would silently escape review. Dirty tree → stop and report; have the work committed first. - Quirks doc: read the project quirks doc when one exists (e.g.
docs/quirks.md— hard-learned domain gotchas) — its entries feed Phase 0's semantic-drift sweep and Phase 3. - Base & anchor: resolve the base (
git symbolic-ref refs/remotes/origin/HEADormain/master), then capturegit rev-parse HEADandgit rev-parse <base>— both go into the## Reviewentry. - Review
git diff <base>...HEAD. Lenses below reconcile cleanly: Phase 0 checks the diff does what was decided; Phase 1 removes what should not exist; Phase 2 restructures what remains.
Start the report with a 3-line rollup:
Verdict: ship | fix-first | block
Top issue: <one line, or "none">
Net: -N lines possible | Lean already
Verdict rules (deterministic):
block— any Phase 3 CRITICAL RISK, or a spec decisionmissing/ unapproveddriftin Phase 0.fix-first— no blockers, but accepted findings remain open (Phase 0 semantic nits, Phase 1 cuts, Phase 2 structure). Also the cap when a ticket branch has no findable spec/plan (see Phase 0).ship— no open accepted findings AND the full test suite is green at the reviewed SHA, evidenced by the suite command + result recorded in the## Reviewentry (the orchestrator re-runs it after the last fix; a targeted gate command alone does not qualify). No recorded evidence → cap atfix-first.
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.
- 12d ago First seen · 226 lines · 66 tokens per session scan A 9c762f074fec
thermo-nuclear-code-quality-review is a skill published in the GitHub repository ayberkcansever/ai-skills (2 stars, last pushed 8d ago), licensed MIT. It adds 66 tokens to every session and 3,062 once invoked, about $0.0003 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-31.
Other skills, from other repositories
pr-review
Use when opening, reviewing, or merging a pull request. Covers pre-PR checks (linting, tests, branch naming), PR description requirements, and post-merge cleanup. Not for code review commentary or architecture decisions — use the relevant role guidelines for those.
code-review
Review a GitHub Pull Request for bugs, security, performance, and code quality. Use when user asks to review a PR or wants pull request feedback. Don't use for reviewing local uncommitted changes, creating new PRs, or merging branches.
issue-creation
Trigger: issue creation, bug reports, feature requests, or issue approval. Create and triage GitHub issues from repository evidence.
sdd-tasks
Break an SDD change into implementation tasks. Trigger: orchestrator launches task planning for a change.
work-unit-commits
Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code.
systemic-issue-triage
Trigger: new issue, bug report, triage, backlog, issue flood, community report, root cause, dead-end, blocked user. Attack issues by root class, never one-by-one; fixes must shrink the system, not grow it.