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 agentmods add commands/flyfission/nuclear-grade-context-engineering/ng-code-reviewgit clone --depth 1 https://github.com/FlyFission/nuclear-grade-context-engineeringWhat 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 | $0.00000 | $0.00794 |
| Opus 5 | $0.00000 | $0.00397 |
| Sonnet 5 | $0.00000 | $0.00159 |
| Haiku 4.5 | $0.00000 | $0.00079 |
Grade A, and why
ng-code-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 2d 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ng-code-review
Portable command prompt generated from skills/reviewing-code-quality/SKILL.md. Edit the skill, then run python tools/ng.py gen-commands; do not edit this file by hand.
Reviews a diff or module for slipping standards, favoring deletion over rearranging, and ends in one honest verdict. Use when a change risks oversized files, needless layers, feature logic leaking into shared code, or clever indirection. Do not use for a trivial obvious edit, or for a check that is only about whether the code works.
Use when
- A diff or module is up for review and you want a standards check, not just a "does it work" check.
- A file or function has grown large, or a new layer is being added.
- Logic for one feature may be leaking into shared, core, or framework code.
- A rewrite is proposed and you need to judge whether it removes complexity or just moves it.
- An agent wrote code fast and the question is whether anyone can maintain it.
- The work is in Sweeper posture -- simplification, unshipping, or performance work -- where deletion can outrun the baseline (see
docs/02-operating-system/archetype-lens.md).
Do not use when
- The change is a trivial, obvious edit with no effect on structure.
- The task is only about whether the code works (use proving-claims and verification instead).
- The deliverable is a produced artifact whose correctness lives in the rendered output — a figure, PDF, SVG, screenshot, build, or deployed response — rather than the source structure; use
verifying-final-artifactsinstead. - A quick fix has to ship to contain a live incident before a quality pass makes sense.
Inputs
- The diff or module under review and the files around it.
- The change's mission anchor or goal, so you can judge scope.
- Project conventions and any countable limits the team agreed on.
- The map of dependencies and layers: what is shared or core versus tied to one feature.
Prompt text
Run a Nuclear-grade code-quality review on this change.
Inputs:
- diff or module:
- objective / mission anchor:
- agreed limits or conventions:
- shared vs feature-specific layers:
Do this:
- Read the change against its goal; flag scope drift first.
- Look to delete before you rearrange; ask what can be removed entirely.
- Use the countable tripwires as prompts, not laws (file around 1000 lines, function around 50 lines, deep nesting, duplicated branches).
- Test each abstraction: it must remove more complexity than it adds; flag thin pass-throughs.
- Check the layering: flag feature logic leaking into shared, canonical, or framework code.
- Prefer plain, direct code over clever indirection.
Return:
- a ranked list of findings (location, the standard at risk, a concrete fix, often a deletion)
- one verdict: VERIFIED, NOT VERIFIED, or INCONCLUSIVE
- a short reason tying the verdict to the findings
Do not soften every finding into "looks good." Do not imply formal assurance, compliance, certification, safety, security, or regulatory adequacy.
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.
- 2d ago First seen · 66 lines · 0 tokens per session scan A f1d3567216c4
ng-code-review is a command published in the GitHub repository FlyFission/nuclear-grade-context-engineering (33 stars, last pushed 23d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 794 tokens. 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 commands, from other repositories
coder-eval-implement-plan
Implement an approved codereval plan phase by phase with risk-scaled per-phase review, then a final code review.
capture-feedback
Quick feedback capture with structured signals.
auto-run
PitWay: Manage auto-run authorization for automatic task continuation.
task-integrate
PitWay: Apply a dispatched task's worktree commit to the main tree.
milestone-list
PitWay: List every milestone with a concise one-line status.
fix
Universal debugging and fix application with semantic code analysis.