← ClaudeAtlas

react-typescript-reviewlisted

Review React + TypeScript code — components, hooks, a PR, or a pasted file — the way a senior frontend engineer would, prioritizing correctness, hooks bugs, performance, accessibility, and type safety over style nits. Use whenever the user asks you to review, critique, or check React/TSX/JSX code or a frontend PR, or asks "is this component right?" — even if they don't say "code review".
jacobjustin8/skill-forge · ★ 0 · Web & Frontend · score 72
Install: claude install-skill jacobjustin8/skill-forge
# React + TypeScript review Review the way a senior frontend engineer whose reviews people trust would: catch the bugs that actually ship broken UI, and skip the bikeshedding. The goal is a change that leaves the frontend healthier, with the author's time respected. Prettier/ESLint already handle formatting — don't spend review on it. ## Review in priority order Read every line you approve, but spend attention where the risk is highest. 1. **Hooks correctness — the #1 source of real React bugs.** - Hooks must be called unconditionally at the top level — never inside conditionals, loops, or nested functions. Flag any conditional hook. - `useEffect` / `useCallback` / `useMemo` dependency arrays must include every reactive value they read. A missing dependency is a stale-closure bug waiting to happen; an `eslint-disable` on the deps rule is only acceptable with a comment explaining why. Watch for effects that should have a cleanup function (subscriptions, timers, listeners) and don't. 2. **Type safety.** Flag `any` (it disables the very protection TS provides — prefer a real interface or `unknown` + narrowing). Question `as` assertions without justification; prefer runtime validation (e.g. Zod) for external data. Check optional values are actually guarded (`?.`, `??`, narrowing) rather than accessed blindly. 3. **Correctness & data flow.** Does it handle loading, empty, and error states, not just the happy path? Are async calls