# React Code Design Review

> Review React and React Native code structure using contextual rules for ownership, data access, UI-to-code mapping, composition, naming, and accessibility. Use when a user asks to review, refactor, or design React code or a component-heavy diff. Inspect real call sites and repository conventions before reporting findings. Do not use for visual styling critique, broad application architecture, or performance review without structural evidence.

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

---


# React Code Design Review

Review React code structure without turning team preferences into universal rules.

## Operating contract

- Treat review as read-only unless the user also asks for fixes.
- Inspect the target component, its call sites, relevant hooks, tests, and nearby conventions.
- Distinguish page, feature, design-system, and reusable leaf components; the right ownership differs by role.
- Report only findings with a concrete maintenance, correctness, accessibility, or change-locality cost.
- Prefer the smallest change that restores a clear owner. Do not reward extraction by itself.

## 1. Establish context

Before judging structure, resolve:

1. platform and rendering model: React web, React Native, server rendering, client rendering, or a mixture;
2. component role and reuse surface;
3. who owns data loading, mutations, state, spacing, error handling, and accessibility;
4. actual call sites and whether the suspected coupling already creates repeated change;
5. repository rules and established component patterns.

If the evidence is unavailable, mark the point as unverified instead of inventing a design problem.

## 2. Apply only relevant rules

Read [references/rules.md](references/rules.md) and select only rules supported by the target code. The rule groups are:

- locality and ownership;
- UI-to-code mapping and responsibility;
- data access and side effects;
- composition and external layout;
- naming and pure logic;
- semantics and accessibility.

Rules are heuristics with exceptions. A server component may intentionally own loading for its subtree. A design-system component may intentionally own layout tokens. A small callback may be clearer as `handleSubmit` than a long procedural name.

## 3. Admit findings narrowly

A finding must contain all four elements:

1. **Location:** exact file and symbol or tight line range.
2. **Evidence:** current call flow, duplicated decision, leaked state, inaccessible interaction, or repeated change cost.
3. **Consequence:** what becomes harder to understand, test, reuse, or change.
4. **Smallest correction:** the minimum ownership or structure change that resolves the evidence.

Reject findings based only on:

- component length;
- hypothetical future reuse;
- personal folder or naming preference;
- a single prop passed one level;
- extraction that merely moves code;
- a rule whose stated exception matches the current design.

## 4. Prioritize

- **High:** correctness, inaccessible interaction, hidden cross-component state, or a structure already causing inconsistent behavior.
- **Medium:** concrete repeated change cost, unclear ownership, or coupling across established seams.
- **Low:** worthwhile cleanup with local evidence but no current behavioral risk.

Do not assign a severity when the claim is only a question or needs missing runtime evidence.

## 5. Report

Return:

```markdown
## React code design review

### Findings
1. [High|Medium|Low] Short title
   - Location: `path:line`
   - Evidence: current code and call-site evidence
   - Consequence: concrete cost or risk
   - Smallest correction: bounded change

### Good boundaries to preserve
- Existing ownership or composition decisions that should not be disturbed

### Unverified
- Missing call-site, runtime, accessibility, or repository evidence

### Verdict
`CLEAN` or `CHANGES_RECOMMENDED`
```

If fixes are authorized, change only admitted findings, run focused checks, and report what each check actually proves.