typescript-best-practices

Replace unsafe TypeScript types and assertions with safer typed alternatives.

1|Updated Feb 16, 2026
One-click install
npx skills add https://github.com/hayatosc/dotfiles --skill typescript-best-practices-hayatosc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typescript-best-practices
Source: https://github.com/hayatosc/dotfiles/tree/main/home/dot_agents/skills/typescript-best-practices
Command: npx skills add https://github.com/hayatosc/dotfiles --skill typescript-best-practices-hayatosc

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Large or evolving TypeScript codebases often accumulate unsafe types, pervasive use of any, and fragile assertions that hide bugs and reduce developer confidence. This Skill helps developers implement and enforce precise types, replace unsafe assertions with safe narrowing or branded types, and align runtime guards with compile-time guarantees.

Core Features & Use Cases

  • Type-first refactors: Replace any and unsafe as with generics, unknown-and-narrowing, discriminated unions, or branded types for safer public APIs.
  • Configuration hygiene: Incrementally tighten tsconfig and typescript-eslint settings when it materially improves safety and remains reviewable.
  • Verification & tests: Run the repository's typecheck, add type-level tests for exported utilities, and re-run lint/tests as part of verification.
  • Use Case: Convert a repo using permissive types into an ESM-first, strictly-typed codebase that passes tsgo --noEmit or tsc --noEmit without weakening existing APIs.

Quick Start

Audit the repository for any and unsafe as usages, design explicit types for affected APIs, update tsconfig and ESLint incrementally where safe, and run the project's typecheck until it passes.

Frequently Asked Questions about typescript-best-practices

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I remove `any` and unsafe `as` assertions from a TypeScript codebase?

To remove `any` and unsafe `as` assertions from TypeScript code, replace them with generics, `unknown` combined with narrowing, discriminated unions, or branded types to enforce safer public APIs and restore compile-time type safety.

What is the best way to tighten tsconfig and eslint rules incrementally for type safety?

The best way to tighten tsconfig and eslint rules incrementally is to update compiler and typescript-eslint settings in reviewable steps while running the repository typecheck, ensuring strict configurations materially improve safety without breaking existing APIs.

How does replacing `any` with `unknown` and narrowing work in TypeScript?

Replacing `any` with `unknown` and narrowing works by forcing compile-time checks before accessing values, using type guards or discriminated unions to safely resolve runtime data structures while preventing silent type errors.

Can I convert a permissive TypeScript project to ESM-first without weakening existing exported APIs?

Yes, you can convert a permissive TypeScript project to an ESM-first, strictly-typed codebase by designing explicit types for affected APIs and verifying with `tsgo --noEmit` or `tsc --noEmit` to ensure exported APIs remain backward compatible.

Do I need to add type-level tests when refactoring exported TypeScript utilities?

Yes, you need to add type-level tests when refactoring exported TypeScript utilities to verify that changes affecting exported APIs maintain compile-time guarantees and pass the repository's typecheck and lint verification processes.