typescript-type-safety-review

Reviews TypeScript code and diffs for unsound types, unsafe casts, and trust-boundary leaks.

1|1|Updated Apr 8, 2026
One-click install
npx skills add https://github.com/GonkaGate/opencode-setup --skill typescript-type-safety-review-gonkagate
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: typescript-type-safety-review
Source: https://github.com/GonkaGate/opencode-setup/tree/main/.agents/skills/typescript-type-safety-review
Command: npx skills add https://github.com/GonkaGate/opencode-setup --skill typescript-type-safety-review-gonkagate

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? TypeScript code often looks type-safe while hiding real soundness gaps: unsafe as casts, any leakage, partial validation treated as full trust, utility types that collapse unions, and exported types that overpromise. This Skill performs a findings-first review that separates genuine unsoundness from missing proof, residual risk, and style-only concerns. ## Core Features & Use Cases - Soundness-Focused Review: Identifies the exact safety claim code makes, traces where compiler proof ends or runtime truth disagrees, and classifies each point as a finding, missing proof, or residual risk. - Structured Inspection Workflow: Provides checklists covering compiler strictness settings, boundary trust sweeps, escape hatches, helper composition, and public API surfaces. - Finding Calibration: Challenges the strongest nearby non-finding story before keeping a point, and recommends the smallest safe fix rather than broad rewrites. - Use Case: When reviewing a TypeScript PR that adds a parser and new exported types, use this Skill to verify whether unknown truly stops at the validation boundary and whether the exported signatures promise more than the runtime guarantees. ## Quick Start Ask the AI to review your TypeScript diff or PR for type-safety issues such as unsafe casts, any leakage, partial validation, or exported types that overpromise guarantees.

Frequently Asked Questions about typescript-type-safety-review

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

FAQPage Schema
How do I review TypeScript code for type safety issues?▼

Start by naming the exact safety claim the code makes, such as a trust boundary or impossible-state guarantee, then trace where compiler proof ends or runtime behavior disagrees. Classify each concern as a finding, missing proof, or residual risk before recommending the smallest safe fix.

How to detect unsafe type assertions and any leakage in TypeScript?▼

Scan for `as` casts, `as unknown as` chains, non-null `!` operators, and `any` flowing from JSON.parse or third-party SDKs into typed variables. The key question is whether each assertion expresses already-earned knowledge or creates trust from nowhere.

Does TypeScript strict mode guarantee type safety at runtime?▼

No. TypeScript types erase at runtime, so `strict` mode alone does not validate data. Optionality, indexed access, and catch-variable safety depend on specific flags like exactOptionalPropertyTypes and noUncheckedIndexedAccess, and runtime boundaries still need explicit parsing.

Why does Omit break discriminated unions in TypeScript?▼

Omit is not distributive over unions, so applying it to a union can collapse variants and erase the discriminant the runtime relies on. Union-safe helpers such as DistributedOmit preserve the per-variant separation that plain utility types destroy.

When should a type concern be reported as missing proof instead of a finding?▼

Use missing proof when the verdict depends on unseen tsconfig settings, a parser or guard defined elsewhere, or emitted declaration files you have not inspected. A finding requires directly observable evidence that the code's safety claim is broken.