菜单
Use when writing, fixing, editing, or refactoring TypeScript code, especially weak types, unclear names, duplicated logic, oversized functions, stale comments, boundary gaps, error handling, data modeling, async flows, module structure, or brittle tests.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when checking code for functional correctness, backwards compatibility, logic errors, security vulnerabilities, performance issues, or missing test coverage — not style.
Use when reviewing code, pull requests, branches, diffs, or changed files for quality, correctness, security, performance, and style issues.
Use when writing, fixing, editing, or refactoring TypeScript, Python, React, or CSS code. Not for PR or diff reviews — use clean-code-reviewer for those.
Use when writing, fixing, or editing comments or documentation in any language, especially commented-out code, stale docs, metadata comments, TODO banners, redundant comments, or unclear comment value.
Use when naming or renaming identifiers in any language, especially cryptic names, ambiguous parameters, type or scope encodings, misleading side effects, or requests for clearer names.
Use when writing, fixing, or editing code in any language with duplicated logic, magic values, unclear one-liners, mixed responsibilities, clutter, arbitrary code, or inconsistent abstraction levels.
| name | clean-typescript |
| description | Use when writing, fixing, editing, or refactoring TypeScript code, especially weak types, unclear names, duplicated logic, oversized functions, stale comments, boundary gaps, error handling, data modeling, async flows, module structure, or brittle tests. |
Use this as the TypeScript entry point. It routes broad review work to focused skills and summarizes the rules most likely to affect design. Prefer clear runtime behavior and precise public types over cleverness or type-system escape hatches.
Error objects with useful contextunknown and narrow before reading propertiesunknown plus narrowing instead of any at boundariesunknown until validatednull failures| Work | Use |
|---|---|
| Broad duplication, intent, magic values, dead code | clean-general |
| Comments and TSDoc | clean-general-comments |
| Functions, arguments, mutation, flags | clean-typescript-functions |
| Modules, classes, file order, cohesion, coupling, dependency construction, over-abstraction | clean-typescript-modules |
| Promises, retries, timeouts, cancellation, race conditions | clean-typescript-async |
| Error handling and fallbacks | clean-typescript-error-handling |
| APIs, JSON, config, storage, SDKs | clean-typescript-boundaries |
| DTOs, domain models, classes, unions | clean-typescript-objects-data |
| Names | clean-general-names |
| Tests | clean-typescript-tests |
A single code region often matches multiple rules. Without precedence, the same issue gets reported 2-4 times under different IDs and the review becomes noise.
Core rule: If two findings have the same Fix, collapse to one finding under the most specific rule and cite the others in parentheses. If two findings have different Fixes, keep them separate even when they touch the same line.
Specificity order — the more specific rule wins:
unknown (TS3)" or "obscured intent (G2)".arg.field = value inside one async function is F2. A3 is reserved for genuine cross-call races: a module-level mutable value read and written across awaits by concurrent callers.MAX_RETRIES = 3 declared and used in the loop, but the literal 3 also appearing in "Failed after 3 retries", is G1 (two representations of the same fact); G3 is implied.Rules that look similar but stay independent — report both:
cause/message context).Finding format under precedence:
[S1] Severity: Fix
Category: Style (M5; also touches M8, G1)
Location: src/userRepoWrapper.ts:1-9
Issue: ...
Fix: ...
The lead rule is the primary citation. Supporting rules go in parentheses only when they describe the same region with the same fix. If a related rule has an independent fix, give it its own finding.
Cross-reference collapse: If a finding's Issue or Fix text contains a phrase like "see also [Sx]", "resolved by fixing [Sx]", "subsumed by [Sx]", "if [Sx] is accepted this resolves", or "applies only if [Sx] is rejected" — that is direct evidence the two findings are not independent. Collapse the dependent finding into the referenced one and add the dependent rule in parentheses on the surviving finding. The presence of a cross-reference is itself the signal; do not write the cross-reference and then keep both findings.
Red flags — you are about to over-report:
If you catch yourself doing any of these, collapse to one finding under the more specific rule.
satisfies when validating object literals without widening useful literal types.as assertions unless crossing a boundary that cannot express the type; narrow first when possible.When reviewing code, use this skill for the first-pass sweep: identify violations by rule number (e.g., "G1 violation: duplicated logic").
When writing detailed fixes or explanations for a specific category, read the corresponding sub-skill file before proceeding — for example, read ../clean-typescript-functions/SKILL.md when addressing F-rule violations, or ../clean-general-names/SKILL.md when addressing N-rule violations. If the Skill tool is available, invoke the skill by name instead. The sub-skills contain code examples and nuance that this index omits.
When fixing or editing code, report what was fixed (e.g., "Fixed: extracted magic value to SECONDS_PER_DAY (G3)").