review-typescript

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: Review TypeScript

技能：审查TypeScript

Purpose

目的

Review TypeScript and JavaScript code for language and runtime conventions only. Do not define scope (diff vs codebase) or perform security/architecture analysis; those are handled by scope and cognitive skills. Emit a findings list in the standard format for 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.

审查TypeScript和JavaScript代码的语言与运行时规范。不要定义审查范围（差异对比 vs 整个代码库）或执行安全/架构分析；这些由范围技能和认知技能处理。以标准格式输出问题发现清单用于汇总。重点关注类型安全性与类型系统使用、异步模式与Promise处理、错误处理、模块设计、运行时正确性、API与接口设计，以及性能和内存考量。

Core Objective

核心目标

Primary Goal: Produce a TypeScript/JavaScript language findings list 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 must be met):

✅ TypeScript/JavaScript language-only scope: Only TypeScript and JavaScript language and runtime conventions are reviewed; no scope selection, security, or architecture analysis performed
✅ All seven language dimensions covered: Type safety, async patterns, error handling, module design, runtime correctness, API/interface design, and performance/memory are assessed where relevant
✅ Findings format compliant: Each finding includes Location, Category (
```
language-typescript
```
), Severity, Title, Description, and optional Suggestion
✅ File/line references: All findings reference specific file:line or symbol name
✅ Non-TS/JS code excluded: Non-TypeScript/JavaScript files are not analyzed for TS/JS-specific rules unless explicitly in scope

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

主要目标：针对给定的代码范围，生成涵盖类型安全性、异步模式、错误处理、模块设计、运行时正确性、API/接口设计以及性能/内存的TypeScript/JavaScript语言问题发现清单。

成功标准（必须全部满足）：

✅ 仅TypeScript/JavaScript语言范围：仅审查TypeScript和JavaScript的语言与运行时规范；不进行范围选择、安全或架构分析
✅ 覆盖全部七个语言维度：评估所有相关的类型安全性、异步模式、错误处理、模块设计、运行时正确性、API/接口设计以及性能/内存维度
✅ 符合问题发现格式：每个问题发现包含位置、分类（
```
language-typescript
```
）、严重程度、标题、描述，以及可选的建议
✅ 文件/行号引用：所有问题发现均引用具体的文件:行号或符号名称
✅ 排除非TS/JS代码：除非明确在审查范围内，否则不针对TypeScript/JavaScript特定规则分析非TypeScript/JavaScript文件

验收测试：输出是否包含以TypeScript/JavaScript为重点的问题发现清单，带有文件/行号引用，覆盖所有相关语言维度，且未执行安全、架构或范围分析？

Scope Boundaries

范围边界

This skill handles:

Type safety and type system usage (strict mode, proper typing,
```
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 does NOT handle:

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: When all TypeScript/JavaScript findings are emitted, hand off to

review-code

for aggregation. For injection risks or secrets in code, note them and suggest

review-security

本技能负责：

类型安全性与类型系统使用（严格模式、正确类型标注、避免使用
```
any
```
、可辨识联合、类型守卫、泛型）
异步模式（async/await、Promise处理、错误传播、竞态条件、未处理的拒绝）
错误处理（try/catch模式、自定义错误类型、错误边界、全面的错误处理）
模块设计（ESM vs CJS、桶导出、循环依赖、摇树优化、副作用）
运行时正确性（null/undefined处理、相等性检查、隐式类型转换陷阱、原型污染）
API与接口设计（函数签名、重载、品牌类型、readonly正确性）
性能与内存（闭包内存泄漏、事件监听器清理、WeakRef/WeakMap使用、打包体积影响）

本技能不负责：

范围选择——范围由调用方提供
安全分析（注入、密钥、XSS）——使用
```
review-security
```
技能
架构分析——使用
```
review-architecture
```
技能
框架规范（Vue、React、Angular）——使用框架专属技能（如
```
review-vue
```
）
完整的协同审查——使用
```
review-code
```
技能

交接节点：当所有TypeScript/JavaScript问题发现输出完成后，交接给

review-code

进行汇总。若发现代码中存在注入风险或密钥，需标注并建议使用

review-security

。

Use Cases

使用场景

Orchestrated review: Used as the language step when review-code runs scope → language → framework → library → cognitive for TypeScript/JavaScript projects.
TypeScript-only review: When the user wants only TypeScript/JavaScript language conventions checked.
Pre-PR language checklist: Ensure type safety, async correctness, and module design are sound before merging.

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

协同审查：在review-code针对TypeScript/JavaScript项目执行范围→语言→框架→库→认知的审查流程时，作为语言环节使用。
仅TypeScript审查：当用户仅希望检查TypeScript/JavaScript语言规范时使用。
PR前语言检查清单：在合并前确保类型安全性、异步正确性和模块设计无问题。

使用时机：当待审查的代码为TypeScript或JavaScript，且任务包含语言质量检查时。范围由调用方或用户确定。

Behavior

行为规范

Scope of this skill

技能范围

Analyze: TypeScript and JavaScript language and runtime conventions in the given code scope (files or diff provided by the caller). Do not decide scope; accept the code range as input.
Do not: Perform scope selection, security review, or architecture review; do not review non-TS/JS files for TS/JS rules unless in scope.

分析：在给定的代码范围（调用方提供的文件或差异）内分析TypeScript和JavaScript的语言与运行时规范。不要自行决定范围；接受输入的代码范围。
禁止：执行范围选择、安全审查或架构审查；除非在范围内，否则不要针对TypeScript/JavaScript规则分析非TS/JS文件。

Review checklist (TypeScript/JavaScript language only)

审查清单（仅TypeScript/JavaScript语言）

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 (
```
as
```
) where narrowing is possible.
Async patterns: Ensure proper async/await usage and Promise chaining; verify error propagation through async boundaries; detect race conditions and unhandled Promise rejections; check for dangling Promises (missing
```
await
```
); validate concurrent patterns (
```
Promise.all
```
,
```
Promise.allSettled
```
).
Error handling: Verify try/catch placement and specificity; prefer custom error types over raw strings/Error; ensure exhaustive error handling (switch/if-else covers all cases); check that errors carry sufficient context; validate cleanup in finally blocks.
Module design: Prefer ESM (
```
import
```
/
```
export
```
) over CJS (
```
require
```
/
```
module.exports
```
); audit barrel exports for tree-shaking impact; detect circular dependencies; check for unintended side effects at module scope; validate consistent module resolution.
Runtime correctness: Check for null/undefined handling (optional chaining, nullish coalescing); enforce strict equality (
```
===
```
/
```
!==
```
); detect coercion traps (implicit type conversions); check for prototype pollution risks; validate iterator/generator correctness.
API and interface design: Review function signatures for clarity and consistency; validate overloads are ordered correctly and are non-ambiguous; check branded/opaque types for domain safety; enforce
```
readonly
```
where mutation is unintended; verify index signatures and mapped types.
Performance and memory: Detect closure-based memory leaks; verify event listener and subscription cleanup; check WeakRef/WeakMap usage for cache patterns; assess bundle size impact of imports; identify hot-path inefficiencies (e.g. unnecessary allocations in loops).

类型安全性与类型系统使用：强制启用
```
strict
```
模式；优先使用显式类型而非
```
any
```
；使用可辨识联合进行状态建模；应用类型守卫与类型收窄；利用泛型实现复用且不丢失类型信息；在可进行类型收窄的情况下避免使用类型断言（
```
as
```
）。
异步模式：确保正确使用async/await和Promise链式调用；验证异步边界的错误传播；检测竞态条件和未处理的Promise拒绝；检查悬空Promise（缺少
```
await
```
）；验证并发模式（
```
Promise.all
```
、
```
Promise.allSettled
```
）。
错误处理：验证try/catch的位置与针对性；优先使用自定义错误类型而非原始字符串/Error；确保全面的错误处理（switch/if-else覆盖所有情况）；检查错误是否携带足够的上下文；验证finally块中的清理操作。
模块设计：优先使用ESM（
```
import
```
/
```
export
```
）而非CJS（
```
require
```
/
```
module.exports
```
）；审计桶导出对摇树优化的影响；检测循环依赖；检查模块级别的意外副作用；验证一致的模块解析方式。
运行时正确性：检查null/undefined处理（可选链、空值合并）；强制使用严格相等（
```
===
```
/
```
!==
```
）；检测隐式类型转换陷阱；检查原型污染风险；验证迭代器/生成器的正确性。
API与接口设计：审查函数签名的清晰度与一致性；验证重载的顺序正确且无歧义；检查品牌/不透明类型以保障领域安全；在不希望发生突变的场景下强制使用
```
readonly
```
；验证索引签名与映射类型。
性能与内存：检测基于闭包的内存泄漏；验证事件监听器与订阅的清理；检查WeakRef/WeakMap在缓存模式中的使用；评估导入对打包体积的影响；识别热点路径中的低效问题（如循环中的不必要分配）。

Tone and references

语气与引用

Professional and technical: Reference specific locations (file:line or symbol name). Emit findings with Location, Category, Severity, Title, Description, Suggestion.

专业且技术化：引用具体位置（文件:行号或符号名称）。输出包含位置、分类、严重程度、标题、描述、建议的问题发现。

Input & Output

输入与输出

Input

输入

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

代码范围：包含TypeScript或JavaScript代码的文件或目录（或差异）（.ts、.tsx、.js、.jsx、.mts、.mjs、.cts、.cjs）。由用户或范围技能提供。

Output

输出

Emit zero or more findings in the format defined in Appendix: Output contract.
Category for this skill is language-typescript.

输出零个或多个问题发现，格式遵循附录：输出约定。
本技能的分类为language-typescript。

Restrictions

限制条件

Hard Boundaries

硬性边界

Do not perform scope selection, security, or architecture review. Stay within TypeScript/JavaScript language and runtime conventions.
Do not give conclusions without specific locations or actionable suggestions.
Do not review non-TS/JS code for TS/JS-specific rules unless explicitly in scope.

禁止执行范围选择、安全或架构审查。仅关注TypeScript/JavaScript语言与运行时规范。
禁止在没有具体位置或可操作建议的情况下给出结论。
禁止针对TypeScript/JavaScript特定规则分析非TS/JS文件，除非明确在范围内。

Skill Boundaries

技能边界

Do NOT do these (other skills handle them):

Do NOT select or define the code scope — 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 respective framework skill

When to stop and hand off:

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

禁止执行以下操作（由其他技能负责）：

禁止选择或定义代码范围——范围由调用方或
```
review-code
```
确定
禁止执行安全分析（注入、密钥）——使用
```
review-security
```
禁止执行架构分析——使用
```
review-architecture
```
禁止审查框架特定规范（Vue、React、Angular）——使用对应的框架技能

停止并交接的时机：

当所有TypeScript/JavaScript问题发现输出完成后，交接给
```
review-code
```
进行汇总
当发现注入风险或密钥时，标注并建议使用
```
review-security
```
当用户需要完整审查（范围+语言+认知）时，引导至
```
review-code
```

Self-Check

自我检查

Core Success Criteria

核心成功标准

TypeScript/JavaScript language-only scope: Only TypeScript and JavaScript language and runtime conventions are reviewed; no scope selection, security, or architecture analysis performed
All seven language dimensions covered: Type safety, async patterns, error handling, module design, runtime correctness, API/interface design, and performance/memory are assessed where relevant
Findings format compliant: Each finding includes Location, Category (
```
language-typescript
```
), Severity, Title, Description, and optional Suggestion
File/line references: All findings reference specific file:line or symbol name
Non-TS/JS code excluded: Non-TypeScript/JavaScript files are not analyzed for TS/JS-specific rules unless explicitly in scope

仅TypeScript/JavaScript语言范围：仅审查TypeScript和JavaScript的语言与运行时规范；未执行范围选择、安全或架构分析
覆盖全部七个语言维度：评估所有相关的类型安全性、异步模式、错误处理、模块设计、运行时正确性、API/接口设计以及性能/内存维度
符合问题发现格式：每个问题发现包含位置、分类（
```
language-typescript
```
）、严重程度、标题、描述，以及可选的建议
文件/行号引用：所有问题发现均引用具体的文件:行号或符号名称
排除非TS/JS代码：除非明确在审查范围内，否则未针对TypeScript/JavaScript特定规则分析非TypeScript/JavaScript文件

Process Quality Checks

流程质量检查

Was only the TypeScript/JavaScript language dimension reviewed (no scope/security/architecture)?
Are type safety, async patterns, error handling, module design, runtime correctness, API design, and performance covered where relevant?
Is each finding emitted with Location, Category=language-typescript, Severity, Title, Description, and optional Suggestion?
Are issues referenced with file:line or symbol name?

是否仅审查了TypeScript/JavaScript语言维度（未涉及范围/安全/架构）？
是否覆盖了所有相关的类型安全性、异步模式、错误处理、模块设计、运行时正确性、API设计和性能？
每个问题发现是否都包含位置、分类=language-typescript、严重程度、标题、描述和可选建议？
问题是否都引用了文件:行号或符号名称？

Acceptance Test

验收测试

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

输出是否包含以TypeScript/JavaScript为重点的问题发现清单，带有文件/行号引用，覆盖所有相关语言维度，且未执行安全、架构或范围分析？

Examples

示例

Example 1: Unsafe use of

any

示例1：不安全的

any

使用

Input: Module with function parameters typed as
```
any
```
and no runtime validation.
Expected: Emit a finding (major) for unsafe
```
any
```
usage; suggest replacing with a proper type, generic, or
```
unknown
```
with type narrowing. Category = language-typescript.

输入：函数参数类型标注为
```
any
```
且无运行时验证的模块。
预期输出：输出一个关于不安全
```
any
```
使用的问题发现（严重程度：主要）；建议替换为合适的类型、泛型或带类型收窄的
```
unknown
```
。分类 = language-typescript。

Example 2: Missing

await

on async call

示例2：异步调用缺少

await

Input: Async function that calls another async function without
```
await
```
, discarding the Promise.
Expected: Emit a finding (critical/major) for dangling Promise; suggest adding
```
await
```
or explicitly handling the returned Promise. Category = language-typescript.

输入：调用另一个异步函数但未使用
```
await
```
、丢弃Promise的异步函数。
预期输出：输出一个关于悬空Promise的问题发现（严重程度：关键/主要）；建议添加
```
await
```
或显式处理返回的Promise。分类 = language-typescript。

Edge case: Mixed ESM and CJS in the same project

边缘案例：同一项目中混合使用ESM和CJS

Input: Project with some files using
```
import
```
/
```
export
```
and others using
```
require
```
/
```
module.exports
```
.
Expected: Emit findings for inconsistent module system usage; suggest migrating to a single module system (preferably ESM) or documenting the reason for mixed usage. Category = language-typescript.

输入：部分文件使用
```
import
```
/
```
export
```
、其他文件使用
```
require
```
/
```
module.exports
```
的项目。
预期输出：输出关于模块系统使用不一致的问题发现；建议迁移至单一模块系统（优先ESM）或记录混合使用的原因。分类 = language-typescript。

Appendix: Output contract

附录：输出约定

Each finding MUST follow the standard findings format:

Element	Requirement
Location	`path/to/file.ts` or `.js` (optional line or range).
Category	`language-typescript` .
Severity	`critical` \| `major` \| `minor` \| `suggestion` .
Title	Short one-line summary.
Description	1–3 sentences.
Suggestion	Concrete fix or improvement (optional).

Example:

markdown

- **Location**: `src/services/userService.ts:42`
- **Category**: language-typescript
- **Severity**: major
- **Title**: Unsafe `any` type in function parameter
- **Description**: Parameter `data` is typed as `any`, bypassing all type checking and allowing silent runtime errors.
- **Suggestion**: Replace `any` with `unknown` and add type narrowing, or define a specific interface for the expected shape.

每个问题发现必须遵循标准的问题发现格式：

元素	要求
位置	`path/to/file.ts` 或 `.js` （可选行号或范围）。
分类	`language-typescript` 。
严重程度	`critical` \| `major` \| `minor` \| `suggestion` 。
标题	简短的单行摘要。
描述	1–3句话。
建议	具体的修复或改进方案（可选）。

示例：