typescript

WallysonGalvao's avatarfrom WallysonGalvao

TypeScript/JavaScript standards for type-safe, maintainable code.

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 4, 2026
[Code Review]

When & Why to Use This Skill

This Claude skill establishes a comprehensive set of TypeScript and JavaScript standards designed to ensure type-safety, maintainability, and high-quality code architecture. By enforcing strict typing rules, modern asynchronous patterns, and clean code principles, it helps development teams eliminate technical debt and maintain a consistent, professional codebase.

Use Cases

  • Automated Code Audits: Use these standards to perform deep reviews of pull requests, identifying unsafe 'any' types, improper type casting, and redundant naming conventions.
  • Refactoring Legacy Projects: Guide the transformation of complex JavaScript into flat, readable TypeScript by applying early return patterns and replacing switch-cases with hash-lists.
  • Architecture Standardization: Enforce consistent project structures, such as named exports and specific file naming conventions (kebab-case), to improve collaboration in large-scale engineering teams.
  • Type-Safe Database Integration: Implement best practices for end-to-end type safety using query-builders instead of raw SQL to prevent injection and runtime errors.
nametypescript
descriptionTypeScript/JavaScript standards for type-safe, maintainable code.

TypeScript/JavaScript Standards

Type Safety

  • Use strict TypeScript, never use any
  • Almost never use as casting
  • Aim for e2e type-safety (API to Database to UI)
  • Let the compiler infer response types whenever possible
  • Use query-builders instead of raw SQL for type-safety and injection protection

Code Structure

  • Always use named exports; avoid default exports unless required
  • Don't create index files only for exports
  • Prefer await/async over Promise().then()
  • Prefer types over interfaces
  • Leave types close to where they're used
  • Unused vars should start with _ (or don't exist at all)

Naming & Clarity

  • Don't abbreviate; use descriptive names
  • Always use early return over if-else
  • Prefer hash-lists over switch-case
  • Follow conventions: SNAKE_CAPS for constants, camelCase for functions, kebab-case for files
  • Avoid indentation levels, strive for flat code
  • Prefer string literals over string concatenation

Avoid

  • Redundant names: users not userList
  • Suffixes like Manager, Helper, Service unless essential
  • Over-long names: retryCount over maximumNumberOfTimesToRetryBeforeGivingUpOnTheRequest
  • Magic strings/numbers: extract to named constants or enums

Tooling

  • Use pre-commit hooks for linting/parsing/removing dead code