review-typescript

Skill: Review TypeScript

Purpose

Review only TypeScript and JavaScript code's language and runtime conventions. Do not define scope (diff vs codebase) or perform security/architecture analysis; these are handled by scope and cognitive skills. Emit in standard formatresult listfor aggregation. Focus on type safety and type system usage, async patterns and Promise handling, error handling, module design, runtime correctness, API and interface design, and performance and memory considerations.

Core Objective

Primary objective: Generate a list of TypeScript/JavaScript language findings covering type safety, async patterns, error handling, module design, runtime correctness, API/interface design, and performance/memory for the given code scope.

Success criteria(all requirements must be met):

✅ TypeScript/JavaScript language scope only: Review only TypeScript and JavaScript language and runtime conventions; no scope selection, security, or architecture analysis performed
✅ Covers all seven language dimensions: Type safety, async patterns, error handling, module design, runtime correctness, API/interface design, and performance/memory are evaluated (if relevant)
✅ Result format compatible: Each result includes location, category (语言打字稿), severity, title, description, and optional recommendation
✅ File/line references: All findings reference a specific file:line or symbol name
✅ Exclude non-TS/JS code: TS/JS-specific rules are not analyzed for non-TypeScript/JavaScript files unless explicitly in scope

AcceptanceTest: Does the output contain a TypeScript/JavaScript-centric result list with file/line references covering all relevant language dimensions, without performing security, architecture, or scope analysis?

Scope boundaries (Scope boundaries)

This skill is responsible for：

Type safety and type system usage (strict mode, correct types, 'any' avoidance, discriminated unions, type guards, generics)
Async patterns (async/await, promise handling, error propagation, race conditions, unhandled rejections)
Error handling (try/catch patterns, custom error types, error boundaries, exhaustive error handling)
Module design (ESM vs CJS, barrel exports, circular dependencies, tree-shaking, side effects)
Runtime correctness (null/undefined handling, equality checks, coercion traps, prototype pollution)
API and interface design (function signatures, overloads, branded types, readonly correctness)
Performance and memory (closure leaks, event listener cleanup, WeakRef/WeakMap usage, bundle size impact)

This skill is not responsible for：

Scope selection — scope is provided by the caller
Security analysis (injection, secrets, XSS) — use 'review-security'
Architecture analysis — use 'review-architecture'
Framework conventions (Vue, React, Angular) — use framework-specific skills (e.g. 'review-vue')
Full orchestrated review — use 'review-code'

Handoff point: After all TypeScript/JavaScript results are emitted, hand them off to "orchestrate-code-review" for aggregation. For injection risks or secrets in the code, note them and recommend "review-security".

Use cases

Orchestrated review: used as the language step when orchestrate-code-review runs the scope → language → framework → library → cognitive of a TypeScript/JavaScript project.
TypeScript-only review: when the user only wants to check TypeScript/JavaScript language conventions.
Pre-PR language checklist: ensure type safety, async correctness, and sound module design before merging.

When to use: when the code under review is TypeScript or JavaScript and the task includes language quality. The scope is determined by the caller or the user.

Behavior

Scope of this skill

Analyze：the TypeScript and JavaScript language and runtime conventions in the given code scope(files or diffs provided by the caller). Does not decide the scope; accepts the code scope as input.
Do not: perform scope selection, security review, or architecture review; do not check TS/JS rules for non-TS/JS files unless they are in scope.

Review checklist (TypeScript/JavaScript language only)

Type safety and type system usage: enforce "strict" mode; prefer explicit types over "any"; use discriminated unions for state modeling; apply type guards and narrowing; leverage generics for reuse without sacrificing type information; avoid type assertions where narrowing is possible (as）。
Async patterns: ensure correct async/await usage and Promise chains; verify error propagation across async boundaries; detect race conditions and unhandled Promise rejections; check for dangling Promises (missing await); verify concurrency patterns ("Promise.all", "Promise.allSettled").
Error handling: verify the placement and specificity of try/catch; prefer custom error types over raw strings/errors; ensure exhaustive error handling (switch/if-else covers all cases); check whether errors carry sufficient context; verify cleanup in finally blocks.
Module design: prefer ESM (import/export) over CJS (require/module.exports); audit the impact of barrel exports; detect circular dependencies; check for unintended side effects at module scope; verify consistent module resolution.
Runtime correctness: check null/undefined handling (optional chaining, nullish coalescing); enforce strict equality (===/!==); detect coercion traps (implicit type conversion); check for prototype pollution risks; verify iterator/generator correctness.
API and interface design: check the clarity and consistency of function signatures; verify that overloads are ordered correctly and are unambiguous; check branded/opaque types for domain safety; enforce "readonly" where unexpected mutation could occur; verify index signatures and mapped types.
Performance and memory: Detect closure-based memory leaks; verify event listener and subscription cleanup; check WeakRef/WeakMap cache pattern usage; evaluate the impact of import bundle size; identify inefficiencies in hot paths (e.g., unnecessary allocations in loops).

Tone and References

Professional and technical: Reference specific locations (file:line or symbol name). Emit findings containing location, category, severity, title, description, recommendation.

Input & Output

Input

Code scope: Files or directories (or diffs) containing TypeScript or JavaScript code (.ts, .tsx, .js, .jsx, .mts, .mjs, .cts, .cjs). Provided by the user or a scoped skill.

Output

In the format defined inAppendix: Output Contract, emit zero or morefindings。
The category of this skill islanguage TypeScript。

Limits

Hard Boundaries

Do notperform scope selection, security, or architecture review. Follow TypeScript/JavaScript language and runtime conventions.
Do notgive conclusions without specific locations or actionable recommendations.
Do notreview TS/JS-specific rules for non-TS/JS code unless explicitly in scope.

Skill Boundaries

Do not do these(other skills can handle them):

Do not select or define the code scope - the scope is determined by the caller or "review code"
Do not perform security analysis (injection, secrets) - use "review-security"
Do not perform architecture analysis - use "review-architecture"
Do not review framework-specific conventions (Vue, React, Angular) - use the corresponding framework skill

When to stop and hand off：

After all TypeScript/JavaScript findings are emitted, hand them off to "orchestrate-code-review" for aggregation
When injection risks or secrets are found, note them and recommend "review security"
When the user needs a comprehensive review (scope + language + cognitive), redirect to "review code"

Self-Check

Core Success Criteria

TypeScript/JavaScript language scope only: Review only TypeScript and JavaScript language and runtime conventions; scope selection, security, or architecture analysis was not performed
Covers all seven language dimensions: Type safety, async patterns, error handling, module design, runtime correctness, API/interface design, and performance/memory (if relevant) are evaluated
Conforms to the findings format: Each finding includes location, category (语言打字稿), severity, title, description, and optional recommendation
File/line references: All findings reference a specific file:line or symbol name
Exclude non-TS/JS code: TS/JS-specific rules for non-TypeScript/JavaScript files are not analyzed unless explicitly in scope

Process Quality Check

Were only TypeScript/JavaScript language dimensions reviewed (no scope/security/architecture)?
Does it cover relevant type safety, async patterns, error handling, module design, runtime correctness, API design, and performance?
Does each finding include location, category=language TypeScript, severity, title, description, and optional suggestion?
Are issues referenced by file:line or symbol name?

Acceptance test

Does the output include a TypeScript/JavaScript-focused list of results with file/line references covering all relevant language dimensions, without performing security, architecture, or scope analysis?

Example (Example)

Example 1: Unsafe use of `any`

Input: a module where function parameter types are "any" and there is no runtime validation.
Expected: emit one finding for unsafe "any" use (major); suggest replacing it with an appropriate type, generics, or type-narrowed "unknown". Category = language TypeScript.

Example 2: Missing `await`

Input: an async function calls another async function without using "await", discarding the Promise.
Expected: emit one finding for a dangling Promise (critical/major); suggest adding await or explicitly handling the returned Promise. Category = language TypeScript.

Edge case: Mixing ESM and CJS in the same project

Input: a project using "import"/"export" for some files and "require"/"module.exports" for other files.
Expected: emit a finding for inconsistent module system usage; suggest migrating to a single module system (preferably ESM) or documenting the reason for the mixed usage. Category = language TypeScript.