with one click
typescript-best-practices
Write idiomatic TypeScript patterns for clean, maintainable code. Use when writing or refactoring TypeScript classes, functions, modules, or async logic.
Menu
Write idiomatic TypeScript patterns for clean, maintainable code. Use when writing or refactoring TypeScript classes, functions, modules, or async logic.
| name | typescript-best-practices |
| description | Write idiomatic TypeScript patterns for clean, maintainable code. Use when writing or refactoring TypeScript classes, functions, modules, or async logic. |
| metadata | {"triggers":{"files":["**/*.ts","**/*.tsx"],"keywords":["class","function","module","import","export","async","promise"]}} |
PascalCase for Classes/Types/Interfaces, camelCase for variables/functions, and UPPER_SNAKE for static constants.arrow functions for callbacks/logic; function declaration for top-level exports. Always type public API returns.Named exports ONLY to enable better refactoring/auto-imports.async/await with Promise.all() for parallel execution. Implement try-catch for error handling; type catch(e) as unknown and narrow before use. Avoid .then().catch() chains.private, protected, and public modifiers. Favor composition over inheritance and dependency injection with constructor injection and interfaces over singletons for testability.never for exhaustiveness checks in switch-cases.optional chaining (?.) and nullish coalescing (??) over manual checks.external packages → internal modules → relative imports order automatically via eslint-plugin-import. Use import type for interfaces/types to ensure better tree-shaking and zero runtime overhead.Zod or Tsoa for runtime boundary validation.noUnusedLocals.require: Use ES6 import.type or non-empty interface.any: Use unknown or specific type.jest.Mocked<T> or as unknown as T.See references/examples.md for Immutable Interfaces, Exhaustiveness Checking, Assertion Functions, DI Patterns, and Import Organization.
Standardize BRD and BRD-lite discovery for business goals, stakeholder impact, current-to-future state, and measurable value outcomes. Use when creating BRD, business case, project justification, ROI narrative, or AS-IS to TO-BE scope.
Standardize PRD discovery and drafting for product scope, user outcomes, requirement IDs, and acceptance criteria. Use when creating PRD, product requirements, feature specification, or acceptance criteria plan.
Standardize SRS and FRS specifications for technical behavior, interfaces, data contracts, quality constraints, and verification mapping. Use when writing SRS, functional specification, system behavior requirements, API/data contracts, or non-functional thresholds.
Clarify a rough product or engineering idea into a BRD-lite brief (Why) with measurable business value.
Turn an approved PRD or implementation goal into SRS/FRS technical requirements (How), architecture, contracts, and verification decisions.
Plan a feature from BRD-lite brief or clear intent into PRD (What), decisions, implementation plan, and task slices.