exhaustiveness-checking

Enforce compile-time exhaustiveness checking on TypeScript discriminated union switch statements.

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/pohlai88/afenda-xforge-v5 --skill exhaustiveness-checking-pohlai88
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: exhaustiveness-checking
Source: https://github.com/pohlai88/afenda-xforge-v5/tree/main/.agents/skills/exhaustiveness-checking
Command: npx skills add https://github.com/pohlai88/afenda-xforge-v5 --skill exhaustiveness-checking-pohlai88

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When you add a new variant to a TypeScript discriminated union, existing switch statements that forget to handle it fail silently, causing bugs that only surface at runtime. This Skill ensures missing cases become compile-time type errors instead. ## Core Features & Use Cases - Never-Type Exhaustiveness Pattern: Uses an assertUnreachable(value: never) helper in the default case so TypeScript flags any unhandled union variant. - Compile-Time Detection of Missing Cases: Adding a new variant to a union immediately produces type errors at every switch statement that needs updating. - Return Type Enforcement Alternative: Explains how explicit return types with strictNullChecks can also enforce exhaustive handling. - Use Case: You add a Line variant to a Shape union used across a canvas rendering codebase. With this pattern, every drawShape-style switch that omits the line case fails to compile, pointing you to every location needing an update. ## Quick Start Add an assertUnreachable helper to my TypeScript switch statements on union types so missing cases become compile errors.

Frequently Asked Questions about exhaustiveness-checking

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

FAQPage Schema
How do I make TypeScript switch statements exhaustive over union types?▼

Add a default case that calls an assertUnreachable(value: never): never helper. After all cases are handled, the remaining type is never; if a case is missing, the leftover variant type is not assignable to never and TypeScript raises a compile error.

How to catch missing cases when adding a new variant to a discriminated union?▼

Use the never-type exhaustiveness pattern in every switch over that union. When you add the new variant, each switch missing the case fails to compile with an error like 'Argument of type X is not assignable to parameter of type never', pointing to every location needing an update.

Can return types enforce exhaustive switch statements in TypeScript?▼

Yes, if the function has an explicit return type, every case returns, and strictNullChecks is enabled. A missing case then triggers 'Function lacks ending return statement'. This works only under those conditions, unlike the assertUnreachable approach.

Why doesn't a default case protect against new union variants?▼

A plain default case silently swallows new variants, so adding one produces no error and the new case is never handled. Using assertUnreachable in the default turns that silent omission into a compile-time type error.

When should I not use exhaustiveness checking in TypeScript?▼

Skip it when you intentionally handle only a subset of union variants, such as a function that processes common cases and deliberately ignores others. Adding assertUnreachable there would create false type errors for intentionally unhandled cases.