clean-code-ts-react

v2026.09.24

Use when writing, reviewing, or refactoring TypeScript or React code for craftsmanship — naming, function and component shape, error handling, data modeling, tests, and abstraction. Translates Robert C. Martin's Clean Code principles into modern TS+React idioms (TS 5.x, React 19), with first-class "When NOT to apply" guidance and a Meta category for principle conflicts (DRY vs SRP, small functions vs deep modules, type safety vs ergonomics). Triggers on code review, refactoring for clarity, naming, function/component design, "is this clean?", "make this more readable", "right abstraction?" — even when the user doesn't say "clean code". Does NOT cover React-specific APIs (RSC, hooks API surface) — use the `react` skill. Does NOT cover TS compiler perf or tsconfig — use the `typescript` skill.

GitHub
Install command
npx skhub add pproenca/clean-code-ts-react
Markdown
SKILL.md

Robert C. Martin (Uncle Bob) TypeScript 5.x + React 19 Best Practices

Craftsmanship principles from Robert C. Martin's Clean Code (2008), re-expressed for modern TypeScript and React. Contains 61 rules across 11 categories, prioritized by cognitive cost across a code change's lifetime. Examples use TS 5.x and React 19 idioms — but the rules are about timeless principles, not specific APIs.

What Makes This Skill Different

Three things set this apart from a generic clean-code copy:

  1. Modern idioms as vehicle. Examples use TS 5.x (satisfies, branded types, discriminated unions, const type parameters) and React 19 (function components, hooks, use(), Server Components where relevant). But the rule is always the principle, never the syntax.
  2. "When NOT to apply" is first-class. Every rule has 2-3 concrete scenarios where the principle should bend — not generic disclaimers, real situations. Loop counters can be i. Single-use code shouldn't be DRY. Some HOCs are unavoidable.
  3. Meta category for principle conflicts. Category 11 names the most common tensions explicitly — DRY vs Single Responsibility, small functions vs deep modules (Ousterhout), type precision vs ergonomic APIs, tests as spec vs documentation. The mark of seniority is knowing which to bend.

When to Apply

Reference these guidelines when:

  • Writing new TypeScript or React code and wanting craftsmanship feedback
  • Reviewing a pull request for clarity, naming, or abstraction
  • Refactoring existing code for readability or maintainability
  • Designing function, hook, or component APIs
  • Deciding whether to extract, abstract, or duplicate
  • Resolving a tension between two clean-code rules (see Category 11)

Skip this skill and use:

  • react for React 19 API patterns (concurrent rendering, Server Components, ref-as-prop, useActionState, <Context>-as-provider)
  • typescript for compiler performance, tsconfig tuning, type-system perf
  • refactor for mechanical refactoring workflows
  • tdd for the TDD workflow itself

Rule Categories by Priority

Order reflects cognitive cost across a change's lifetime (read → understand → modify → verify → ship → maintain). Earlier stages cascade — bad names taint every read.

PriorityCategoryImpactPrefixRules
1Meaningful NamesCRITICALname-8
2Functions, Components & HooksCRITICALfunc-8
3Self-Documentation (Types & Comments)HIGHdoc-5
4Formatting (Beyond Prettier)HIGHfmt-4
5Error HandlingHIGHerr-7
6Data Shape & ImmutabilityMEDIUM-HIGHdata-6
7BoundariesMEDIUM-HIGHbound-4
8Composition over InheritanceMEDIUM-HIGHcomp-6
9TestsMEDIUMtest-5
10Emergence & Simple DesignMEDIUMemerge-4
11Meta: When Principles ConflictMEDIUMmeta-4

Total: 61 rules.

Quick Reference

1. Meaningful Names (CRITICAL)

2. Functions, Components & Hooks (CRITICAL)

3. Self-Documentation: Types & Comments (HIGH)

4. Formatting Beyond Prettier (HIGH)

5. Error Handling (HIGH)

6. Data Shape & Immutability (MEDIUM-HIGH)

7. Boundaries (MEDIUM-HIGH)

8. Composition over Inheritance (MEDIUM-HIGH)

9. Tests (MEDIUM)

10. Emergence & Simple Design (MEDIUM)

11. Meta: When Principles Conflict (MEDIUM)

This is the signature category — explicit guidance on when one clean-code principle yields to another.

How to Use

For an ad-hoc question ("is this naming OK?", "should I extract this?"), jump straight to the relevant rule file via the Quick Reference above.

For a code review or refactor, scan the categories in priority order — names and function shape first (highest cascade), then errors and data shape, then composition and tests. The category-major sweep is more efficient than file-major.

When two principles seem to disagree, read the corresponding Meta rule (Category 11). Pick the principle that wins, and document the call.

Reference Files

FileDescription
references/_sections.mdCategory definitions and ordering
assets/templates/_template.mdTemplate for adding new rules
metadata.jsonVersion and reference information

Related Skills

  • .experimental/clean-code — Original language-agnostic clean code (Java examples). This skill is the TS+React sibling.
  • .curated/react — React 19-specific patterns (Server Components, concurrent rendering, ref-as-prop).
  • .curated/typescript — TS compiler performance and tsconfig tuning.
  • .curated/refactor — Mechanical refactoring workflows.
  • .curated/tdd — The TDD workflow itself.
Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

MIT

Source path

skills/.experimental/clean-code-ts-react

Default branch

master

Latest commit

cf93c57

Tree SHA

afbb575