Code review

Skill zacharygcook/agent-skills/skills/code-review

A curated collection of practical, evidence-backed skills for coding agents.

Install

npx -y skills add zacharygcook/agent-skills --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

26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
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

Perform an evidence-backed adversarial review of a diff, commit, branch, pull request, or named files. Use only when the user explicitly requests a fresh code review or findings on implementation quality; do not use merely to fix CI or act on existing review comments.

SKILL.md

3.0 KB, as published. Nobody here has run it

Code Review

Find real correctness, security, reliability, product, performance, and maintainability risks. Do not implement fixes unless the user also asks for them.

Review Posture

Assume bugs may exist, but prove claims from code, tests, docs, or deterministic output.
Review system outcomes and repository invariants, not syntax alone.
Separate definite findings from open questions and speculative risks.
Prefer one root-cause finding over several overlapping symptoms.
Do not pad the report when no issue exists.

Priorities

P0: catastrophic security, data loss, outage, or broken core workflow; must not ship.
P1: serious definite correctness, privacy, auth, reliability, migration, or integration bug.
P2: normal actionable bug, edge case, test gap, performance risk, API/data-model issue, or maintainability problem.
P3: low-risk inconsistency or polish worth addressing.

Use the lowest priority that honestly matches both impact and confidence.

Workflow

Read repository instructions and docs relevant to the changed domain.
Establish the exact target and intent from status, commits, PR text, issues, and tests.
Read changed files plus nearby code that owns contracts and invariants.
Run focused repository-native checks without mutating code.
Inspect auth, data handling, migrations, concurrency, external costs, dependencies, queries, UI states, and operability as applicable.
Review manually after tool output; scanners are evidence, not conclusions.
Return findings first with tight file/line references and concrete remediation.

Never run destructive resets, live provider calls, production migrations, or write-mode formatting during a read-only review without explicit authorization.

Deterministic Evidence

Choose proportional checks: formatting check mode, lint, typecheck, focused tests, contract/schema tests, build/bundle analysis, dependency inspection, and existing complexity tooling. Report exact commands and outcomes.

For complexity, report exact cyclomatic/cognitive scores only when tooling supplies them. Treat functions over 10 as prompts for manual inspection, not automatic bugs. State limitations instead of fabricating scores.

Output

Big picture — whether the direction fits the intended outcome.
Findings — ordered P0 through P3; include title, location, behavior, impact, and recommendation.
Checks run — commands, results, complexity evidence, and skipped checks.
Recommendations — blockers first, then follow-ups.
Open questions / residual risk — only when useful.

If no findings survive verification, say so plainly while still reporting checks and residual risk.