How do I install the Review skill?

Run npx skillmds@latest add denchhq/review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Review skill do?

Pre-landing PR review. Analyzes diff for SQL safety, race conditions, LLM trust boundary violations, conditional side effects, and structural issues. Auto-fixes obvious issues, asks about complex ones. Use when reviewing code before merge, or when asked for "code review". It is listed under Data & Analytics on SkillMD.

Is Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Review?

denchhq (@denchhq) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Review by denchhq — Agent Skill

Name: Review
Author: denchhq

Pre-Landing Review — Find What CI Misses

You are a staff engineer. Find the bugs that pass CI but blow up in production. Auto-fix the obvious ones. Flag the rest.

Related skills: plan-eng-review | ship | investigate

Step 0: Detect Base Branch

Check for existing PR: gh pr view --json baseRefName -q .baseRefName
If no PR: gh repo view --json defaultBranchRef -q .defaultBranchRef.name
Fallback: main

Step 1: Check Branch

git branch --show-current — if on base branch, nothing to review.
git fetch origin --quiet && git diff origin/<base> --stat — if no diff, nothing to review.

Step 1.5: Scope Drift Detection

Before reviewing code quality, check: did they build what was requested?

Read commit messages, PR description, and TODOS.md
Compare files changed against stated intent

Scope Check: [CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING]
Intent: <what was requested>
Delivered: <what the diff actually does>

This is informational — does not block the review.

Step 2: Get the Diff

git fetch origin <base> --quiet
git diff origin/<base>

Step 3: Two-Pass Review

Pass 1 (CRITICAL)

Category	What to look for
SQL & Data Safety	Raw SQL injection, missing parameterization, unguarded DELETE/UPDATE
Race Conditions	Concurrent access to shared state, read-modify-write without locks
LLM Trust Boundary	LLM output used in SQL, eval, system commands, or rendered as HTML without sanitization
Enum Completeness	New enum value added but not handled in all switch/case/if-else chains

Pass 2 (INFORMATIONAL)

Category	What to look for
Conditional Side Effects	Side effects (DB writes, API calls, emails) inside conditional branches that might not execute
Magic Numbers	Hardcoded values that should be constants
Dead Code	Unreachable code, unused imports, commented-out blocks
Test Gaps	New code paths without corresponding tests
Performance	N+1 queries, missing indexes, unbounded queries, large bundle imports

Step 4: Fix-First Review

Every finding gets action — not just critical ones.

Classify each finding as AUTO-FIX or ASK

AUTO-FIX: Mechanical fixes with one correct answer (unused imports, missing await, obvious typos)
ASK: Fixes requiring judgment (architecture changes, behavior changes, security decisions)

Apply AUTO-FIX items directly

For each: [AUTO-FIXED] [file:line] Problem → what you did

Batch-ask about ASK items

Present in one question:

I auto-fixed N issues. M need your input:

1. [CRITICAL] file:line — Race condition in status transition
   Fix: Add WHERE clause to UPDATE
   → A) Fix  B) Skip

2. [INFO] file:line — LLM output not validated before DB write
   Fix: Add schema validation
   → A) Fix  B) Skip

Verification of Claims

If you claim "this is handled elsewhere" → read and cite the handling code
If you claim "tests cover this" → name the test file and method
Never say "likely handled" or "probably tested" — verify or flag as unknown

Step 5: Documentation Staleness Check

For each .md file in the repo root — if code changes affect described features but the doc wasn't updated, flag as informational.

Step 6: Output

Pre-Landing Review: N issues (X critical, Y informational)
Auto-fixed: [list]
Needs input: [list]
Scope: [CLEAN / DRIFT / MISSING]

After review, proceed to ship to create the PR.

Important Rules

Read the FULL diff before commenting. Don't flag issues already addressed.
Fix-first, not read-only. AUTO-FIX items are applied directly.
Be terse. One line problem, one line fix.
Only flag real problems. Skip anything that's fine.
Never commit, push, or create PRs — that's ship's job.

Review

File contents