type-test-authoring

Write compile-time type tests for public TypeScript APIs.

1|1|Updated May 3, 2026
One-click install
npx skills add https://github.com/matt-riley/agent-skills --skill type-test-authoring
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: type-test-authoring
Source: https://github.com/matt-riley/agent-skills/tree/main/skills/type-test-authoring
Command: npx skills add https://github.com/matt-riley/agent-skills --skill type-test-authoring

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Write compile-time type tests to protect public TypeScript APIs, inference behavior, and negative cases.

Core Features & Use Cases

  • Provides a framework for asserting type contracts and regression guards using existing type-test tools.
  • Supports both inline assertions and fixture-based patterns to cover public surfaces.
  • Helps prevent regressions by capturing positive and negative cases near exported types.

Quick Start

Bootstrap by adding a minimal positive assertion and a negative assertion next to the exported types and run the repository's type-check command.

Frequently Asked Questions about type-test-authoring

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

FAQPage Schema
How do I write compile-time type tests for a TypeScript API?

Compile-time type tests use inline assertions or fixtures with tools like tsd or dtslint to verify public TypeScript API surfaces, guarding type inference contracts and regression edge cases without runtime side effects.

Why should I use compile-time type testing instead of runtime tests for TypeScript libraries?

Compile-time type testing captures positive and negative type inference cases near exported types, preventing regressions in public API surfaces without runtime overhead, ensuring type contracts remain intact across library updates.

Do I need an existing type-test tool in my repository to enforce TypeScript API contracts?

Yes, enforcing TypeScript API contracts requires an existing type-test tool in the repository, such as tsd, dtslint, expectTypeOf, or @ts-expect-error fixtures, to validate compile-time type inference.

What's the best way to prevent type inference regressions in a TypeScript library?

The best way to prevent type inference regressions is to write compile-time type tests using fixture-based patterns or inline assertions that capture positive and negative cases next to your exported TypeScript types.

Can I use @ts-expect-error fixtures to test negative type cases in TypeScript?

Yes, you can use @ts-expect-error fixtures alongside inline assertions to test negative type cases in TypeScript, capturing regression edge cases and guarding public API surfaces during compile-time checks.