code-review

Files (6)

• SKILL.md
• .gitkeep · assets/
• .gitkeep · examples/
• .gitkeep · references/
• .gitkeep · scripts/
• .gitkeep · templates/

SKILL.md (first lines)

# Code Review

Review changes for defects and risk, not merely for style preference.

## Review Order

1. Read repository and package guidance before evaluating the change.
2. Inspect the complete diff and relevant surrounding code, tests, contracts, configuration, and
   callers. Do not review only the changed lines.
3. Verify the intended behavior against the task, acceptance criteria, and public interfaces.
4. Trace changed data and control flow across package, process, persistence, and user boundaries.
5. Run or inspect focused validation and identify missing cases.

## Findings

Prioritize findings in this order:

- Data loss, security vulnerabilities, authorization bypasses, or unsafe external effects.
- Incorrect behavior, broken contracts, race conditions, failure handling, or compatibility breaks.
- Missing migrations, incomplete rollout handling, or incorrect configuration and environment use.
- Missing tests for important behavior, error paths, boundaries, or regressions.
- Maintainability problems that make defects likely or violate repository architecture.

Each finding must include the file and line reference, concrete problem, impact, and recommended fix.
Distinguish confirmed defects from questions or residual risks. Do not report formatting preferences as
findings when automated tooling already owns that concern.

## Review Boundaries

- Check public exports, runtime validation, authorization, error mapping, logging, redaction, retries,
  idempotency, and resource cleanup when relevant.
- Check that tests assert behavior rather than implementation details and that mocks do not hide broken
  integration boundaries.
- Check changed files remain under 300 lines and retain one cohesive responsibility.
- Apply [Code Quality](../code-quality/SKILL.md) to the entire changed units: check component and helper
  ownership, duplicated business rules, nested control flow, dense expressions, callbacks,
  transformations, and keyed dispatch. For JSX, also apply
  [JSX Component Extraction](../jsx-component-extraction/SKILL.md).
- Flag structural violations even in short files with passing tests. Require a concrete reason for
  necessary retained complexity. Check that extraction and flattening preserve evaluation order,
  selected-branch execution, errors, side effects, state ownership, and cleanup; moving complexity
  into vague helpers does not resolve it.
- Check documentation, checklist statuses, release notes, and generated artifacts when the change
  affects them.
- Flag any use of `--no-verify`, `--no-hooks`, `HUSKY=0`, skipped hooks, disabled checks, or equivalent
  validation bypasses.
- Treat an unauthorized commit, amend, push, force-push, tag, publish, release, or deploy as a
  repository-process violation.

## Report

List findings first, ordered by severity. Then list open questions, assumptions, testing gaps, and a
brief change summary. If no findings exist, state that explicitly and identify residual risks or
validation gaps.

From gowebknot/monorepo-template, MIT.

More from gowebknot/monorepo-template