跳到正文
cccskills
免费在 GitHub 公开

ls-typescript-code-quality

Guide TypeScript code quality work. Use when touching TypeScript, TSX, tsconfig, typed ESLint or Biome config, Node TypeScript scripts, or TypeScript-heavy framework code.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(2)

  • SKILL.md6.5 KB
  • references/typescript-quality-standards.md5.7 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

TypeScript Code Quality

Use this skill when reviewing or changing TypeScript projects, TSX UI code, TypeScript configuration, typed linting, Node TypeScript scripts, or frameworks whose behavior depends on TypeScript tooling.

Start With The Pinned Toolchain

Before recommending upgrades or changing compiler/linter settings, inspect the project's actual toolchain:

  • package.json: package manager, scripts, type, engines, framework packages, TypeScript, ESLint, typescript-eslint, Biome, build tools, and test runners.
  • Lockfile: confirm the installed versions rather than assuming the manifest was resolved recently.
  • TypeScript configs: tsconfig.json, project references, framework-specific configs, and separate lint/test/build configs.
  • Framework version: Next.js, Vite, Angular, SvelteKit, Remix, NestJS, or other toolchains may pin TypeScript, Node, module resolution, JSX, or build behavior.
  • Existing commands: prefer the repo's scripts (typecheck, lint, test, build) over ad hoc runner invocations.

Do not upgrade TypeScript, Node, framework packages, or lint presets just because a newer version exists. Treat framework and lockfile compatibility as the first constraint.

When a TypeScript project needs a Node runtime baseline, target the latest available production LTS line that the project's framework and deployment platform support. Prefer Active LTS over Maintenance LTS, and do not choose a Current release line for production unless the project explicitly requires it.

Type Safety Rules

  • Keep strict enabled for new code unless the project has a documented staged migration plan.
  • Consider noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride, and noFallthroughCasesInSwitch when the project can absorb the added friction.
  • Avoid any, double assertions, broad object types, and Function. If an escape hatch is necessary, keep it local and add a short reason.
  • Prefer discriminated unions, unknown plus narrowing, branded IDs where useful, and explicit return types on exported APIs.
  • Validate external boundaries at runtime: CLI args, env vars, JSON, HTTP payloads, database rows, localStorage, queue messages, and plugin input.
  • Keep generated types, schema validators, and API clients in sync. Do not edit generated files by hand unless the repo explicitly does so.

Async, Errors, And Boundaries

  • Await promises intentionally; do not leave floating promises unless a lint rule and local pattern mark them safe.
  • Preserve causal error context with cause or wrapped messages when crossing module boundaries.
  • Model recoverable failures as typed results only when that pattern already exists; otherwise use exceptions with actionable messages.
  • Add cancellation, timeout, and cleanup behavior for long-running IO.
  • Keep framework server/client boundaries clear. Do not import server-only modules into browser bundles or browser globals into Node-only code.

Linting And Formatting

  • Prefer typed linting when the project already uses ESLint with typescript-eslint and performance is acceptable.
  • For typescript-eslint v8 and newer, prefer parserOptions.projectService: true unless the repo already has a stable project or tsconfig.eslint.json setup.
  • With Biome, preserve the existing formatter/linter contract. If Biome is the only linter, keep tsc --noEmit or the framework type checker as the type safety gate.
  • Keep formatting changes separate from semantic changes when the diff would be noisy.
  • Do not replace a working ESLint/Biome setup without a project-specific reason.

Module And Import Hygiene

  • Match the repo's module system: CommonJS, ESM, nodenext, bundler, or framework-specific defaults.
  • Do not change module, moduleResolution, jsx, paths, or package exports without checking runtime and bundler behavior.
  • Prefer import type for type-only imports, especially when native Node type stripping, verbatimModuleSyntax, or isolated emit is in play.
  • Keep path aliases consistent across TypeScript, bundler, test runner, and runtime. If one tool cannot resolve an alias, fix the shared config rather than scattering relative imports.
  • Avoid deep imports from package internals unless the package documents them.

Size And Maintainability Review

Use heuristics to decide where to focus, not as hard rules:

  • Files over about 300 lines deserve a scan for mixed responsibilities.
  • Functions over about 50 lines deserve a scan for hidden phases, nested control flow, and implicit state.
  • Types that require repeated assertions or helper overloads may need a simpler domain model.
  • React/TSX components that mix fetching, state orchestration, rendering, and formatting are good candidates for extraction.
  • Shared utility modules should have focused names and low dependency fan-in.

Validation

Prefer repo-native scripts, in this order when available:

npm run typecheck
npm run lint
npm test
npm run build

Adapt for the package manager (pnpm, yarn, bun) and monorepo task runner already in use. If a repository script is missing, use a direct tool invocation only after confirming that the specific tool is declared in the project manifest, resolved by the lockfile, and installed locally. Use the repository package manager's documented local-only mode that fails when the executable is missing.

Do not use acquisition-capable fallbacks such as npx, default npm exec, pnpm dlx, yarn dlx, or bunx to fill a missing validation tool. If the executable is absent or local-only behavior is uncertain, stop and surface an explicit dependency decision. Add or change the dependency only through the repository package manager and lockfile after the required approval and dependency-security review.

For framework projects, also run the framework build or checker that the repo uses in CI. Record any skipped checks and why.

Reference

Strict Mode Refresh Note

For strict-mode work, inspect the current tsconfig inheritance tree before changing compiler options. Treat strict as the umbrella setting, and evaluate stricter flags such as noUncheckedIndexedAccess and exactOptionalPropertyTypes only when the project can absorb the migration.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Guide accessibility reviews for UI, documents, and workflows. Use for WCAG-oriented audits, keyboard review, semantics, contrast, and remediation planning.

中文简介正在准备中。当前显示原文说明。

CruxExperts/LocalSetup62026年10月21日 更新

Use when choosing a LocalSetup Agent-* lane for exploration, research, bounded implementation, or review. Consult the static capability matrix; do not probe account or network availability.

中文简介正在准备中。当前显示原文说明。

CruxExperts/LocalSetup62026年10月21日 更新

Guide agent email inbox workflows with prompt-injection defenses. Use for inbound email processing, webhooks, routing, and safety review.

中文简介正在准备中。当前显示原文说明。

CruxExperts/LocalSetup62026年10月21日 更新

Navigate and understand codebases using agentlens hierarchical documentation. Use when exploring new projects, finding modules, locating symbols in large files, finding TODOs/warnings, or understanding code structure.

中文简介正在准备中。当前显示原文说明。

CruxExperts/LocalSetup62026年10月21日 更新

Use for Agent Q signed encrypted file-drop or mail ship and ingest, private registry v2 setup, queue status, and transport maintenance.

中文简介正在准备中。当前显示原文说明。

CruxExperts/LocalSetup62026年10月21日 更新

Inventory wrapper for the alirezarezvani Claude skills bundle. Use when triaging its broad skill catalog and large script surface before any targeted import.

中文简介正在准备中。当前显示原文说明。

CruxExperts/LocalSetup62026年10月21日 更新

查看 CruxExperts 的全部技能

报告此技能的问题