Applies Clean Code principles to TypeScript and React code, covering naming, function shape, error handling, data modeling, tests, and abstraction. Includes when-not-to-apply guidance and handles principle conflicts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pproenca-dot-skills-1:clean-code-ts-reactThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.
Three things set this apart from a generic clean-code copy:
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.i. Single-use code shouldn't be DRY. Some HOCs are unavoidable.Reference these guidelines when:
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 perfrefactor for mechanical refactoring workflowstdd for the TDD workflow itselfOrder reflects cognitive cost across a change's lifetime (read → understand → modify → verify → ship → maintain). Earlier stages cascade — bad names taint every read.
| Priority | Category | Impact | Prefix | Rules |
|---|---|---|---|---|
| 1 | Meaningful Names | CRITICAL | name- | 8 |
| 2 | Functions, Components & Hooks | CRITICAL | func- | 8 |
| 3 | Self-Documentation (Types & Comments) | HIGH | doc- | 5 |
| 4 | Formatting (Beyond Prettier) | HIGH | fmt- | 4 |
| 5 | Error Handling | HIGH | err- | 7 |
| 6 | Data Shape & Immutability | MEDIUM-HIGH | data- | 6 |
| 7 | Boundaries | MEDIUM-HIGH | bound- | 4 |
| 8 | Composition over Inheritance | MEDIUM-HIGH | comp- | 6 |
| 9 | Tests | MEDIUM | test- | 5 |
| 10 | Emergence & Simple Design | MEDIUM | emerge- | 4 |
| 11 | Meta: When Principles Conflict | MEDIUM | meta- | 4 |
Total: 61 rules.
name-intention-revealing — Use names that reveal intentname-avoid-disinformation — Avoid misleading namesname-meaningful-distinctions — Make meaningful distinctionsname-component-pascal-case — Components are PascalCase noun phrasesname-hook-use-prefix — Hooks are useX verb phrasesname-handler-convention — Event handlers use onX / handleXname-boolean-predicate — Boolean variables use is/has/canname-types-pascal-case — Types and interfaces are PascalCasefunc-small — Keep functions, components & hooks smallfunc-one-thing — Do one thingfunc-abstraction-level — One level of abstraction per functionfunc-minimize-arguments — Prefer object parameters over long listsfunc-no-side-effects — Avoid hidden side effects (especially in render)func-command-query-separation — Separate commands from queriesfunc-dry — DRY — until concepts divergefunc-custom-hook-extract — Extract custom hooks for reusable stateful logicdoc-types-over-comments — Prefer types over commentsdoc-satisfies-narrows-with-check — Use satisfies for inferred-but-checked valuesdoc-jsdoc-public-api — JSDoc for public APIs and non-obvious side effectsdoc-avoid-redundant-comments — Avoid redundant commentsdoc-delete-commented-out-code — Delete commented-out codefmt-vertical-density — Keep related code close, unrelated farfmt-newspaper-order — Order files top-down like a newspaperfmt-team-rules-over-preference — Team conventions over personal preferencefmt-imports-grouped — Group imports by sourceerr-early-return — Use early returns to flatten error pathserr-result-vs-throw — Choose throw vs Result deliberatelyerr-narrow-unknown — Always narrow unknown in catch blockserr-error-boundaries — Use error boundaries for render-time failureserr-suspense-for-loading — Use Suspense for loading stateserr-no-swallow — Never swallow errors silentlyerr-null-vs-undefined — Pick null OR undefined per domaindata-discriminated-unions-over-flags — Discriminated unions over boolean flagsdata-readonly-by-default — Mark read-only data readonlydata-branded-types — Brand types for domain invariantsdata-dto-vs-domain — Separate DTOs from domain typesdata-demeter-prop-drilling — Prop drilling often smells like Demeterdata-structural-typing-pitfalls — Beware structural typing aliasingbound-wrap-third-party-hooks — Wrap third-party hooks in custom hooksbound-learning-tests — Write learning tests for third-party behaviorbound-isolate-framework — Isolate framework-specific code at the edgesbound-type-assertions-at-edges — Type assertions belong only at boundariescomp-children-over-props — Compose with children over configuration propscomp-small-components — Keep components small and cohesivecomp-avoid-hoc-stacks — Avoid higher-order component stackscomp-context-only-when-needed — Context for DI, not prop avoidancecomp-render-props-vs-hooks — Prefer hooks over render props for logic reusecomp-separate-construction-from-use — Separate setup from renderingtest-behavior-not-implementation — Test behavior, not implementationtest-mock-at-boundaries — Mock only at true boundariestest-first-principles — Apply FIRST principlestest-one-concept — One concept (not one assert) per testtest-clean-as-production — Test code deserves production-grade careemerge-four-rules — Apply the four rules of simple design in orderemerge-yagni-types — Avoid premature type genericsemerge-premature-abstraction — Resist premature abstractionemerge-reveal-intent — Maximize expressiveness — code as communicationThis is the signature category — explicit guidance on when one clean-code principle yields to another.
meta-dry-vs-srp — Bend DRY when concepts drift apartmeta-small-vs-deep — Small functions lose to deep modules when indirection > comprehensionmeta-types-vs-ergonomics — Type safety loses to ergonomics at stable boundariesmeta-tests-as-spec-vs-doc — Pick tests-as-spec or tests-as-documentation per fileFor 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.
| File | Description |
|---|---|
| references/_sections.md | Category definitions and ordering |
| assets/templates/_template.md | Template for adding new rules |
| metadata.json | Version and reference information |
.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.npx claudepluginhub joshuarweaver/cascade-code-general-misc-1 --plugin pproenca-dot-skills-1Guides writing and modifying React components with modern patterns, TypeScript, hooks for state and effects, component composition, and pitfalls to avoid. Triggers on .jsx/.tsx files or React planning.
Guides React component design, hooks, composition, state management, performance optimization, and error handling with TypeScript.
Guides developers on modern React patterns including hooks, composition, performance optimization, and TypeScript best practices.