# Review Code

> Review code with risk-first analysis, reproducible evidence, and patch-ready guidance for correctness, security, performance, and maintainability.

- Skill: `dvcrn/review-code` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add dvcrn/review-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dvcrn/review-code/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: dvcrn (https://skillmd.com/u/dvcrn)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/dvcrn/review-code

---


## Setup

On first use, read `setup.md` for integration guidance and local memory initialization.

## When to Use

User asks for a code review, PR review, merge-readiness check, or bug-risk audit before shipping.
Agent delivers a risk-ranked review with explicit evidence, impact, confidence, and concrete fix direction.

## Architecture

Memory lives in `~/review-code/`. See `memory-template.md` for structure and starter templates.

```text
~/review-code/
├── memory.md             # Review preferences, stack context, and recent constraints
├── findings/             # Optional per-review finding logs
├── baselines/            # Team conventions and accepted risk baselines
└── sessions/             # Session summaries for ongoing audits
```

## Quick Reference

| Topic | File |
|-------|------|
| Setup and integration behavior | `setup.md` |
| Memory schema and templates | `memory-template.md` |
| End-to-end review execution flow | `review-workflow.md` |
| Severity and confidence calibration | `severity-and-confidence.md` |
| Language and architecture risk checks | `language-risk-checklists.md` |
| Test impact requirements by change type | `test-impact-playbook.md` |
| Comment and report templates | `comment-templates.md` |
| Patch strategy for actionable fixes | `patch-strategy.md` |

## Data Storage

Local notes stay in `~/review-code/`.
Before creating or changing local files, present the planned write and ask for user confirmation.

## Core Rules

### 1. Define the Review Contract First
Confirm target scope before reviewing: branch, files, risk tolerance, and release context.
If scope is unclear, state assumptions explicitly and keep findings tied to those assumptions.

### 2. Start With Risk Mapping, Then Deep Dive
Run a fast pass to locate high-risk zones first: auth, money, data integrity, concurrency, and migration paths.
Only then perform line-level analysis with `review-workflow.md` so major failures are surfaced early.

### 3. Every Finding Must Be Evidence-Backed
Do not report vague concerns.
Each finding must include: trigger location, concrete failure mode, user or business impact, and minimal reproduction clue.
If evidence is weak, mark low confidence or downgrade to a question.

### 4. Separate Blocking vs Advisory With Severity + Confidence
Use `severity-and-confidence.md` for consistent triage.
Blocking findings must be reproducible or highly probable with strong impact.
Advisory feedback must remain concise and never hide blockers.

### 5. Always Pair Findings With a Fix Path
For each blocking issue, provide a minimally disruptive fix strategy.
Use `patch-strategy.md` to propose rollback-safe edits, guard tests, and verification steps.

### 6. Tie Review Quality to Test Impact
Map each change to required tests using `test-impact-playbook.md`.
If tests are missing, list the exact scenarios that must be added and why they prevent regressions.

### 7. Optimize for Signal, Not Volume
Prioritize high-impact defects over style noise.
If no blockers are found, state that explicitly and list residual risks, test gaps, and monitoring advice.

## Common Traps

- Reporting opinions as facts -> review credibility drops and teams ignore real blockers.
- Mixing blocker and nit feedback without labels -> delayed merges and mis-prioritized fixes.
- Calling something “probably fine” without tests -> silent regressions in production.
- Suggesting large rewrites for local defects -> good fixes are postponed indefinitely.
- Ignoring release context (hotfix vs refactor) -> wrong trade-offs for urgency.
- Missing migration and backward-compatibility checks -> runtime failures after deploy.

## External Endpoints

This skill makes NO external network requests.

| Endpoint | Data Sent | Purpose |
|----------|-----------|---------|
| None | None | N/A |

No other data is sent externally.

## Security & Privacy

**Data that leaves your machine:**
- Nothing by default. This is an instruction-only review skill unless the user explicitly exports artifacts.

**Data stored locally:**
- Review preferences, project constraints, and optional findings approved by the user.
- Stored in `~/review-code/`.

**This skill does NOT:**
- auto-approve code or merge pull requests.
- make undeclared network calls.
- store credentials, tokens, or sensitive payloads.
- modify its own core instructions or auxiliary files.

## Trust

This is an instruction-only code review skill.
No credentials are required and no third-party services are contacted by default.

## Related Skills
Install with `clawhub install <slug>` if user confirms:
- `code` - implementation workflow that complements review findings.
- `git` - safer branch, diff, and commit handling during remediation.
- `typescript` - stricter typing and runtime safety review for TS-heavy codebases.
- `ci-cd` - release-gate checks and deployment safeguards after fixes.
- `devops` - production risk assessment and rollback planning.

## Feedback

- If useful: `clawhub star review-code`
- Stay updated: `clawhub sync`