code-review

When running a code review, follow the process outlined here.

## Project Context

- git installed: !`which git 2>/dev/null || echo "not installed"`
- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
- personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
- project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read
that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md`
probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence
between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

## Review Constraints

Severity levels:

- **Critical** — Must fix before merge. Security vulnerabilities, data corruption risk, breaking API changes, data
  isolation failures.
- **Warning** — Should fix. Bugs that don't corrupt data, significant performance issues, missing required tests,
  missing error handling.
- **Suggestion** — Consider improving. Style improvements, optional performance gains, documentation gaps, refactoring
  opportunities.

Severity calibration is governed by **Step 3.3** (the authoritative home for size-based demotion). Manual findings from
Steps 4 to 6 follow the same size-based rules as agent findings classified at Step 7: Small changes escalate only
Critical findings and default uncertain ones to the lower severity, Medium changes escalate Critical and Warning, Large
changes prefer the higher severity when in doubt. Read `{size}` from Step 3.1. Include `file_path:line_number`
references and code examples for suggested fixes.

**Finding caps:** Manual review findings (Steps 4-6) and agent findings (Step 7) are each capped at 30 items. Prioritize
by severity: all CRIT first, then WARN, then SUGG. If either cap is exceeded, note that additional items were omitted
and another code review is recommended after addressing current items. Security findings are not capped (see
classification rubric).

**Project pattern deference:** A pattern that differs from general best practices but is consistent within the project
is not a review finding. Only flag deviations from the project's own conventions.

**YAGNI findings are a separate, non-correcting class.** Apply the two-pass YAGNI procedure documented in
[`references/review-checklist.md`](./references/review-checklist.md) (the canonical home for the procedure and the
(a)/(b)/(c) recording requirement) to every change in the diff. **YAGNI findings are listed in their own `### 🟡 YAGNI`
section, separate from Critical / Warning / Suggestion**, and **do not appear under CRIT / WARN / SUGG**. The YAGNI
section opens with this exact statement: _"These findings will not be corrected unless explicitly requested. They are
documented so the team can decide consciously whether to keep, simplify, or defer the items."_ Severity calibration (the
directive in Step 3.3, the authoritative home) does NOT apply to YAGNI; these findings are surfaced regardless of change
size and are advisory, not corrective.

**Automated tool boundary:** If the project has a linter or formatter, trust it. Only flag style issues that automated
tools can't catch.

**Readability standard:** The review report is a reader-facing deliverable. As it writes the finding prose and
narrative, the skill sources the shared standard by invoking `han-communication:readability-guidance` (Step 8) and
applies it, holding the named audience: the author and reviewers of the change under review. The standard governs how
each finding reads (lead with what to do and why, one idea per paragraph, short active sentences, plain words), and
drops a required technical fact only when the reader asked for less and losing it would not change what they do next. It
applies to the prose in finding bodies and narrative sections only; it never rewrites task IDs, severities,
`file_path:line_number` references, `EXPLOIT:` fields, category labels, the fixed section headings and their order, the
Review Summary table structure, or any code snippet. The dedicated `han-communication:readability-editor` rewrite (Step
8.5) and the readability self-check (Step 9.2) carry the standard into the report.

### Task ID Assignment

Assign a unique task ID to each review item:

- **CRIT-###** for critical items (e.g., CRIT-001, CRIT-002)
- **WARN-###** for warnings (e.g., WARN-001, WARN-002)
- **SUGG-###** for suggestions (e.g., SUGG-001, SUGG-002)
- **YAGNI-###** for YAGNI candidates (e.g., YAGNI-001, YAGNI-002) — these are advisory and listed in their own section;
  they are not corrected unless the user explicitly requests it

IDs are sequential within each category, starting at 001. Assign IDs in the order files are reviewed (alphabetically).

**Category Assignment:** When an issue fits multiple categories, use the **first matching category** from the checklist
order in [review-checklist.md](./references/review-checklist.md).

## Step 1: Identify Changes

Resolve project config: read CLAUDE.md's `## Project Discovery` section for docs, ADR, and coding-standards directories
plus test, lint, and build commands (look under `### Commands and Tests`, not `### Frameworks and Tooling`); fall back
to project-discovery.md; fall back to Glob defaults (`docs/`, `docs/adr/`, `docs/coding-standards/`). Store found values
for use in Steps 2, 5, and 6. Continue without any keys that remain unfound.

### Detect review context

Check the `git installed` value from Project Context above. If it is empty or reads `not installed`, skip directly to
**Mode C** below.

1. Run `${CLAUDE_SKILL_DIR}/scripts/detect-review-context.sh` to detect the git environment. Capture the output — it
   contains key-