# Code Review Standards

## When to Review

Review meaningful code changes before declaring them complete, committing to a shared branch, or opening a pull request. Security-sensitive and architectural changes require extra scrutiny.

## Use Available Pi Capabilities

If the current Pi session exposes a review or security skill, load its `SKILL.md` and follow it. If a Pi extension provides a dedicated reviewer or sub-agent tool, use it only when available and collect its result before continuing. Otherwise perform the review directly with Pi's file, diff, and shell tools.

Do not assume named reviewer agents are built into Pi.

## Pre-Review Requirements

Before final review:

- inspect the full relevant diff;
- run the project's configured type, lint, test, and build checks;
- resolve merge conflicts;
- verify the branch state against the intended base when preparing a pull request.

## Review Checklist

- [ ] Code is readable and well-named
- [ ] Functions and files remain focused
- [ ] Errors are handled explicitly
- [ ] Inputs are validated at system boundaries
- [ ] No hardcoded secrets or credentials
- [ ] No debug statements remain
- [ ] Tests cover new or changed behavior
- [ ] Relevant automated checks pass

## Security Review Triggers

Apply a security-focused review when changing:

- authentication or authorization;
- user input handling;
- database queries;
- file-system access;
- external API calls;
- cryptography;
- payment or financial code.

If a security issue is found, stop unrelated work and fix critical issues first.

## Severity Levels

| Level | Meaning | Action |
|-------|---------|--------|
| CRITICAL | Exploitable vulnerability or data-loss risk | Block completion until fixed |
| HIGH | Likely bug or significant quality risk | Fix before merge |
| MEDIUM | Maintainability or limited-risk issue | Fix when practical or document |
| LOW | Minor style or optional improvement | Note if useful |

## Review Workflow

1. Inspect `git diff` and the affected call paths.
2. Check security and data-loss risks first.
3. Review correctness, error handling, and maintainability.
4. Run the relevant automated checks.
5. Confirm tests exercise the changed behavior.
6. Report findings by severity with file and line references.

Approval requires no unresolved CRITICAL or HIGH findings.