# Review

> Self-review the complete scoped diff for correctness, regressions, requirements and repository rules before delivery. Use after implementation or when asked to find problems in changes; use `security-review` for security-specific analysis.

- Skill: `navikt/review-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add navikt/review-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/navikt/review-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: navikt (https://skillmd.com/u/navikt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/navikt/review-2

---

# Review the complete task diff

> **OpenCode v1:** Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native `skill` tool. Slash commands are direct user entry points only.

This is the ordinary self-review pass. An independent Inspector verdict remains
a separate review when the calling workflow requires it.

If the user requests a walkthrough, start explaining the change at their
requested pace instead of replacing that request with this self-review pass.
`guided-review` is a manual skill: apply it when the user explicitly invokes it
through the client's skill entrypoint. Do not automatically load it or require
another confirmation or a skill command before providing a requested explanation.

## Establish the boundary

Read the acceptance criteria, locked decisions, and repository instructions
that govern the task. Resolve the stated base or fixed point, then account for
staged, unstaged, committed, and untracked changes in scope. Read every new
untracked file in full because ordinary diff output omits it.

Stop when the diff is empty, the base is ambiguous, or unrelated work cannot
be separated safely. Review primary evidence, not the implementation summary or
memory of the intended change.

## Review six axes separately

1. **Correctness** — trace changed control and data flow; check errors, state
   transitions, cleanup, concurrency, and failure handling.
2. **Regression** — find affected callers, contracts, shared defaults,
   migrations, and behavior outside the immediate edit.
3. **Edge cases** — test relevant empty, missing, malformed, repeated,
   concurrent, timeout, retry, and partial-failure cases.
4. **Requirement coverage** — map every acceptance criterion and locked
   decision to concrete code or test evidence.
5. **Repository standards** — check established architecture, naming,
   language, test, documentation, and delivery rules.
6. **Scope** — require every hunk to serve the task and identify requested
   behavior the diff does not implement.

When the change touches personal or confidential data, authentication or
authorization, secrets, logging, network trust, external integrations,
deployment permissions, or another security boundary, invoke and apply
`security-review`.

## Correct and verify

If the active caller is the writer, fix in-scope findings before returning. If
Grillmester is reviewing work from `kokk`, do not edit the
implementation in the orchestration context; send Kokk the smallest bounded
correction instead.

Discover deterministic gates from repository instructions, build files, test
configuration, and CI rather than assuming a toolchain. Run the smallest
relevant checks and required final gates after the last edit. Record commands,
relevant results, and exit codes; distinguish fresh evidence from stale or
unverified claims.

Report material findings first, ordered by consequence. For each finding, give
the affected path and line when available, the concrete failure mode, and the
smallest useful correction. End with acceptance-criterion coverage, gate
evidence, and remaining uncertainty. A clean review must still state what was
inspected and what the evidence does not prove.