type-safety

Enforce strict TypeScript type safety by prohibiting unsafe assertions and guiding safe alternatives.

Updated May 8, 2025
One-click install
npx skills add https://github.com/ez404-36/vroomly --skill type-safety-ez404-36
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: type-safety
Source: https://github.com/ez404-36/vroomly/tree/main/.agents/skills/type-safety
Command: npx skills add https://github.com/ez404-36/vroomly --skill type-safety-ez404-36

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enforces strict TypeScript type safety by prohibiting unsafe patterns, such as type assertions that bypass checking and blanket error silencing, and provides guidance on proper alternatives.

Core Features & Use Cases

  • Prohibits unsafe type assertions like as any, as unknown as T, and @ts-ignore.
  • Guides safe type augmentation with DTO updates, type guards, and explicit mappers.
  • Documents acceptable uses of @ts-expect-error for testing or library issues.

Quick Start

Review and apply the prohibited patterns, recommended alternatives, and acceptable-@ts-expect-error practices to enforce strict TypeScript safety across your project.

Frequently Asked Questions about type-safety

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

FAQPage Schema
How do I enforce strict TypeScript type safety when updating DTOs?

Avoid `as any` and `as unknown as T` type assertions in TypeScript by using type guards and explicit mappers. These alternatives enforce compile-time type checking instead of bypassing the compiler's validation logic.

What's the best way to handle `@ts-ignore` and `@ts-expect-error` in TypeScript?

Replace blanket `@ts-ignore` error silencing with documented `@ts-expect-error` usage. Only apply `@ts-expect-error` for specific testing or library issues, providing concrete examples to maintain strict type safety.

How do type guards prevent unsafe type assertions in TypeScript?

Type guards prevent unsafe type assertions by validating types at runtime before assignment. They ensure safe type augmentation and interface extension, replacing prohibited patterns like `as any` with verifiable checks.

When should I use explicit mappers instead of type assertions in TypeScript?

Use explicit mappers instead of type assertions when extending interfaces or updating DTOs. Mappers provide concrete examples of data transformation, maintaining compile-time safety without relying on prohibited bypasses.

Does this Skill work with projects using strict typing and runtime validation?

Yes, it applies to projects using strict typing and DTO updates. It guides developers through runtime validation, type guards, and proper mappers to maintain compile-time safety in real-world scenarios.