ng-code-review

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-artifacts instead.
• 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.