typescript-clean-code
Use when writing, fixing, editing, reviewing, or refactoring any TypeScript code. Enforces Robert Martin's complete Clean Code catalog—naming, functions, comments, DRY, and boundary conditions.
Works with
Agent Skills format with YAML frontmatter. Claude Code reads it as-is.
--- name: "typescript-clean-code" description: "Use when writing, fixing, editing, reviewing, or refactoring any TypeScript code. Enforces Robert Martin's complete Clean Code catalog—naming, functions, comments, DRY, and boundary conditions." license: "MIT" --- # Clean TypeScript: Complete Reference Enforces all Clean Code principles from Robert C. Martin's Chapter 17, adapted for TypeScript. ## Comments (C1-C5) - C1: No metadata in comments (use Git) - C2: Delete obsolete comments immediately - C3: No redundant comments - C4: Write comments well if you must - C5: Never commit commented-out code ## Environment (E1-E2) - E1: One command to build (`npm run build`) - E2: One command to test (`npm test`) ## Functions (F1-F4) - F1: Maximum 3 arguments (use parameter objects/interfaces for more) - F2: No output arguments (return values) - F3: No flag arguments (split functions) - F4: Delete dead functions ## General (G1-G36) - G1: One language per file - G2: Implement expected behavior - G3: Handle boundary conditions - G4: Don't override safeties - G5: DRY - no duplication - G6: Consistent abstraction levels - G7: Base classes don't know children - G8: Minimize public interface - G9: Delete dead code - G10: Variables near usage - G11: Be consistent - G12: Remove clutter - G13: No artificial coupling - G14: No feature envy - G15: No selector arguments - G16: No obscured intent - G17: Code where expected - G18: Prefer instance methods - G19: Use explanatory variables - G20: Function names say what they do - G21: Understand the algorithm - G22: Make dependencies physical - G23: Prefer polymorphism to if/else - G24: Follow conventions (TypeScript style guide + ESLint/Prettier) - G25: Named constants, not magic numbers - G26: Be precise - G27: Structure over convention - G28: Encapsulate conditionals - G29: Avoid negative conditionals - G30: Functions do one thing - G31: Make temporal coupling explicit - G32: Don't be arbitrary - G33: Encapsulate boundary conditions - G34: One abstraction level per function - G35: Config at high levels - G36: Law of Demeter (no train wrecks) ## TypeScript-Specific (TS1-TS3) These adapt the Java-specific rules (J1-J3) to TypeScript conventions: - TS1: Keep imports explicit and stable; avoid namespace-style overuse and implicit dependencies - TS2: Use enums or literal union types, not magic constants - TS3: Type public interfaces explicitly and avoid `any` in boundaries ## Names (N1-N7) - N1: Choose descriptive names - N2: Right abstraction level - N3: Use standard nomenclature - N4: Unambiguous names - N5: Name length matches scope - N6: No encodings - N7: Names describe side effects ## Tests (T1-T9) - T1: Test everything that could break - T2: Use coverage tools - T3: Don't skip trivial tests - T4: Ignored test = ambiguity question - T5: Test boundary conditions - T6: Exhaustively test near bugs - T7: Look for patterns in failures - T8: Check coverage when debugging - T9: Tests must be fast (< 100ms each) ## Quick Reference Table | Category | Rule | One-Liner | |----------|------|-----------| | **Comments** | C1 | No metadata (use Git) | | | C3 | No redundant comments | | | C5 | No commented-out code | | **Functions** | F1 | Max 3 arguments | | | F3 | No flag arguments | | | F4 | Delete dead functions | | **General** | G5 | DRY—no duplication | | | G9 | Delete dead code | | | G16 | No obscured intent | | | G23 | Polymorphism over if/else | | | G25 | Named constants, not magic numbers | | | G30 | Functions do one thing | | | G36 | Law of Demeter (one dot) | | **Names** | N1 | Descriptive names | | | N5 | Name length matches scope | | **Tests** | T5 | Test boundary conditions | | | T9 | Tests must be fast | ## Anti-Patterns (Don't → Do) | ❌ Don't | ✅ Do | |----------|-------| | Comment every line | Delete obvious comments | | Helper for one-liner | Inline the code | | `import * as utils` everywhere | Named imports for explicit dependencies | | `any` in public API | Specific types or `unknown` + narrowing | | Magic number `86400` | `const SECONDS_PER_DAY = 86400` | | `process(data, true)` | `processVerbose(data)` | | Deep nesting | Guard clauses, early returns | | `obj.a.b.c.value` | `obj.getValue()` | | 100+ line function | Split by responsibility | ## AI Behavior When reviewing code, identify violations by rule number (e.g., "G5 violation: duplicated logic"). When fixing or editing code, report what was fixed (e.g., "Fixed: extracted magic number to `SECONDS_PER_DAY` (G25)").
More Refactoring skills
vercel-react-best-practices
vercel-labs/agent-skills
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
analyze-project
lllllllama/rigorpilot-skills
Rigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrypoints, review configs and insertion points, or flag suspicious implementation patterns without modifying code or running heavy jobs. Do not use for active command execution, broad refactoring, speculative code adaptation, or automatic bug fixing.
request-refactor-plan
mattpocock/skills
Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.

