Code review

Skill MarieLynneBlock/arcanum-artifex/skills/development/code-review

Prompts, skills, and agents that survive contact with real workflows. No vendor loyalty. Occasionally heretical. 🧙🏻‍♀️

Install

npx -y skills add MarieLynneBlock/arcanum-artifex --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Applies a consistent, language-agnostic review framework to any code change. It evaluates code across five dimensions, produces prioritised findings with inline suggestions, and distinguishes blockers (must fix before merge) from improvements (worth addressing but not blocking).

SKILL.md

4.8 KB, as published. Nobody here has run it

What this skill does

When to use it

User asks to "review this code", "review this PR", or "give feedback on this diff".
User pastes a code snippet and wants quality feedback.
User wants a second opinion before raising a PR.
User needs a review checklist for a team standard.

Review dimensions

Dimension	What to check
Correctness	Logic errors, off-by-one, null/undefined handling, edge cases not covered
Security	Input validation, injection risks, secrets in code, insecure defaults, least-privilege violations
Maintainability	Naming clarity, function/class size, duplication, coupling, missing or misleading comments
Performance	N+1 queries, unnecessary allocations, blocking calls, inefficient algorithms for the scale
Test coverage	Happy path covered, edge cases tested, negative scenarios present, test quality (not just count)

Finding severity

Severity	Meaning	Merge gate?
Blocker	Must fix — correctness bug, security vulnerability, or missing critical test	Yes
Major	Should fix this PR — significant maintainability or performance issue	Recommended
Minor	Fix soon — small improvement, naming, formatting	No
Nit	Optional — style preference or very low impact	No

Instructions

Understand the context. What does this code do? What is the change trying to achieve? If not clear, state the assumption.
Review each dimension. Work through correctness → security → maintainability → performance → test coverage. Only flag genuine issues — do not manufacture findings.
Write inline suggestions. For each finding, reference the specific line or block and provide a concrete fix or alternative, not just a description of the problem.
Classify severity. Assign Blocker / Major / Minor / Nit to each finding.
Write an overall summary. Is this ready to merge? What is the dominant concern if any?
Produce the report using the output format below.

Output format

## Code review: [file name or PR title]

**Overall verdict:** Ready to merge / Merge after addressing blockers / Needs significant rework

**Summary:** [2–3 sentences: what the code does, overall quality impression, dominant concern.]

---

### Findings

#### [BLOCKER/MAJOR/MINOR/NIT] — [Short title]

**Location:** `file.ext:line` or `function name`

**Issue:** [What is wrong and why it matters.]

**Suggestion:**
\```language
// suggested fix or alternative
\```

---

### What works well

- [Specific thing done well — always include at least one]
- [Specific thing done well]

---

### Checklist

| Dimension | Status | Notes |
| --- | --- | --- |
| Correctness | Pass / Fail / Partial | |
| Security | Pass / Fail / Partial | |
| Maintainability | Pass / Fail / Partial | |
| Performance | Pass / Fail / Partial | |
| Test coverage | Pass / Fail / Partial | |

Examples

Example 1 — Security blocker in a web handler

Input: Python Flask route that concatenates user input into a SQL query string.

Expected output: Blocker finding for SQL injection with a parameterised query fix. Minor finding for missing input length validation. Checklist: Security Fail, Correctness Partial.

Example 2 — Clean PR with minor nits

Input: Well-structured TypeScript utility function with tests.

Expected output: No blockers or majors. Two Nit findings (variable naming, unused import). "What works well" section highlighting test coverage and clear function boundaries. Verdict: Ready to merge.

Notes

Lead with blockers — a long list of nits before a blocker buries the most important information.
Always include at least one "what works well" item. Reviews that only criticise reduce trust and miss knowledge-sharing opportunities.
Do not flag style or formatting issues that a linter/formatter should enforce — note them once as "configure a linter" if they are pervasive.
If the diff is too large to review in full, say so and ask the user to scope it (by file, by concern, or by risk area).

Gives 0 of the 12 instructions most code review skills give

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

push back with technical reasoning if wrongin 60 of 610, across 24 files
ask for clarification on unclear itemsin 51 of 610, across 16 files
fix critical issues immediatelyin 45 of 610, across 29 files
implement one item at a timein 45 of 610, across 11 files
group findings by severityin 44 of 610, across 43 files
verify feedback against the codebasein 42 of 610, across 8 files
dispatch a code reviewer subagentin 39 of 610, across 23 files
fix important issues before proceedingin 37 of 610, across 22 files
test each fix individuallyin 35 of 610, across 7 files
reply in github comment threadsin 33 of 610, across 5 files
check for security vulnerabilitiesin 31 of 610, across 27 files
factualize corrections without over-explainingin 30 of 610, across 2 files

Said here and by no other author read

State the assumed context if unclear
Flag only genuine issues

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.