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 skills/nearform/lastlight/code-reviewnpx skills add nearform/lastlight --skill code-reviewgit clone --depth 1 https://github.com/nearform/lastlightWhat 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.00083 | $0.03340 |
| Opus 5 | $0.00042 | $0.01670 |
| Sonnet 5 | $0.00017 | $0.00668 |
| Haiku 4.5 | $0.00008 | $0.00334 |
Grade A, and why
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 — 234 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review
The shared rubric for assessing a code change. Used both by a PR review and by the build cycle's branch-diff reviewer — the procedure differs (where the diff comes from, how the verdict is recorded), but the rubric below is the same.
Review the change in full context — read each changed file, not just the hunk. For a large change (>300 lines or >5 files): trace data flow through modified functions, check callers of anything whose signature or behaviour changed for regression risk, and check that tests cover the actual risk areas, not just the happy path.
Precision first — post only what matters
A review is only useful if people trust it. A noisy reviewer gets muted; every low-value comment you post spends the credibility of the ones that matter. So the bar is high-signal only — on what you post. Read "Where the gate applies" below first: if your output is consumed by a later stage rather than by a human, none of the filtering in this section is yours to do.
- Post only Critical and Important findings. Suggestions and Nits (below) are not worth a formal review comment on their own — drop them, or fold at most one genuinely valuable line into the summary. When in doubt about a finding's tier, leave it out of the review.
- If you cannot name the concrete impact — what breaks, and for which input or
caller — do not post it. "This could be cleaner" is not a finding; "this
crashes when
itemsis empty because line 42 indexes[0]" is. - One defect per comment, and distinct claims stay distinct. Never fold a second, independent defect into an "Additionally, …" sentence of the first — two defects sharing a comment get read, answered and tracked as one, and one of them is lost. Two comments may share a line. Keep each claim's precision too: "out of date" is not "wrong", and collapsing distinct claims into the harsher one overstates the review's case.
- Confidence gate — refute, don't doubt, and only at the end. Before you finalise, re-read each finding against the actual code and try to refute your own claim. Dropping it requires naming the specific thing that makes it wrong: the guard you missed, the caller that already validates, the type that makes the case unreachable. Unease is not a refutation. "I'm not certain" is an instruction to go and read the other side of the contract, not to delete the finding.
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 · 234 lines · 83 tokens per session scan A 3f7a9436846f
code-review is a skill published in the GitHub repository nearform/lastlight (22 stars, last pushed 5d ago), licensed MIT. It adds 83 tokens to every session and 3,340 once invoked, about $0.0004 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-30.
Other skills, from other repositories
代码审查员
专业代码审查专家，提供建设性、可操作的反馈，聚焦正确性、可维护性、安全性和性能，而非代码风格偏好。.
Codex
Guides operator-owned delegation to Codex when the task fits a bounded coding lane, review pass, or worktree-isolated implementation track.
example-skill
Counts lines, words, and bytes in a text file using the bundled count.sh script. Use when asked to count/measure a file's size in these terms.
design-taste-frontend
Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
open-code-review
Performs AI-powered code review on Git changes using the ocr CLI from alibaba/open-code-review. Use when the user asks to review code, review a pull request, review staged/unstaged changes, review a commit, or compare branches for code quality issues. Produces line-level review comments and can automatically apply…
image-to-code
Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific images instead of tiny compressed boards…