Enforcing TypeScript Standards
Enforces the project's core TypeScript standards including explicit typing, import organization, class member ordering, and code safety rules.
Triggers
Activate this skill when the user says or implies any of these:
- "write", "create", "implement", "add", "build" (new TypeScript code)
- "fix", "update", "change", "modify", "refactor" (existing TypeScript code)
- "review", "check", "improve", "clean up" (code quality)
- Any request involving
.ts or .tsx files
Specific triggers:
- Creating a new
.ts or .tsx file
- Modifying existing TypeScript code
- Reviewing TypeScript code for compliance
Core Standards
Type Safety
- Explicit return types: Prefer explicit return types when practical; omit when inference is obvious and adds no clarity
- Explicit member accessibility: Class members require
public, private, or protected
- Type-only imports: Use
import type for types: import type { Foo } from './foo.js'
- Sorted type constituents: Union/intersection types must be alphabetically sorted
- Only throw Error objects: Never throw strings or other primitives
- Avoid
any and type assertions: Prefer proper typing over any or as casts; use them only when truly necessary
- Type JSON fields explicitly: Use
Record<string, unknown> or specific interfaces for JSON data, never any
- Use Number() for conversion: Prefer
Number(value) over parseInt(value, 10) or parseFloat(value)
- Reuse existing types: Before defining a new interface, search for existing types that can be reused directly, extended, or derived using
Pick, Omit, Partial, or other utility types
Alternatives to Type Assertions
Before using as, try these approaches in order:
- Proper typing at the source
- Type guards (
typeof, instanceof)
- Type narrowing through control flow
- Custom type predicate functions
- Discriminated unions
ts
1// Bad
2const user = data as User;
3
4// Good
5function isUser(data: unknown): data is User {
6 return typeof data === 'object' && data !== null && 'id' in data;
7}
8if (isUser(data)) {
9 // data is now typed as User
10}
Import Organization
- Import order: built-in → external → internal → parent → sibling → index (alphabetized within groups)
- No duplicate imports: Consolidate imports from the same module
- Newline after imports: Empty line required after import block
Class Member Ordering
- Signatures (call/construct)
- Fields: private → public → protected
- Constructors: public → protected → private
- Methods: public → protected → private
Code Style
- Simplicity over cleverness: Straightforward, readable code is better than clever one-liners
- Early returns: Use guard clauses to reduce nesting; return early for edge cases
- Nullish coalescing: Prefer
?? over || for defaults (avoids false positives on 0 or '')
- Optional chaining: Use
?. for safe property access
- Match existing patterns: Follow conventions already established in the codebase
- Meaningful identifiers: Names must be descriptive (exceptions:
_, i, j, k, e, x, y)
- Function declarations: Use
function foo() not const foo = function()
- Prefer const: Use
const unless reassignment is needed
- No var: Always use
const or let
- Object shorthand: Use
{ foo } not { foo: foo }
- Template literals: Use
`Hello ${name}` not 'Hello ' + name
- Strict equality: Use
=== except for null comparisons
- One class per file: Maximum one class definition per file
- Avoid
reduce: Prefer for...of loops or other array methods for clarity
- Functions over classes: Prefer exported functions over classes with static methods (unless state is needed)
- No nested functions: Define helper functions at module level, not inside other functions
- Immutability: Create new objects/arrays instead of mutating existing ones
Naming Conventions
- Enum members: Use
PascalCase (e.g., MyValue)
- No trailing underscores: Identifiers cannot end with
_
- No redundant comments: Never comment what the code already expresses clearly
- No duplicate comments: Don't repeat information from function names, types, or nearby comments
- Meaningful only: Only add comments to explain why, not what — the code shows what it does
Boolean Expressions
- Prefer truthiness checks: Use implicit truthy/falsy checks over explicit comparisons
- Exception: Use explicit checks when distinguishing
0/'' (valid values) from null/undefined is semantically important
Testing
- Minimize mocking: Avoid mocking everything; use real implementations and data generators when available
- Test real behavior: Testing mocks provides little value — test actual code paths
- Don't be lazy: Write thorough tests that cover edge cases, not just happy paths
Error Handling
- Specific error types: Prefer specific error types over generic
Error when meaningful
- Avoid silent failures: Don't swallow errors with empty catch blocks
- Handle rejections: Always handle promise rejections
- Let errors propagate: Don't catch errors just to re-throw or log — let them bubble up to error handlers
Negative Knowledge
Avoid these antipatterns:
console.log() statements in production code
eval() or Function() constructor
- Nested ternary operators
await inside loops when Promise.all would be simpler (sequential awaits are fine when order matters or parallelism adds complexity)
- Empty interfaces
- Variable shadowing
- Functions defined inside loops
@ts-ignore without explanation (use @ts-expect-error with 10+ char description)
- Comments that restate the code:
// increment counter above counter++
- Comments that duplicate type information:
// returns a string when return type is : string
- Commented-out code (delete it; use version control)
- Verbose boolean comparisons:
arr.length > 0, str !== '', obj !== null && obj !== undefined
- Disabling linter rules via comments (fix the code instead)
- Overuse of
any type or as type assertions
- Over-mocking in tests instead of using real implementations or data generators
- Empty catch blocks that silently swallow errors
- Using
|| for defaults when ?? is more appropriate
- Deep nesting when early returns would simplify
- Catching errors just to re-throw or log them
- Nested function definitions inside other functions
- Mutating objects/arrays instead of creating new ones
- TOCTOU: Checking file/resource existence before operating (try and handle errors instead)
- Classes with only static methods (use plain functions instead)
- Duplicating existing interfaces instead of reusing or deriving with
Pick/Omit/Partial
Verification Workflow
- Analyze: Compare the code change against these TypeScript standards
- Generate/Refactor: Write or modify code to comply with all rules above
- Simplify: Review for opportunities to simplify — prefer clear, straightforward code over clever solutions
- Review naming: Verify variable and function names still make sense in context after changes
- Build: Verify types compile without errors (e.g.,
npm run build or npx tsc --noEmit)
- Lint: Run
npm run lint to confirm compliance before completing the task
Examples
ts
1// Standard
2// Retry with exponential backoff to handle transient network failures
3async function fetchWithRetry(url: string, attempts = 3): Promise<Response> {
4 for (let i = 0; i < attempts; i++) {
5 try {
6 return await fetch(url);
7 } catch {
8 await sleep(2 ** i * 100);
9 }
10 }
11 throw new Error(`Failed after ${attempts} attempts`);
12}
13
14// Non-Standard
15/**
16 * Fetches data from a URL with retry logic
17 * @param url - The URL to fetch from
18 * @param attempts - Number of attempts (default 3)
19 * @returns A Promise that resolves to a Response
20 */
21async function fetchWithRetry(url: string, attempts = 3): Promise<Response> {
22 // Loop through attempts
23 for (let i = 0; i < attempts; i++) {
24 try {
25 // Try to fetch the URL
26 return await fetch(url);
27 } catch {
28 // Wait before retrying
29 await sleep(2 ** i * 100);
30 }
31 }
32 // Throw error if all attempts fail
33 throw new Error(`Failed after ${attempts} attempts`);
34}
Boolean Expressions Examples
ts
1// Standard
2if (myArray.length) {
3}
4if (myString) {
5}
6if (myObject) {
7}
8if (!value) {
9}
10
11// Non-Standard
12if (myArray.length !== 0) {
13}
14if (myArray.length > 0) {
15}
16if (myString !== '') {
17}
18if (myObject !== null && myObject !== undefined) {
19}
20if (value === null || value === undefined) {
21}
Early Return Examples
ts
1// Standard
2function processUser(user: User | null): Result {
3 if (!user) {
4 return { error: 'No user provided' };
5 }
6 if (!user.isActive) {
7 return { error: 'User is inactive' };
8 }
9 return { data: transform(user) };
10}
11
12// Non-Standard
13function processUser(user: User | null): Result {
14 if (user) {
15 if (user.isActive) {
16 return { data: transform(user) };
17 } else {
18 return { error: 'User is inactive' };
19 }
20 } else {
21 return { error: 'No user provided' };
22 }
23}
Functions Over Classes Examples
ts
1// Standard
2export function calculateTotal(items: Item[]): number {
3 return items.reduce((sum, item) => sum + item.price, 0);
4}
5
6export function formatCurrency(amount: number): string {
7 return `$${amount.toFixed(2)}`;
8}
9
10// Non-Standard
11export class Calculator {
12 static calculateTotal(items: Item[]): number {
13 return items.reduce((sum, item) => sum + item.price, 0);
14 }
15
16 static formatCurrency(amount: number): string {
17 return `$${amount.toFixed(2)}`;
18 }
19}
No Nested Functions Examples
ts
1// Standard
2function transformItem(item: Item): TransformedItem {
3 return { id: item.id, name: item.name.toUpperCase() };
4}
5
6async function processItems(items: Item[]): Promise<TransformedItem[]> {
7 return items.map(transformItem);
8}
9
10// Non-Standard
11async function processItems(items: Item[]): Promise<TransformedItem[]> {
12 function transformItem(item: Item): TransformedItem {
13 return { id: item.id, name: item.name.toUpperCase() };
14 }
15 return items.map(transformItem);
16}
Immutability Examples
ts
1// Standard
2function addItem(items: Item[], newItem: Item): Item[] {
3 return [...items, newItem];
4}
5
6function removeItem(items: Item[], id: string): Item[] {
7 return items.filter((item) => item.id !== id);
8}
9
10function updateItem(items: Item[], id: string, updates: Partial<Item>): Item[] {
11 return items.map((item) => (item.id === id ? { ...item, ...updates } : item));
12}
13
14// Non-Standard
15function addItem(items: Item[], newItem: Item): Item[] {
16 items.push(newItem);
17 return items;
18}
19
20function removeItem(items: Item[], id: string): Item[] {
21 const index = items.findIndex((item) => item.id === id);
22 items.splice(index, 1);
23 return items;
24}
Error Propagation Examples
ts
1// Standard
2async function getUser(id: string): Promise<User> {
3 return userService.findById(id);
4}
5
6// Non-Standard
7async function getUser(id: string): Promise<User> {
8 try {
9 return await userService.findById(id);
10 } catch (error) {
11 console.error(error);
12 throw error;
13 }
14}
TOCTOU Examples
ts
1// Standard
2async function readConfig(path: string): Promise<Config> {
3 try {
4 const content = await readFile(path, 'utf-8');
5 return JSON.parse(content);
6 } catch (error) {
7 if (isNotFoundError(error)) {
8 return defaultConfig;
9 }
10 throw error;
11 }
12}
13
14// Non-Standard
15async function readConfig(path: string): Promise<Config> {
16 if (await fileExists(path)) {
17 const content = await readFile(path, 'utf-8');
18 return JSON.parse(content);
19 }
20 return defaultConfig;
21}
Type Reuse Examples
ts
1// Given an existing type
2interface User {
3 id: string;
4 email: string;
5 name: string;
6 passwordHash: string;
7 createdAt: Date;
8 updatedAt: Date;
9}
10
11// Standard - derive from existing type
12type PublicUser = Omit<User, 'passwordHash'>;
13type UserSummary = Pick<User, 'id' | 'name'>;
14type UserUpdate = Partial<Pick<User, 'email' | 'name'>>;
15
16// Non-Standard - duplicating fields that already exist
17interface PublicUser {
18 id: string;
19 email: string;
20 name: string;
21 createdAt: Date;
22 updatedAt: Date;
23}
24
25interface UserSummary {
26 id: string;
27 name: string;
28}
29
30interface UserUpdate {
31 email?: string;
32 name?: string;
33}