code-review-react-ts

Usage Scenarios and Workflow

Phase 1 (Identify Issues)：Use this skill's checklist to scan the given React/TypeScript code, list potential issues and their categories.
Phase 2 (Solutions & Comments)：For each identified issue, read the corresponding file in the
references/
folder to get recommended solutions and review comment templates, then generate specific optimization suggestions or comments.

The main body of this skill only retains what to check; specific code examples, solutions, and review comments are all under references/
, and should be read when needed to save tokens.

Review Priority (Top to Bottom)

Priority	Content
High (Mandatory)	Security, Type safety, Logic bugs, Performance
Medium (Recommended)	Architecture, Accessibility, Tests, Error handling
Low (Suggested)	Coding style / API design preferences (see Category 9), Naming, Minor optimizations
Ignore	Pure personal style, preferences not agreed upon by the team, bikeshedding

Handle high-priority items first, then move downwards. It would be incorrect to comment on indentation before addressing type safety.

Checklist (For Identifying Issues)

Scan against the following red flags. If an item is found, read the corresponding reference file to get solutions and review comments.

1. Type Safety (High) →

references/01-type-safety.md

Type assertions (
```
as
```
) without valid reasons
Missing null/undefined checks
Incorrect type narrowing (e.g., relying solely on
```
if (value)
```
cannot narrow a union type)

2. React Patterns (High) →

references/02-react-patterns.md

Violating Rules of Hooks (calling hooks inside conditions/loops)
Incomplete dependency arrays in useEffect/useCallback
Causing unnecessary re-renders (inline functions/objects)
State derived from props not synchronized
Directly mutating state

3. Performance (High) →

references/03-performance.md

Expensive calculations in render (not using useMemo)
Importing entire large libraries (e.g.,
```
import _ from 'lodash'
```
)
Using index as key or no key for lists
Using setState to trigger re-renders for high-frequency interactions (mousemove, drag-and-drop, animations) where the value doesn't need to be read by other components (should use useRef to write directly to DOM instead)

4. Security (High) →

references/04-security.md

Potential XSS (unsanitized
```
dangerouslySetInnerHTML
```
)
Sensitive data leakage (hardcoded keys, logging passwords, etc.)
Unencoded user input used in APIs (e.g., query strings)

5. Architecture (Medium) →

references/05-architecture.md

God component (single component is too large and has excessive responsibilities)
Excessive prop drilling
Business logic mixed with UI in components

6. Accessibility (Medium) →

references/06-accessibility.md

Lack of semantic HTML (e.g., using div as a button)
Icon-only buttons missing ARIA attributes or visible text
Interactive elements cannot be operated via keyboard

7. Error Handling (Medium) →

references/07-error-handling.md

Unhandled Promise rejections (no .catch / try-catch)
Silently swallowing errors after catch, no feedback to users

8. Testing (Medium) →

references/08-testing.md

Logic/APIs written inside components making them hard to test
Key flows (e.g., payment) lack corresponding tests

9. Coding Style / API Design (Low, Suggestive) →

references/09-coding-style.md

Not a red flag; adoption does not affect correctness. Present as 🟡 SUGGESTION, authors may choose not to adopt.

From top to bottom: modification cost increases from low to high (renaming → type changes → API restructuring).

🟢 Simple (renaming / type changes only)

Boolean props lack
```
is
```
/
```
has
```
/
```
should
```
prefixes (unless mirroring native HTML attributes)
Callback props not named with
```
on*
```
(e.g.,
```
change
```
instead of
```
onChange
```
,
```
onValueChange
```
)

Prop names duplicate component context (

<Dialog isDialogOpen />

<Button buttonColor />

)

Prop types are too broad (using
```
string
```
when only a few values are actually accepted; should change to union literal / template literal)
Components wrapping native HTML elements do not inherit
```
React.ComponentProps<'tag'>
```
, causing
```
onClick
```
/
```
aria-*
```
/
```
className
```
to be unpassable

🟡 Medium (minor API / type adjustments)

Using multiple mutually exclusive booleans to represent state, creating impossible combinations (suggest changing to enum / variant)
Adding boolean props for behaviors that can actually be derived from existing props (e.g.,
```
isClosable
```
coexisting with
```
onClose
```
)
Render props using generic
```
children
```
functions with unclear parameter meanings (suggest naming
```
renderItem(item, state)
```
)
Variant-dependent props using ordinary optional unions, allowing impossible type combinations (suggest changing to discriminated union)
Symbiotic types like
```
value
```
/
```
onChange
```
/
```
options
```
are hardcoded, not linked via generics for inference

🔴 Major (API structure restructuring)

Custom form components only support controlled or uncontrolled mode (should mirror native
```
value
```
/
```
defaultValue
```
)
Components have accumulated 4+ boolean / className props to control internal parts (suggest considering compound components)
UI structure is embedded in data arrays for configuration (e.g.,
```
items={[{label, icon, submenu...}]}
```
), losing JSX expressiveness

Review Principles (Reference When Writing Comments)

Use questions instead of commands: "Could we use useMemo here?" instead of "Use useMemo."
Explain the reason: Don't just say "Add error handling"; instead, say "If the API fails, users won't be aware. Suggest using a toast to improve UX."
Provide options: For example, "(1) Extract into a custom hook (2) Use React Query for caching".
Mark severity:
- 🔴 BLOCKING: e.g., XSS, critical type/logic errors
- 🟡 SUGGESTION: Optimizable (e.g., useMemo)
- 🟢 PRAISE: Worthwhile writing style
Stay focused: Type safety, React rules, performance, security, architecture.
Ignore: Personal style, subjective preferences, bikeshedding.

Summary

Scanning Phase: Use the above checklist to identify issues and categories; do not expand on code or long-form solutions here.
Output Phase: For each issue, open the corresponding
```
references/XX-...md
```
file and generate solutions and review comments based on its content.

code-review-react-ts

NPX Install

Tags

SKILL.md Content (Chinese)

Usage Scenarios and Workflow

Review Priority (Top to Bottom)

Checklist (For Identifying Issues)

1. Type Safety (High) →
`references/01-type-safety.md`

2. React Patterns (High) →
`references/02-react-patterns.md`

3. Performance (High) →
`references/03-performance.md`

4. Security (High) →
`references/04-security.md`

5. Architecture (Medium) →
`references/05-architecture.md`

6. Accessibility (Medium) →
`references/06-accessibility.md`

7. Error Handling (Medium) →
`references/07-error-handling.md`

8. Testing (Medium) →
`references/08-testing.md`

9. Coding Style / API Design (Low, Suggestive) →
`references/09-coding-style.md`

Review Principles (Reference When Writing Comments)

Summary