# Code Review

> Review code changes for correctness, test coverage, security, performance, and maintainability Use when this capability is needed.

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

---


# Code Review

Perform a structured review of code changes against quality dimensions.

## Workflow

0. **Check lessons (MANDATORY)**
   - Read `.goalrun/lessons.json` for matching failure patterns
   - Search for lessons matching the changed files, error types, or review dimensions
   - If matches found, include them as review checkpoints
   - If no lessons file exists, skip this step

1. **Understand the change**
   - Read the goal specification and implementation strategy
   - Review the diff to understand what changed and why
   - Run the test suite to confirm tests pass

2. **Review dimensions**

   a. **Correctness**
   - Does the change correctly implement the goal?
   - Are edge cases handled?
   - Is error handling appropriate?
   - Are there any off-by-one errors, null reference risks, or race conditions?

   b. **Test Gaps**
   - Does the change include adequate tests?
   - Are edge cases tested?
   - Are negative paths tested? (what happens on failure?)
   - Is there test coverage for rollback/recovery?

   c. **Security**
   - Does the change introduce any OWASP Top 10 vulnerabilities?
   - Are there injection risks (SQL, command, path)?
   - Are secrets or credentials exposed?
   - Is input validated at system boundaries?

   d. **Performance**
   - Are there obvious performance issues (N+1 queries, large allocations)?
   - Is the algorithmic complexity appropriate for the data scale?
   - Are there blocking operations that could be async?

   e. **Maintainability**
   - Is the code clear and self-documenting?
   - Are names descriptive and consistent with the codebase?
   - Is there unnecessary abstraction or duplication?
   - Will a future developer understand this code?

   f. **Observability**
   - Are errors logged with enough context to debug?
   - Are important state transitions observable?

   g. **API Compatibility**
   - Are public APIs changed? If so, is the change backward-compatible?
   - Are deprecations properly signaled?

3. **Produce review report**
   - Summary: APPROVED / CHANGES REQUESTED / BLOCKED
   - Per-dimension findings with severity (error/warning/info)
   - Specific file:line references for each finding
   - Recommendations for each issue

## Required Outputs

- Review report with all dimensions assessed
- An overall verdict: APPROVED, CHANGES REQUESTED, or BLOCKED
- For each finding: severity, location, and recommendation

## Verification Expectations

- Every finding must reference a specific file and line
- BLOCKED verdict requires at least one error-level finding
- APPROVED verdict means no error-level findings
- Security findings are always at least warning severity

## Safety Notes

- This skill only reads files. It does not modify code.
- If a security vulnerability is found, mark it as error severity.
- Do not approve changes that delete or weaken existing tests.
- If tests are missing for the changed behavior, request changes.

---
> Source: [strings77wzq/goal-run](https://github.com/strings77wzq/goal-run) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-16 -->