skills.rest
pohlai88
pohlai88COMMUNITY
Explore all skills by this author →
GitHub

hide-unsafe-assertions

Hide TypeScript type assertions inside well-typed function implementations.

Updated Sep 5, 2026
Search Tags:#code quality#type safety#typescript#refactoring#any type#type assertions#function signatures
One-click install
npx skills add https://github.com/pohlai88/afenda-xforge-v5 --skill hide-unsafe-assertions-pohlai88
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: hide-unsafe-assertions
Source: https://github.com/pohlai88/afenda-xforge-v5/tree/main/.agents/skills/hide-unsafe-assertions
Command: npx skills add https://github.com/pohlai88/afenda-xforge-v5 --skill hide-unsafe-assertions-pohlai88

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? TypeScript code often needs type assertions or any internally, but exposing them in function signatures forces every caller to handle unsafe types. This Skill teaches how to keep public type signatures clean while containing necessary assertions inside implementations. ## Core Features & Use Cases - Contained Assertions: Move as casts and any usage into function bodies so callers receive precise return types like Promise<MountainPeak> instead of unknown. - Validation and Documentation Patterns: Add runtime checks and explanatory comments that justify why each hidden assertion is safe. - Use Case: When wrapping a loosely typed API client, write fetchPeak(id): Promise<MountainPeak> with the assertion hidden inside, so callers never write as MountainPeak at every call site. ## Quick Start Ask the AI to refactor a TypeScript function so its type assertions are hidden inside the implementation while the public signature stays fully typed.

Frequently Asked Questions about hide-unsafe-assertions

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

FAQPage Schema
How do I hide type assertions in TypeScript functions?▼

Place the assertion inside the function body and declare a precise return type in the signature. For example, return `checkedFetchJSON(url) as Promise<MountainPeak>` inside a function typed as `Promise<MountainPeak>`, so callers never cast.

When is it acceptable to use any in TypeScript?▼

Using any is acceptable when confined to a function implementation with a clean public signature. Narrow the assertion to the smallest expression, document why it is valid, and add runtime validation plus tests.

Should I change a return type to unknown to avoid assertions?▼

No. Returning unknown pushes the assertion burden to every caller. Keep the signature precise and hide a single validated assertion inside the implementation instead.

How do function overloads help hide unsafe implementations?▼

Overloads let the implementation signature return unknown while the public overload signature exposes a precise type like Promise<MountainPeak>. Callers see only the clean overload, and the unsafe implementation stays hidden.

What are the risks of casting a whole object with as any?▼

Casting an entire object disables type checking on all its properties, hiding real errors. Instead, apply the assertion only to the specific property or expression that the compiler cannot verify.

Related Skills

Explore More Software Engineering Skills→
d-oitd-oit

typescript-guardian

Enforce strict TypeScript compiler options and replace any types with unknown or specific types.

Community
Advanced
prabaljainnprabaljainn

migrate-to-shoehorn

Migrates TypeScript test files from `as` type assertions to @total-typescript/shoehorn partial mocks.

Community
Basic
pnewsampnewsam
1

typescript-types

Enforce TypeScript type safety using tsc strict mode and no-unsafe ESLint rules.

Community
Intermediate
awfixers-stuffawfixers-stuff

typescript-best-practices

Enforce type-safe patterns in TypeScript and JavaScript code reviews.

Official
Intermediate