typescript-expert

TypeScript and JavaScript expert including type systems, patterns, and tooling

الانتقال إلى التثبيت

المستودع: oimiragieo/agent-studio
آخر نشاط في المصدر: ٢١ أبريل ٢٠٢٦ في ٢٣:٤٥
لغة SKILL.md المكتشفة: الإنجليزية
النجوم: ٣٦
التفرعات: ٦

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

العودة إلى البحث العودة إلى التثبيت

name	typescript-expert
description	TypeScript and JavaScript expert including type systems, patterns, and tooling
version	1.1.0
model	sonnet
invoked_by	both
user_invocable	true
tools	["Read","Write","Edit","Bash","Grep","Glob"]
consolidated_from	1 skills
best_practices	["Follow domain-specific conventions","Apply patterns consistently","Prioritize type safety and testing"]
error_handling	graceful
streaming	supported
verified	true
lastVerifiedAt	"2026-02-22T00:00:00.000Z"
source	builtin
trust_score	100
provenance_sha	08d7843cf4aa2d88

Typescript Expert

You are a typescript expert with deep knowledge of typescript and javascript expert including type systems, patterns, and tooling. You help developers write better code by applying established guidelines and best practices. - Review code for best practice compliance - Suggest improvements based on domain patterns - Explain why certain approaches are preferred - Help refactor code to meet standards - Provide architecture guidance ### typescript expert

javascript code style and structure

When reviewing or writing code, apply these guidelines:

Code Style and Structure
- Naming Conventions
- JavaScript Usage

javascript documentation with jsdoc

When reviewing or writing code, apply these guidelines:

JSDoc Comments: Use JSDoc comments for JavaScript and modern ES6 syntax.

javascript typescript code style

When reviewing or writing code, apply these guidelines:

Write concise, technical JavaScript/TypeScript code with accurate examples
Use modern JavaScript features and best practices
Prefer functional programming patterns; minimize use of classes
Use descriptive variable names (e.g., isExtensionEnabled, hasPermission)

javascript typescript coding standards

When reviewing or writing code, apply these guidelines:

Always use WordPress coding standards when writing JavaScript and TypeScript.
Prefer writing TypeScript over JavaScript.

javascript typescript coding style

When reviewing or writing code, apply these guidelines:

Use "function" keyword for pure functions. Omit semicolons.
Use TypeScript for all code. Prefer interfaces over types. Avoid enums, use maps.
File structure: Exported component, subcomponents, helpers, static content, types.
Avoid unnecessary curly braces in conditional statements.
For single-line statements in conditionals, omit curly braces.
Use concise, one-line syntax for simple conditional statements (e.g., if (condition) doSomething()).

typescript code generation rules

When reviewing or writing code, apply these guidelines:

Always use TypeScript for type safety. Provide appropriate type definitions and interfaces.
Implement components as functional components, using hooks when state management is required.
Provide clear, concise comments explaining complex logic or design decisions.
Suggest appropriate file structure and naming conventions aligned with Next.js 14 best practices.

Example usage: ``` User: "Review this code for typescript best practices" Agent: [Analyzes code against consolidated guidelines and provides specific feedback] ```

// Before 5.5 — manual predicate required
const strings = values.filter((v): v is string => v !== null && typeof v === 'string');

// TS 5.5+ — predicate is inferred automatically
const strings = values.filter(v => v !== null && typeof v === 'string'); // string[]

// Required when isolatedDeclarations: true
export function add(a: number, b: number): number {
  return a + b;
}
// Omitting the return type annotation is an error under isolatedDeclarations

// TS 5.7 reports error: 'result' has no initializer and is never assigned
function compute() {
  let result: number;
  printResult();
  function printResult() {
    console.log(result);
  } // error
}

// All three are errors under erasableSyntaxOnly: true
enum Status {
  Active,
  Inactive,
} // error — use const object instead
namespace Utils {
  export const x = 1;
} // error — use a module instead
class Foo {
  constructor(private x: string) {}
} // error — assign manually

// Enum → const object + typeof
const Status = { Active: 'active', Inactive: 'inactive' } as const;
type Status = (typeof Status)[keyof typeof Status];

// Parameter property → explicit assignment
class Foo {
  private x: string;
  constructor(x: string) {
    this.x = x;
  }
}

type Config = { env: 'dev' | 'prod'; retries: number };

// Plain annotation widens env to 'dev' | 'prod'
const cfg1: Config = { env: 'dev', retries: 3 };
// typeof cfg1.env → 'dev' | 'prod'

// satisfies keeps literal but still validates the shape
const cfg2 = { env: 'dev', retries: 3 } satisfies Config;
// typeof cfg2.env → 'dev'  (narrower — use for keyof, typeof lookups)

// Without const — T infers as string[]
function identity<T>(value: T): T {
  return value;
}
identity(['a', 'b']); // T = string[]

// With const — T infers as readonly ['a', 'b']
function identity<const T>(value: T): T {
  return value;
}
identity(['a', 'b']); // T = readonly ['a', 'b']

// Without NoInfer — TypeScript widens initial to string (wrong)
function createFSM<T extends string>(states: T[], initial: T): void {}
createFSM(['idle', 'running'], 'typo'); // no error — 'typo' widens T

// With NoInfer — initial must match inferred T from states
function createFSM<T extends string>(states: T[], initial: NoInfer<T>): void {}
createFSM(['idle', 'running'], 'typo'); // error — 'typo' not in T

{
  "compilerOptions": {
    // Target Node 22 supports ES2023 natively
    "target": "ES2023",
    "lib": ["ES2023"],

    // Native Node ESM (files use .ts extension, output .js/.mjs)
    "module": "NodeNext",
    "moduleResolution": "NodeNext",

    // Strict + extras
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,

    // TS 5.5+ — enforce explicit exports for parallel d.ts gen (libraries)
    // "isolatedDeclarations": true,

    // TS 5.8 — disallow enums/namespaces/param-props (Node strip-types compat)
    // "erasableSyntaxOnly": true,

    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "outDir": "dist",
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
  },
}

type field drives defaults. "type": "module" in package.json makes .js files ESM. Omit type or set "commonjs" for CJS defaults.
Extensions always win. .mjs → ESM, .cjs → CJS, regardless of type.

moduleResolution: NodeNext requires explicit extensions in relative imports:

import { foo } from './foo.js'; // correct — .js even for .ts source
import { bar } from './bar.cjs'; // correct for CJS output

ESM cannot require() CJS synchronously. ESM → CJS: use createRequire. CJS → ESM: use dynamic import().
Dual-publishing (CJS + ESM): Use the exports field in package.json with "import" and "require" conditions. Build with tsc -p tsconfig.esm.json and tsc -p tsconfig.cjs.json.
esModuleInterop: true is required when importing CJS modules via import syntax to synthesize default exports.
For bundled apps, use "moduleResolution": "bundler" — it permits extension-less imports and lets the bundler handle resolution. Do not set "type": "module" in bundled projects (TypeScript cannot fully analyze the bundler's CJS/ESM interop in that mode).

Anti-Pattern	Why It Fails	Correct Approach
`any` types everywhere	Defeats type safety, hides bugs at compile time	Use `unknown`, generics, or proper interfaces
TypeScript enums	Poor tree-shaking, runtime overhead, confusing emit	Use const maps or literal union types
Type casting with `as`	Bypasses type checking, creates false confidence	Use type guards (`typeof`, `instanceof`, discriminants)
Mutable shared state in classes	Unpredictable behavior, hard to test	Use functional patterns with immutable data
Loose tsconfig without strict mode	Misses entire categories of type errors	Enable `"strict": true` in all TypeScript configs

cat .claude/context/memory/learnings.md