clean-typescript_skill

This skill helps you write clean, safe TypeScript by applying explicit types, narrowing, and unknown usage to reduce bugs.

2

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill academind/ai-config --skill clean-typescript

  • SKILL.md1.5 KB

Overview

This skill produces clean, efficient TypeScript code that emphasizes correctness and readability over cleverness. It encodes a pragmatic type philosophy: prefer explicit, composable types, avoid unsafe patterns, and keep runtime behavior predictable. The output focuses on practical refactors and suggestions you can apply directly to code.

How this skill works

The skill analyzes TypeScript code and suggests concrete changes: type alias vs interface recommendations, safer null handling, simplified function signatures, and alternatives to enums. It flags unsafe constructs like any, non-null assertions, and fragile overloads, and proposes explicit, composable replacements. It also provides small, copy-pasteable code snippets or refactors to implement the recommendations.

When to use it

  • When introducing TypeScript into an existing JavaScript codebase and you need practical typing guidance
  • During code reviews to enforce clear, maintainable type usage and API surface design
  • When designing public APIs or library types that should be stable and easy to extend
  • To replace unsafe patterns like any, frequent non-null assertions, or fragile enums
  • When you want types to document intent and reduce cognitive load for future maintainers

Best practices

  • Prefer explicit, readable types and small composable aliases over clever generics
  • Avoid any; use unknown if you must and narrow it with guards before use
  • Prefer type aliases for most cases; use interface for public, extendable shapes
  • Use explicit return types for public functions and keep signatures simple
  • Handle null/undefined through guards and control-flow narrowing; avoid !
  • Prefer union types or as const objects instead of enum for predictable runtime

Example use cases

  • Refactor a function that returns any into a well-typed result object or union
  • Replace an enum used only for static values with a union type and as const object
  • Design a new public API with explicit return types and small composable input types
  • Audit a codebase for unsafe null assertions and add appropriate guards or typed results
  • Simplify overloaded functions into clearer, single-signature APIs with discriminated unions

FAQ

Yes—prefer unknown or well-scoped types. Use any only as a last resort and document why.

When is interface better than type?

Use interface for public object shapes that consumers may extend; use type for unions, tuples, and most internal aliases.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational