Type parameter naming conventions for personal TypeScript projects. Triggers on generic type/function creation, type-level code, or when asking about TypeScript generics.
Enforces TypeScript type parameter naming conventions with $ prefix and specific patterns.
/plugin marketplace add jasonkuhrt/claude-marketplace/plugin install typescript@jasonkuhrtThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Type aliases and interfaces: Use $ prefix
type Transform<$Input> = $Input extends string ? number : booleaninterface Container<$T> { value: $T }Functions and methods: Use $ prefix matching the value parameter name
function process<$value>(value: $value): $valuefunction map<$item, $result>(item: $item, fn: ($item) => $result): $resultType guard exception: Add _ suffix to avoid conflict with narrowed type
function isString<$value_>(value: unknown): value is $value_Generic returns exception: When type param is NOT mapped to value parameter
function create<$T>(): $TUtility internals: Parameters with ___ prefix are implementation details
type Utility<$T, ___Internal = SomeDefault<$T>> = ...Mapped types: Use specific single-letter iterators
k (key) - { [k in keyof $T]: $T[k] }i (index) - { [i in keyof $T]: Transform<$T[i]> }Infer clauses: Use __lowercase__ pattern
$T extends Array<infer __element__> ? __element__ : neverDefault type parameters to their widest possible variant:
// GOOD - Defaults to widest
type ParserContext<
$Schema = Schema | undefined,
$SDDM = any,
$TypeHooks = never
> = ...
// Usage with clean constraints
function parse<$Context extends ParserContext>(...) // Clean!
// BAD - Cluttered constraint
function parse<$Context extends ParserContext<any, any, any>>(...) // Ugly!
This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.