tighten-typescript-types

Tighten TypeScript annotations by replacing any with validated types in changed files.

1|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/cjthompson/claude-code-config --skill tighten-typescript-types-cjthompson
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tighten-typescript-types
Source: https://github.com/cjthompson/claude-code-config/tree/main/plugins/typescript-development/skills/tighten-typescript-types
Command: npx skills add https://github.com/cjthompson/claude-code-config --skill tighten-typescript-types-cjthompson

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Existing TypeScript codebases accumulate loose any types, unnecessary assertions, and imprecise declarations that hide bugs and weaken compiler checks. This Skill guides a disciplined pass that tightens types in changed files without broad refactoring or breaking public consumers. ## Core Features & Use Cases - Evidence-based tightening: Replaces boundary any with unknown, applies control-flow narrowing, discriminated unions, and satisfies instead of blanket assertions. - Scoped change control: Limits edits to changed files and directly used declarations, keeping public API compatibility verified against supported consumers. - Verification workflow: Runs focused typechecks, tests, declaration emission, and diff review to catch runtime changes, API drift, and new suppressions. - Use Case: After modifying a TypeScript module, ask the assistant to remove avoidable any types and assertions in just those files while confirming the package's external consumers still compile. ## Quick Start Tighten the TypeScript types in my changed files, replacing any with validated types and running the project's typecheck to confirm nothing breaks.

Frequently Asked Questions about tighten-typescript-types

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

FAQPage Schema
How do I remove any types from existing TypeScript code?

Replace boundary `any` with `unknown`, then validate or narrow before use with control-flow narrowing, type predicates performing real runtime checks, or discriminated unions. Annotate exported and serialization boundaries while letting inference handle honest local values.

How to tighten TypeScript types without breaking the public API?

Compile supported external consumers against the narrower declaration before changing public types. If a truthful narrower type is incompatible, tighten behind the existing boundary instead, and emit declarations to verify the contract.

When should I use unknown instead of any in TypeScript?

Use `unknown` at boundaries where data arrives without proven shape, such as dynamic legacy data or external inputs. It forces validation or narrowing before use, keeping uncertainty visible rather than hiding it behind an assertion.

When is a type assertion acceptable in TypeScript?

Use an assertion only when a runtime fact is established outside TypeScript's model, keep it at that boundary, and document the fact. Prefer `satisfies` to check values without discarding inference, and never use `@ts-ignore` to finish a pass.

Should I fix all legacy type errors in a TypeScript repo at once?

No. Limit edits to changed files and directly used declarations that block an honest local type. Report pre-existing external errors separately rather than cleaning unrelated `any`, assertions, or legacy modules.