React + TypeScript
Pathrule2 Rules • 2 Memories • 1 Skill
Rules, memories, and a review skill for React codebases written in TypeScript. Pre-scoped to your source and component directories so your AI assistant writes typed, accessible, and predictable components.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
react-component-review
src/
Component structure conventions
Hooks discipline and data fetching
components/
Type props explicitly, no any
Interactive elements must be accessible
Rules
2Type props explicitly, no any/src/componentsmediumadvisoryEvery component has an explicit props type and avoids any.
| 1 | Every component has an explicit props type and avoids `any`. |
| 2 | |
| 3 | - Prefer `unknown` with narrowing when a type is genuinely unknown. |
| 4 | - Type event handlers and refs precisely. |
| 5 | - Derive types from a single source of truth (schemas, API types) rather than restating shapes that can drift. |
Interactive elements must be accessible/src/componentshighadvisoryUse real semantics, labels, and keyboard support.
| 1 | Use real semantics before reaching for a `div` with handlers. |
| 2 | |
| 3 | - Prefer native `button`, `a`, `label`, `input`. |
| 4 | - Every control has an accessible name, a visible focus state, and full keyboard operability. |
| 5 | - Images have `alt` text, and color is never the only signal. |
Memories
2Component structure conventions/srcSmall, focused components; colocate state and lift only when shared.
| 1 | Keep components small and focused on one responsibility. |
| 2 | |
| 3 | - Colocate state with the component that owns it; lift only when genuinely shared. |
| 4 | - Separate presentational components from data access. |
| 5 | - Name files and exports consistently so the tree is predictable to navigate. |
Hooks discipline and data fetching/srcFollow the rules of hooks; fetch with a real data layer, not raw effects.
| 1 | Call hooks unconditionally at the top level with honest dependency arrays. |
| 2 | |
| 3 | - Avoid effects for data fetching; use a data-fetching library or the framework's server data layer. |
| 4 | - Custom hooks encapsulate reusable logic. |
| 5 | - Return stable references where identity matters. |
Skills
1react-component-review/rootChecklist for reviewing a new or changed React component.
| 1 | --- |
| 2 | name: react-component-review |
| 3 | description: Review a React + TypeScript component for types, accessibility, and hook correctness. |
| 4 | --- |
| 5 | |
| 6 | # React component review |
| 7 | |
| 8 | - [ ] Props are explicitly typed; no any |
| 9 | - [ ] Interactive elements use native semantics, labels, and keyboard support |
| 10 | - [ ] Hooks are called unconditionally with honest dependency arrays |
| 11 | - [ ] No data fetching inside raw effects |
| 12 | - [ ] Component has one clear responsibility and reasonable size |
| 13 | - [ ] State lives at the right level (colocated, lifted only when shared) |
| 14 | - [ ] No needless re-renders from unstable inline props or callbacks |
Why this pattern
React and TypeScript components drift into any-typed props, inaccessible controls, and effect-driven data fetching.
Built for frontend teams writing React in TypeScript.
Keeps your assistant from:
- Untyped or any-typed props and event handlers
- div-with-onClick controls that fail keyboard and screen-reader users
- Fetching data inside effects instead of a real data layer
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-06-09