typesafe

Identify unsafe type assumptions and mismatched guarantees in code paths.

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/nmnmcc/skills --skill typesafe
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typesafe
Source: https://github.com/nmnmcc/skills/tree/main/skills/typesafe
Command: npx skills add https://github.com/nmnmcc/skills --skill typesafe

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you design, write, review, and debug code so that meanings, runtime values, contracts, data forms, and allowed operations stay aligned from the first source to the final use. It prevents code from relying on stronger guarantees than the evidence actually supports.

Core Features & Use Cases

  • Type and contract design: Model values, states, failures, and invariants honestly instead of hiding risk behind overly broad types.
  • Boundary safety: Validate data at inputs, across services, through storage, and at version changes so guarantees survive the full path.
  • Implementation and review support: Apply type-safe reasoning to refactors, API design, integrations, migrations, compiler settings, runtime checks, schemas, and generated code.
  • Use case: When a feature reads user data from an API and passes it into business logic, this Skill helps ensure the input is checked, narrowed, propagated safely, and consumed with the right guarantee.

Quick Start

Use the typesafe skill to inspect my code path, identify every value, state, boundary, and proof, and tell me where the current guarantees are too weak or unsupported.

Frequently Asked Questions about typesafe

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

FAQPage Schema
How do I validate API data at boundaries to prevent unsafe type assumptions?

You validate API data at boundaries by applying runtime contracts and schemas to input values, ensuring that type guarantees survive intact from source to final use. This process checks, narrows, and propagates data safely.

What is the best way to keep type contracts honest during a major refactoring?

Keeping type contracts honest during refactoring requires aligning compiler facts with runtime checks, ensuring that meanings, values, and allowed operations do not rely on unsupported or overly broad type assumptions.

How do I design API types that don't hide runtime failures behind broad guarantees?

Designing safe API types involves modeling values, states, failures, and invariants explicitly, using runtime validation to align data forms and allowed operations rather than hiding risk behind overly broad types.

Does this approach to type safety work for data migration and version changes?

Yes, boundary checks and type contracts apply directly to data migration and version changes, validating data through storage and version transitions so guarantees survive the full integration path.

Why does my code fail when consuming API data even though the compiler says the types match?

Code fails because compiler facts alone do not guarantee runtime values, requiring boundary checks and schemas to validate data forms, align meaning, and narrow types before entering business logic.