원클릭으로
performance-lint-rules
// Tips for writing performant Oxc linter rules. Use only when editing Rust rule implementations under crates/oxc_linter/src/rules/.
// Tips for writing performant Oxc linter rules. Use only when editing Rust rule implementations under crates/oxc_linter/src/rules/.
Guide for migrating a project from ESLint to Oxlint. Use when asked to migrate, convert, or switch a JavaScript/TypeScript project's linter from ESLint to Oxlint.
Guide for migrating a project from Prettier or Biome to Oxfmt. Use when asked to migrate, convert, or switch a JavaScript/TypeScript project's formatter from Prettier or Biome to Oxfmt.
Guide for working with and updating insta snapshot tests in Oxc without terminal interaction.
| name | performance-lint-rules |
| description | Tips for writing performant Oxc linter rules. Use only when editing Rust rule implementations under crates/oxc_linter/src/rules/. |
This skill gives performance guidance for Oxc linter rule implementations.
Use this skill only for Rust code under crates/oxc_linter/src/rules/.
Do not use this skill for linter infrastructure, parser code, semantic analysis, formatter code, tests outside the rules directory, or unrelated crates.
Put node kind checks at the top level of the rule when possible. Rule runner implementations generated by lintgen can recognize implemented node types, which helps avoid invoking rules on unrelated AST nodes.
Order checks from cheapest and most selective to most expensive. Simple equality checks, early returns, and fast paths such as ASCII-only checks should come before semantic lookups, allocations, or deeper AST traversal.
Most rules trigger on only a small set of nodes, so quickly return for the common non-matching cases.
Most files do not contain lint errors. Avoid preparing diagnostics, labels, help text, fix data, or other extra context until the rule knows it needs to report an issue.
Avoid walking more syntax than necessary.
run_once when the rule only needs a whole-file pass and does not need to run on every node.Do not construct regular expressions internally when byte or string checks are enough. Prefer simple operations such as checking whether a string contains a character, starts with a prefix, ends with a suffix, or matches a small fixed set of values.
Minimize allocations in hot lint paths.
Vecs and Strings when iteration or borrowed data is enough.