Typecheck Skill

Use this skill when handling TypeScript type errors or type-safety decisions.

Core Rule: Never Use as any

CRITICAL: NEVER add as any type assertions to fix TypeScript errors. If you cannot figure out a proper type-safe solution, tell the user that you can't figure it out rather than using as any.

Rationale

Using as any:

• •Disables type checking, removing TypeScript's safety guarantees
• •Hides actual type problems that should be addressed properly
• •Makes the codebase more error-prone and harder to maintain
• •Is a code smell that indicates deeper type design issues

What to Do Instead

1. •Investigate the root cause: Understand why TypeScript can't infer the correct type
2. •Use proper type narrowing: Use type guards, conditional types, or better type constraints
3. •Fix the type definitions: Update interfaces, generics, or type utilities if needed
4. •Ask for help: If you truly cannot solve it type-safely, inform the user that you cannot figure out a proper solution

When Encountering Type Errors

• •

  ✅ DO: Analyze the error message carefully to understand the type mismatch

• •

  ✅ DO: Check if helper types or type utilities can resolve it

• •

  ✅ DO: Consider if the API or type definitions need improvement

• •

  ✅ DO: Tell the user if you cannot find a type-safe solution

• •

  ❌ DON'T: Add as any to silence the error

• •

  ❌ DON'T: Use as unknown as T as a workaround (same problem as as any)

• •

  ❌ DON'T: Use @ts-ignore or @ts-expect-error to suppress type errors

Examples of What NOT to Do

// ❌ WRONG - Never do this
const rows = yield* db
  .select()
  .from(pgTable as any)
  .where(eq(pgTable.id, id));

// ❌ WRONG - This is also bad
const value = someValue as unknown as ExpectedType;

When You Cannot Solve It Type-Safely

If after careful analysis you cannot find a type-safe solution, you should:

1. •Explain what the type error is
2. •Describe what you tried
3. •State clearly that you cannot figure out a proper type-safe solution
4. •Suggest potential approaches (better type definitions, helper utilities, etc.)

Example response:

"I'm encountering a TypeScript error where pgTable from models[modelName] cannot be properly narrowed for use in Drizzle's .from() method. The complex generic types from InferAggregateModels are preventing proper type inference. I've tried [X, Y, Z approaches] but cannot find a type-safe solution. This likely requires improving the type definitions for the table mapping or using a different pattern for accessing tables. I cannot figure out a proper type-safe fix for this."