# Code Review Standards

> Severity-tagged code review rubric (CRITICAL/HIGH/MEDIUM/LOW) used by the code-critic agent to produce APPROVE/WARN/BLOCK verdicts with evidence-backed findings

- Skill: `bobmatnyc/code-review-standards-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bobmatnyc/code-review-standards-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bobmatnyc/code-review-standards-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: bobmatnyc (https://skillmd.com/u/bobmatnyc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/bobmatnyc/code-review-standards-3

---


# Code Review Standards

## Purpose

This skill defines the structured, severity-tagged checklist the `code-critic` agent applies
when reviewing an implementation. Severity tagging makes review deterministic across
dispatches: PM and engineer both know exactly which findings block delivery and which are
advisory. Engineers may load it for self-review before requesting a critic pass.

## The Severity-Tagged Checklist

### CRITICAL (must fix — blocks delivery)
- No secrets, API keys, or credentials hardcoded
- No injection vectors (parameterized queries only; no unsafe shell/template interpolation)
- No arbitrary code execution paths (`eval`, `exec`, unrestricted deserialization)
- Authentication/authorization not bypassable
- No data-loss or silent-corruption paths

### HIGH (must fix — blocks delivery)
- Type hints / static types on public functions and classes; type checker passes clean
- Tests pass with zero failures; meaningful coverage on new code
- No bare `except`, no swallowed errors, error cases handled explicitly
- No mutable default arguments, no unguarded global mutable state
- No synchronous I/O inside async functions; no N+1 query patterns

### MEDIUM (flag, note in report, proceed)
- Functions reasonably small and single-purpose
- Hash maps used where nested loops would otherwise dominate complexity
- Async operations have explicit timeouts
- Docstrings on public methods; no stray `Any` in production paths

### LOW (note only)
- Formatter/linter clean (handled by tooling)
- Clear naming, no commented-out code, tidy imports

## Verdict Protocol

First line of the critic response MUST be the verdict, followed by a finding table.

| Verdict | Condition | PM Action |
|---------|-----------|-----------|
| APPROVE | Zero CRITICAL, zero HIGH | Proceed to security review |
| WARN | Zero CRITICAL, one or more HIGH | Proceed, but log finding table to handoff |
| BLOCK | Any CRITICAL | Halt, surface findings to user, await direction |

Finding table columns: `Severity | File | Line | Issue | Required Fix`.

## 80% Confidence Filter

A clean review is a valid review — do not manufacture findings. Only report issues you are
>80% confident are real problems. Below that threshold, raise the concern as a question in
the summary paragraph rather than as a table row. Each table finding must be actionable: the
engineer should be able to fix it without asking for clarification.