playbooks

home / skills / omer-metin / skills-for-antigravity / typescript-strict

typescript-strict skill

/skills/typescript-strict

This skill helps you enforce TypeScript strict mode patterns and type safety by guiding usage of unknown generics and guards.

npx playbooks add skill omer-metin/skills-for-antigravity --skill typescript-strict

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
1.6 KB
---
name: typescript-strict
description: Expert knowledge for TypeScript strict mode patterns and type safetyUse when "typescript, type error, strict mode, generics, type inference, any type, type assertion, typescript, types, strict, generics, type-safety, inference" mentioned. 
---

# Typescript Strict

## Identity

You are a TypeScript strict mode expert. You understand how to leverage
TypeScript's type system for maximum safety while keeping code readable.
You know when to use type assertions, generics, and type guards.

Your core principles:
1. Enable strict mode - all flags, no exceptions
2. Avoid 'any' - use 'unknown' when type is truly unknown
3. Let inference work - don't annotate when TypeScript knows
4. Use type guards - narrow types safely
5. Generics for reusability - constrain appropriately


## Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

* **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here.
* **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
* **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively.

**Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Overview

This skill provides expert guidance on using TypeScript strict mode to maximize type safety while keeping code maintainable. It codifies strict-mode patterns, common failure modes, and objective validation rules so you can make changes with confidence. Use it to diagnose type errors, recommend fixes, and validate code against strict constraints.

How this skill works

The skill inspects TypeScript code for strict-mode violations and risky patterns such as implicit any, unsafe assertions, and weakened generics. It explains why each issue is dangerous, offers targeted fixes (type guards, constrained generics, replacing any with unknown), and validates suggested changes against strict-mode constraints. Recommendations prioritize inference and minimal annotations, and highlight where explicit types are required for safety.

When to use it

  • Enabling or enforcing TypeScript strict mode across a codebase
  • Diagnosing type errors that appear only under strict compilation flags
  • Refactoring code that currently uses any or unsafe type assertions
  • Designing reusable APIs with generics and safe constraints
  • Writing runtime type guards and narrowing strategies for complex unions

Best practices

  • Turn on all strict flags and treat them as the baseline for new code
  • Prefer unknown over any for truly unknown values and narrow with guards
  • Rely on type inference where possible; annotate only where inference is insufficient
  • Use constrained generics to express intent and prevent misuse
  • Write small, composition-friendly type guards rather than broad casts

Example use cases

  • Convert a legacy module that returns any into a type-safe API using unknown and validation guards
  • Resolve a persistent type error caused by implicit any after enabling noImplicitAny
  • Design a generic utility type that preserves literal types while preventing unwanted widening
  • Replace repeated type assertions with a single validated constructor or factory
  • Implement runtime validation for user input and narrow types before business logic

FAQ

When should I use unknown instead of any?

Use unknown whenever the runtime type is uncertain; require explicit narrowing before use. only use any when you accept loss of type safety.

Are type assertions ever safe?

Assertions are safe only when you can guarantee the runtime shape through prior checks or constructors. Prefer narrowing functions or validated factories instead of blind casts.

How do I keep generics safe but ergonomic?

Constrain generics with appropriate extends clauses, provide sensible defaults, and prefer smaller generic interfaces that compose rather than one monolithic generic type.