# Handsontable Code Review

> Use when reviewing changed or staged code, a branch, or a PR in the Handsontable monorepo across architecture, code quality, performance, accessibility, and tests. Covers SOLID / Law of Demeter / plugin decoupling / breaking-changes policy, custom ESLint rules / JSDoc / naming / cognitive complexity, large-array and render-batching performance, WCAG 2.1 AA + keyboard navigation, and the tests a change ships (a named exercising test per new path, scoped mutation, a ticket on every weakened assertion). Trigger when asked to review changes, check a diff against Handsontable conventions, assess architectural correctness, spot performance regressions, verify accessibility, or judge whether a change's tests prove it — and as the design lens before or while implementing any core change.

- Skill: `handsontable/handsontable-code-review` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add handsontable/handsontable-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/handsontable/handsontable-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: handsontable (https://skillmd.com/u/handsontable)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/handsontable/handsontable-code-review

---


# Handsontable code review

Review staged or changed code across four dimensions: architecture, code quality, performance + accessibility, and tests. Apply all four for a full review. For a scoped request ("just check a11y", "is this architecturally sound?"), read only the relevant dimension.

## Workflow

1. Collect the changes: `git diff` (or `git diff --staged`).
2. Apply each dimension's checklist — read the reference file for the dimension you need:
   - **Architecture** — `references/architecture.md`: SOLID, Law of Demeter, plugin decoupling, conflict ownership, coordinate-system correctness, breaking-changes policy, convention over configuration. Also the design lens while implementing any core change, not only at review time.
   - **Code quality** — `references/code-quality.md`: custom ESLint rules, JSDoc, naming, cognitive complexity, DRY, the TypeScript boundary.
   - **Performance & accessibility** — `references/performance-a11y.md`: large-array safety, render batching, memory cleanup, WCAG 2.1 AA, keyboard navigation, ARIA semantics.
   - **Tests** — `references/tests.md`: a named exercising test for every new interaction path and option form, scoped mutation when unit tests changed, near-duplicate DOM helpers, timing-semantics JSDoc checked against its primitive, a ticket on every weakened or deleted assertion.
3. Report using the output format below, applying the general review practices.

## General review practices

Apply these alongside the dimension checklists. They are the durable practices from the built-in `/code-review` command, adapted for an in-repo review (skip its PR-commenting orchestration — the value is the review discipline).

- **Review several lenses on the diff, not just the code in isolation:** AGENTS.md / CLAUDE.md adherence at the correct scope, obvious bugs, the git blame and history of the modified lines, comments on prior PRs that touched these files, and guidance in nearby code comments.
- **Focus on the changed lines.** Do not flag pre-existing issues, or problems on lines the change did not touch.
- **Confidence filtering — surface only what you are confident is real.** For each candidate issue, judge how likely it is a genuine problem that will be hit in practice. The bar is roughly "highly confident": you verified it is real and it materially affects functionality, or it is explicitly called out in an AGENTS.md at the relevant scope. Drop low-confidence findings and likely false positives rather than padding the report — a short list of real issues beats a long list of maybes.
- **Do not flag what other tooling catches.** Skip anything a linter, type-checker, or compiler would surface (missing or wrong imports, type errors, formatting, pedantic style). CI runs those separately; do not build, type-check, or run tests yourself for the review. The one exception is the scoped mutation run in `references/tests.md`, when the diff changes unit tests — no other tool measures what a new test would catch.
- **Skip nitpicks a senior engineer would not raise.** Pedantic style not called out in an AGENTS.md, intentional functional changes that belong to the broader work, and issues already silenced with a documented lint-ignore are not findings.
- **Cite every finding** with a `file:line` reference (link the file and line range when commenting on a PR).

## Output format

List findings by severity:

- **Critical** — breaks builds, tests, or runtime behavior.
- **High** — violates an enforced ESLint rule or a mandatory convention.
- **Medium** — style or maintainability concern.
- **Low** — suggestion for improvement.

Each finding includes a `file:line` reference and a short explanation. When reporting more than one dimension, group findings under Architecture / Code quality / Performance / Accessibility / Tests headings.

If no issues are found, output exactly: `No blocking issues found.`