typescript-strict

Enforce strict TypeScript practices in the Tetris codebase.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/sakataka/tetris-game2 --skill typescript-strict
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typescript-strict
Source: https://github.com/sakataka/tetris-game2/tree/main/.claude/skills/typescript-strict
Command: npx skills add https://github.com/sakataka/tetris-game2 --skill typescript-strict

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enforces strict TypeScript practices to reduce type errors and improve safety in the game logic.

Core Features & Use Cases

  • No any types; use unknown and guards
  • No type assertions; use narrowing
  • No non-null assertions (!); use optional chaining
  • Result<T,E> pattern for game logic
  • Exhaustive type checking

Quick Start

Apply strict typing in new game logic functions and refactor existing code to replace any, as demonstrated in the guide.

Frequently Asked Questions about typescript-strict

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

FAQPage Schema
How do I eliminate type errors by avoiding `any` types in TypeScript?

Replace `any` with `unknown` and use type guards to narrow types safely. This prevents implicit type coercion and forces explicit type checking, catching errors at compile time rather than runtime.

What's the best way to handle null and undefined safely in TypeScript?

Use optional chaining and nullish coalescing instead of non-null assertions (`!`). This approach makes null-handling explicit in your code and prevents runtime crashes from accessing properties on null or undefined values.

How do I structure error handling in game logic without type assertions?

Adopt the Result<T, E> pattern to represent success or failure explicitly. This eliminates type assertions and non-null assertions, making error paths type-safe and traceable throughout your game logic.

Why should I use exhaustive type checking instead of type assertions?

Exhaustive checking with type guards ensures all possible cases are handled at compile time. This catches logic gaps early, reduces runtime errors, and makes refactoring safer when types change.

Can I apply strict TypeScript practices incrementally to an existing codebase?

Yes. Start by applying strict typing to new functions and refactor existing code gradually, replacing `any` types and assertions as you modify sections. This allows adoption without rewriting the entire codebase at once.