Menu
Review code for quality, simplicity, and common mistakes before declaring work complete.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/srid/haskell-flake --skill code-policeThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Based on SOC occupation classification
Showing SKILL.md
| name | code-police |
| description | Review code for quality, simplicity, and common mistakes before declaring work complete. |
Review the current changes (scoped to the current branch/PR) against the rules below and any additional code-police rules from project instructions, then run three passes in order.
Two similar instances are fine — don't abstract prematurely. Three is the threshold for extraction. But identical content that must stay in sync (same HTML, same version string) should be deduplicated immediately regardless of count. Versions, ports, paths — define once, reference everywhere.
Before hand-rolling a utility (string tokenizer, quoted-string parser, date helper, semver comparator, URL builder, CLI arg parser, tree walker, regex-based matcher, path normalizer, etc.), check whether a focused library solves the same problem. If one exists with a matching scope and a reasonable bundle cost, prefer it — even if it's a new dependency. Hand-rolling is only justified when the library would add capabilities you actively don't want (tagging, env expansion, i18n layers, etc. you'd have to ignore), or when the hand-roll is genuinely a handful of lines with no branching.
Rationale: "Zero deps" is an easiness judgment dressed as a simplicity judgment. Code you don't own is genuinely simpler than code you do own — it doesn't accumulate private test fixtures, it doesn't bitrot when requirements shift, and its edge cases are someone else's problem to fix. Hand-rolled utilities routinely grow past the library they displaced as new edge cases surface. A small focused library with a single exported function is the same complexity to your reader as a one-line utility import, and less complexity than a 40-line loop with state variables.
How to apply: When you're about to write a loop with nested state-machine variables, a tokenizer, a parser, a semver comparator, a date math helper, a quoted-string handler, or a path normalizer — stop and search for the focused library first. Only fall back to hand-roll after seeing a concrete library and judging that its scope genuinely exceeds what you need.
Anti-patterns in this rule's application:
Use discriminated unions, not booleans or stringly-typed fields. If two fields can't both be undefined at the same time, model that in the type.
Aggressively remove unused code. No commented-out blocks, no "just in case" leftovers.
Never silently swallow errors. Empty catch {} blocks, bare catch: pass, and || true hide failures. At minimum, log the error. If the catch is intentional (best-effort operation), add a comment explaining why the error is safe to ignore.
Rationale: Silent swallowing masks bugs — failures disappear without a trace, making debugging impossible.
Collections, buffers, and listeners that grow with usage must have a bound or a cleanup path. Common violations:
fs.watch, resize, scroll, mousemove, WebSocket onmessage, or any event that can fire many times per second. Each invocation that does non-trivial work (I/O, parsing, DOM mutation, allocation) needs a debounce or throttle. A bare handler is only acceptable if the work is O(1) and allocation-free.Rationale: LLM-generated code defaults to the simplest correct implementation, which is often O(n) in session lifetime. These patterns silently degrade performance over hours/days and surface as "the app got slow" with no obvious cause. The fix is almost always straightforward (cap, debounce, stream, share) but must be applied at write time — it's rarely caught in review because the code is functionally correct.
Add comments where the why isn't obvious from the code. Don't comment the what. Also comment where the what isn't obvious — non-obvious guards, CSS workarounds, platform-specific behavior. Non-obvious workarounds (temp files, wrapper scripts, env var shims) must have a comment explaining why they exist.
Present a table with every rule above:
| Rule ID | Violation found? | What was identified | Action taken |
|---|
If no violation was found for a rule, mark it as "No" with a brief note on what was checked. Every rule must appear in the table — no skipping.
Audit the changes for correctness and rigor. This is not a style review — it's a logic review. Find places where the code lies to itself.
Flag:
try/catch: pass, empty catch {}, || true, errors caught but not propagated, Result/Option silently defaulted.For each finding: file, line, one-line risk, concrete fix. If no issues, say so — don't invent problems.
Principles:
Anti-patterns in YOUR review (strictly banned):
Review the changes for elegance and simplicity. For each iteration (run 3 iterations):
Principles:
After all three passes, present a combined summary:
| Pass | Issues found | Details |
|---|---|---|
| Rules | N | Brief summary or "Clean" |
| Fact-check | N | Brief summary or "Clean" |
| Elegance | N | Brief summary or "Clean" |
If ANY pass found issues, clearly state: "Violations or issues found" so the workflow can route to a fix step.
If all passes are clean, state: "All clear".
Simple means not interleaved. Each module does one thing. Data flows through arguments and return values, not shared mutable state or indirection.
# above the recipe name).Group code by rate of change, not by technical layer. Things that change together live together; things that change independently get separate modules.