React & TypeScript coding standards
This skill applies company coding standards expressed as Avoid (anti-patterns) and Prefer (recommended patterns) to in-code patterns only. For file and folder naming and structure, use react-files-structure-standards.
Reference categories
Standards are defined in the references/ folder. Load these files when you need the exact Avoid/Prefer rules and examples:
| Category |
File |
Scope |
| Coding patterns |
references/common-coding-patterns.md |
TypeScript (types, control flow, errors, enums, destructuring, etc.) |
| Naming patterns |
references/common-naming-patterns.md |
In-code naming (boolean prefixes, descriptive names) |
| React patterns |
references/common-react-patterns.md |
Hooks, components, JSX, state, styling, fragments |
| Unit testing |
references/common-unit-testing.md |
Jest, React Testing Library, AAA, mocks, selectors |
Three-phase workflow
When the skill is invoked on code (selected files, git staged files, branch):
Preliminary — Run linter
- Run the project linter:
yarn lint or npm run lint (use the one that matches the project).
- Collect every reported rule violation (rule id/name, file, line, message).
- For each violation:
- If the rule is auto-fixable (e.g.
--fix / eslint --fix), run the fix (e.g. yarn lint --fix or npm run lint --fix) and consider the violation resolved.
- If the fix is not automatic, do your best to find a solution with the help of coding guidelines in
references/*.md (coding → common-coding-patterns, naming → common-naming-patterns, React → common-react-patterns, tests → common-unit-testing) and apply the Prefer correction described for that rule.
- Re-run the linter after fixes; repeat until lint passes or only violations that need manual interpretation remain.
Phase 1 — Collect violations
- Analyze the provided code against the reference files above.
- Identify every place where the code matches an Avoid pattern.
- List each violation in a single report with:
- Category (coding / naming / React / unit testing)
- Rule name (e.g. "Avoid Using
any for Type Definitions")
- Location (file and line or snippet)
- Short reason (what is wrong)
- If no Avoid pattern is found, state that the code complies and stop. Otherwise proceed to Phase 2.
Phase 2 — Apply corrections
- For each violation in the report:
- Open the corresponding reference file and find the Prefer section paired with that Avoid rule.
- Apply the recommended correction so the code follows the Prefer pattern.
- Preserve business logic and behavior; only change structure, naming, or patterns.
- Prefer minimal edits: one logical change per violation, no unnecessary rewrites.
- When several standards apply to the same area, prioritize: TypeScript safety → naming clarity → React architecture → testing structure.
Rules of thumb
- Strict avoid/prefer: Only treat as violations what is explicitly described as Avoid in the reference files; only apply fixes that are explicitly described as Prefer there.
- One violation, one fix: One Avoid → one corresponding Prefer; do not mix multiple rules in a single edit unless they target the same line.
- Readability and maintainability: After corrections, the code should be easier to read and maintain, without changing behavior.
Quick reference
- Lint first: Run
yarn lint or npm run lint; fix auto-fixable issues, then resolve remaining ones using references/*.md.
- Collect next: Complete the full list of Avoid violations (manual analysis) before making edits.
- Then redress: Apply each Prefer in turn, using the reference file as the source of truth.
- File/folder naming: Use react-files-structure-standards for normalizing file and folder names and structure.
1---2name: react-coding-standards3description: Enforces internal React and TypeScript coding standards using avoid/prefer rules. Use when reviewing or refactoring React/TS code, applying company standards, or when the user asks to align code with coding standards.4---56# React & TypeScript coding standards78This skill applies company coding standards expressed as **Avoid** (anti-patterns) and **Prefer** (recommended patterns) to **in-code** patterns only. For file and folder naming and structure, use [react-files-structure-standards](../react-files-structure-standards/SKILL.md).910## Reference categories1112Standards are defined in the `references/` folder. Load these files when you need the exact Avoid/Prefer rules and examples:1314| Category | File | Scope |15| ------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------- |16| **Coding patterns** | [references/common-coding-patterns.md](references/common-coding-patterns.md) | TypeScript (types, control flow, errors, enums, destructuring, etc.) |17| **Naming patterns** | [references/common-naming-patterns.md](references/common-naming-patterns.md) | In-code naming (boolean prefixes, descriptive names) |18| **React patterns** | [references/common-react-patterns.md](references/common-react-patterns.md) | Hooks, components, JSX, state, styling, fragments |19| **Unit testing** | [references/common-unit-testing.md](references/common-unit-testing.md) | Jest, React Testing Library, AAA, mocks, selectors |2021## Three-phase workflow2223When the skill is invoked on code (selected files, git staged files, branch):2425### Preliminary — Run linter26271. **Run** the project linter: `yarn lint` or `npm run lint` (use the one that matches the project).282. **Collect** every reported rule violation (rule id/name, file, line, message).293. For **each** violation:30 - If the rule is **auto-fixable** (e.g. `--fix` / `eslint --fix`), run the fix (e.g. `yarn lint --fix` or `npm run lint --fix`) and consider the violation resolved.31 - If the fix is **not automatic**, do your best to find a solution with the help of coding guidelines in `references/*.md` (coding → common-coding-patterns, naming → common-naming-patterns, React → common-react-patterns, tests → common-unit-testing) and apply the **Prefer** correction described for that rule.324. Re-run the linter after fixes; repeat until lint passes or only violations that need manual interpretation remain.3334### Phase 1 — Collect violations35361. **Analyze** the provided code against the reference files above.372. **Identify** every place where the code matches an **Avoid** pattern.383. **List** each violation in a single report with:39 - **Category** (coding / naming / React / unit testing)40 - **Rule name** (e.g. "Avoid Using `any` for Type Definitions")41 - **Location** (file and line or snippet)42 - **Short reason** (what is wrong)434. If no Avoid pattern is found, state that the code complies and stop. Otherwise proceed to Phase 2.4445### Phase 2 — Apply corrections46471. For **each** violation in the report:48 - Open the corresponding reference file and find the **Prefer** section paired with that Avoid rule.49 - Apply the recommended correction so the code follows the Prefer pattern.502. **Preserve** business logic and behavior; only change structure, naming, or patterns.513. **Prefer minimal edits**: one logical change per violation, no unnecessary rewrites.524. When several standards apply to the same area, prioritize: TypeScript safety → naming clarity → React architecture → testing structure.5354## Rules of thumb5556- **Strict avoid/prefer**: Only treat as violations what is explicitly described as Avoid in the reference files; only apply fixes that are explicitly described as Prefer there.57- **One violation, one fix**: One Avoid → one corresponding Prefer; do not mix multiple rules in a single edit unless they target the same line.58- **Readability and maintainability**: After corrections, the code should be easier to read and maintain, without changing behavior.5960## Quick reference6162- **Lint first**: Run `yarn lint` or `npm run lint`; fix auto-fixable issues, then resolve remaining ones using `references/*.md`.63- **Collect next**: Complete the full list of Avoid violations (manual analysis) before making edits.64- **Then redress**: Apply each Prefer in turn, using the reference file as the source of truth.65- **File/folder naming**: Use react-files-structure-standards for normalizing file and folder names and structure.