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.