SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmodernize-ecmascript

modernize-ecmascript

Coding & development

View repository

Updated 10-15 20:08

About this skill

Modernizing ECMAScript

Choose ECMAScript capabilities that reduce code or clarify intent around the source transformation chain, without changing observable behavior. Do not draw compatibility conclusions directly from framework names, a single tool version, or a general "ES20xx support".

Choose a working mode

Judge in order according to task intent, and choose only one mode:

  1. When there is a review, batch search, or repository-level simplification intent, chooseexplicit code review; the environment and ES constraints provided by the user serve as review conditions.
  2. Otherwise, when the user explicitly provides the environment, output version, or ES version, or specifies concrete syntax or APIs, chooseuser-directed authoring or capability consultation。
  3. Otherwise, when writing or modifying JavaScript or TypeScript, chooseeveryday syntax assistance。

Manually specifying this Skill only enforces loading of the workflow; it does not override more specific task intent.

Everyday syntax assistance

  • Focus only on code areas that are newly written, currently being modified, or already touched in the current task.
  • Do not scan untouched code, and do not automatically include existing Git working tree changes from before the task began.
  • First determine whether this change will produce or change runtime code. If it only involves type annotations, interfaces, type aliases, generics, or .d.ts and other content erased after compilation, and the task does not involve build configuration or runtime behavior, silently end the modernization judgment and continue the original task.
  • For runtime code, first identify trustworthy candidates in the current change area that can reduce code, clarify intent, or avoid handwritten helper logic. If there are no candidates, continue the original task directly; do not read yearly files,llms.txt or the full transformation chain merely because the Skill has been triggered.
  • After forming candidates, locate the actual parser, transformer, and output target from the target files, and automatically adopt only Stage 4 syntax that can be parsed and safely transformed.
  • When syntax will remain in the artifact, adopt it only if there is clear evidence of support in the target runtime.
  • Distinguish pure syntax from runtime-sensitive capabilities. As long as a capability depends on new standard built-in APIs, global objects, protocols, polyfills, or shims, treat it as a runtime-sensitive capability even if it superficially contains new syntax; in everyday mode, do not automatically adopt it by default.
  • When the user requests minimal changes, only fixing the current issue, or no refactoring, the newly written code may adopt safe syntax, but do not additionally rewrite existing code for modernization.
  • When the transformation chain, output target, or necessary runtime evidence is missing, conflicting, or ambiguous, silently stop the modernization judgment and continue the original task. Do not ask the user, and do not restate the reason for skipping in the final report.
  • Do not rewrite adjacent old code just to showcase new syntax.

User-directed authoring or capability consultation

  • Give priority to the scope, target environment, output version, ES version, and specific capability requirements provided by the user.
  • When the user only asks whether a certain capability can be used, only investigate and answer; do not modify code, and do not expand it into a repository-level review; only modify code within the requested scope when the user explicitly asks to write, apply, or refactor it.
  • After completing safe automatic discovery, when the target runtime, output target, or consumer constraints are still missing and genuinely affect the conclusion, combine the relevant missing items into a single inquiry, neither guessing nor silently applying the everyday mode's rules.
  • Verify whether the actual parser and transformer can handle the syntax the user requires, and do not silently override the user's requirements with repository defaults.
  • When requirements conflict with the toolchain, present the evidence and feasible options, and ask the user to confirm adjusting the syntax, upgrading or configuring the transformer, raising the output baseline, or abandoning that capability.
  • When the user explicitly requires standard built-in APIs, additionally verify the target runtime or the configured polyfills. When a new polyfill, shim, transform plugin, or dependency is needed, explain the source, impact, and alternatives and obtain confirmation.
  • The user may explicitly approve changes to compatibility, build configuration, dependencies, or experimental capabilities; confirmation only authorizes the chosen option and does not turn a capability that cannot be parsed or transformed into a usable capability.
  • Do not automatically expand targeted authoring into a repository-level review.

Explicit code review

  • Scan the files, packages, or repository scope specified by the user, without being limited by the currently modified area.
  • First locate legacy syntax, hand-written helper logic, and other candidates to be verified, then discover the relevant source transformation chain and output targets and filter out safe capabilities.
  • When the environment, output target, or consumer scope is missing and genuinely affects the conclusion, complete all safe discovery first and then ask the user in a single consolidated inquiry.
  • In the question, provide the detected environment, the exact uncertain items, the feasible options, their respective impacts, and a recommended choice, without interrupting once per candidate.
  • When the user only asks for a review, output analysis only; modify code only when explicitly asked to apply the review results.

Read the capability overview by ECMAScript year

When the user specifies one or more ES versions, or asks what a certain version added, first read the corresponding annual file. The annual file directly lists that version's proposals, current Stage, status, summary of effect, and online Markdown; do not load all proposals just to look up one year. Everyday mode reads the corresponding annual file only after relevant candidates have been formed, and does not treat the annual summary as preloaded material for coding tasks.

The annual file is a snapshot updated with the repository. When you need to understand a specific capability, continue by reading the online proposal Markdown linked from the entry; when you need to confirm the latest proposal set, Stage, status, or version, or when the user asks about a proposal that has not yet entered the standard, read instead llms.txt. Neither the annual file nor the Atlas proves compatibility of the target project.

Read the TC39 Atlas on demand

Use the TC39 Atlas as the entry point for proposal stages, status, ECMAScript versions, official repositories, bilingual READMEs, and proposal overviews:

  • Index:https://bosens-china.github.io/tc39-atlas/llms.txt

In addition to the annual queries above, first read the index and use its titles, stages, statuses, ES versions, and proposal page links to locate capabilities. When the index already provides links, do not construct page addresses yourself.

  • When the user specifies a certain syntax, API, or proposal, read the relevant proposal page; when the user specifies an ES version, first read the annual file, then read the online proposal pages according to the candidates.
  • After explicit review forms a shortlist of candidates, read only the pages relevant to the candidates, and do not load all proposals in bulk.
  • Use the official repository entry on the proposal page to verify authoritative source material, and extract clues such as polyfills, shims, transform plugins, implementation status, and userland alternatives from the proposal description.
  • Treat these clues as possible implementation paths, not as proof that the target project has already installed, configured, or is compatible with them.
  • When a proposal does not list polyfills, plugins, or implementations, do not infer that they definitely do not exist.
  • Before adopting dependencies, polyfills, plugins, or experimental implementations discovered on a page, check their official documentation, versions, and suitability for the target project, and obtain user confirmation according to the work mode.

Atlas describes specification maturity and proposal content; it does not prove TypeScript, transpiler, or runtime compatibility.

Locate the source transformation chain

Starting from the target file, collect only the minimum sufficient evidence needed to judge the candidate capability:

In daily mode, first form candidates, then perform the localization here; in user-directed mode and explicit review, determine candidates and investigation scope according to their respective rules.

  1. Locate the nearest package or workspace, and read package.json, lock files, actual production scripts, and applicable Agent instructions.
  2. Follow the real commands to locate TypeScript, Babel, SWC, esbuild, Rspack, or other parser and transpiler configurations, including inherited and target-package override values.
  3. Record whether the parser can understand the candidate syntax, the actual transpiler, the production output target, and whether the candidate syntax will be downleveled or preserved.
  4. Only when the candidate syntax is preserved, the code does not pass through a transpiler, or the candidate is a runtime API, then read the relevant Node, browser, Edge, WebView, embedded platform, or consumer baseline.

Framework and tool names such as Vite, Rsbuild, Next.js, and tsdown are used only to discover real commands and configurations; they do not constitute proof of compatibility. Do not maintain or rely on a static framework compatibility matrix.

Handle the execution surfaces within the same project separately:

  • Browser source code and build configuration may be executed by the browser artifact transformation chain and Node.js, respectively.
  • SSR, server-side, Edge, Worker, test, and migration scripts may have different transpilers or runtimes.
  • Code executed directly by Node.js has no syntax downleveling step; the target Node version is the runtime boundary for preserved syntax; the current host version only proves the local execution environment.
  • Docker multi-stage builds require distinguishing the build stage from the final runtime stage.
  • Published libraries and shared source code need to satisfy the declared consumer baseline; when multiple consumers are inconsistent, daily mode skips, and explicit review focuses on asking about scope.

Pass the candidate capability thresholds

Judge each candidate item individually; do not compute a false "highest ES version" for the entire project:

  1. Specification maturity: Daily mode uses only Stage 4. Stage 3 requires the user's explicit consent and a warning about experimental risk; do not recommend inactive, withdrawn, or lower-stage proposals for production modernization.
  2. Source parsing: Confirm that TypeScript, the lint parser, the test transpiler, and the production transpiler understand the candidate syntax and its current semantics.
  3. Syntax transformation: Confirm that the production transpiler can safely downlevel the candidate to the actual output target, or confirm that the preserved syntax is supported by the target runtime.
  4. Runtime supplementation: Standard built-in APIs must have native support from the target runtime or evidence that the project has configured a polyfill or shim; when syntax cannot be downleveled or will be preserved, evidence of native support from the target runtime must be obtained. Transformation plugins belong to the first two parsing and transformation thresholds; polyfills cannot make a parser understand syntax.target、TypeScript lib Neither nor the polyfill links in proposals can by themselves prove usability.
  5. Behavioral equivalence: Verify observable behaviors such as exceptions, evaluation order, sparse arrays, iteration consumption, asynchronous timing, and public APIs.
  6. Compatibility contract: Unless the user explicitly confirms, do not upgrade dependencies, do not add polyfills, do not change build targets, and do not raise Node, browser, or consumer baselines.

Describe the source capabilities and artifact baseline independently. For example, "the source uses ES2025 Stage 4 syntax, transformed by esbuild to ES2020," rather than only saying "enable ES2025."

Application and verification

  • Daily mode only modifies code areas newly written, currently being modified, or already touched by the current task, and does not send a separate modernization plan; when the user requests minimal changes, do not modernize existing code as an incidental modification.
  • User-directed writing proceeds according to the scope and constraints confirmed by the user; pure capability consultation only answers, and when a compatibility choice arises, wait for confirmation first.
  • When explicit review requires code changes, first report the scope, transformation chain, output targets, candidate capabilities, Atlas evidence, exclusions, and baseline changes, then begin editing.
  • Preserve project style and public behavior, and add comments only when a compatibility decision would be difficult to understand without them.
  • Run the target package's existing format checks, type checks, relevant tests, and production build according to risk. For a monorepo, verify only the affected consumers.

The pre-modification report for explicit review uses the following structure:

ECMAScript 现代化已准备开始。
- 模式与范围：<工作模式、应用/包、代码范围>
- 转换链：<解析器、转换器、输出目标>
- 候选与依据：<Stage/ES 版本、Atlas 提案页或官方仓库>
- 策略：<安全转换、原样保留、已批准的 polyfill>
- 排除：<实验性、不兼容或行为不等价项>
- 基线变更：<无，或用户已确认的变更>

On completion, report the capabilities actually adopted and skipped, the transformation or preservation strategy, user-confirmed contract changes, and verification results. Do not claim that Stage 4, successful type checking, or a successfully running development server alone proves transformation or runtime compatibility.