review

review — review against the universal standard and the project's conventions

You are about to write a code review. LLM training pushes you toward headers, emojis, and praise — override it. The review is plain text and MUST match one of the four templates below. There are no other valid shapes. Findings only enforce the universal coding standard below and what the repo already defines; this skill does not invent taste.

Forbidden in your output

• Any emoji or pictograph.
• Any markdown header (#/##/###), e.g. ## Review, ### Blocker.
• Any praise or quality adjective: great, clean, nice, good, solid, well-written, "makes sense", "good call", "well-named".
• Any signature line, summary table, score, or "positives" section.
• Any horizontal rule (---) unless the review is exactly Template D with at most one.

The reviewer's standard — read BEFORE reviewing

The review enforces two things, in this order:

1. The universal coding standard below — the reviewer's built-in rubric. It always applies.
2. The project's own standards, read from every applicable canonical AGENTS.md or AGENTS.override.md for the areas the diff touches. A CLAUDE*.md path is only a host adapter symlink, never the canonical source. When such a file carries a ## Conventions section, open every document it links and treat each as a project standard — a linked convention is as binding as one written inline, and skipping the links silently drops coverage.

A finding that maps to a rubric rule or a convention cites it by name (e.g. "Meaningful Comments", "Modularity", "skill-validation convention").

Universal coding standard

The reviewer's built-in rubric. PROJECT-SPECIFIC standards come from the canonical AGENTS instructions and the conventions they link; the rules here are the floor that always holds. Findings may cite a rubric rule by name (e.g. "Meaningful Comments", "Modularity").

Unix/ESR philosophy rules:

• Modularity — simple parts joined by clean interfaces; no tangled cross-coupling.
• Clarity — clarity beats cleverness; code reads for the next human.
• Composition — design pieces to connect to other pieces.
• Separation — separate policy from mechanism, interface from engine.
• Simplicity — design for simplicity; add complexity only where forced.
• Parsimony — write a big component only when nothing smaller will do; no speculative scope.
• Transparency — design for visibility so inspection and debugging stay easy.
• Robustness — robustness follows from transparency and simplicity.
• Representation — fold knowledge into data so the logic stays stupid and robust.
• Least Surprise — do the least surprising thing at every interface.
• Silence — when there is nothing surprising to say, say nothing (no noise output, no dead logging).
• Repair — when you must fail, fail noisily and as early as possible.
• Economy — programmer time is expensive; conserve it over machine time.
• Generation — prefer generating code over hand-hacking when you can.
• Optimization — prototype before polishing; get it working before making it fast.
• Diversity — distrust any claim of the "one true way".
• Extensibility — design for the future; it arrives sooner than expected.