Performance Lint Rules
Optimize Rust implementations of Oxc linter rules so they run cheaply on real-world repos under crates/oxc_linter/src/rules/.
Overview
Performance Lint Rules is an agent skill for the Build phase that gives performance tips for writing Oxc linter rules in Rust under crates/oxc_linter/src/rules/.
Install
npx skills add https://github.com/oxc-project/oxc --skill performance-lint-rulesWhat is this skill?
- Scoped strictly to Rust under crates/oxc_linter/src/rules/
- Prefer top-level AST node kind checks so lintgen can skip unrelated nodes
- Order checks cheapest-first with early returns before semantic lookups and allocations
- Defer diagnostic and fix construction until a violation is confirmed
- Use run_once for whole-file passes when per-node visitation is unnecessary
Adoption & trust: 1 installs on skills.sh; 21.5k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your Oxc linter rule is correct but slows CI because it visits too many nodes and allocates diagnostics on clean files.
Who is it for?
Oxc contributors implementing or tuning rules in the official linter rules directory who care about linter throughput.
Skip if: General JavaScript lint configuration, oxc formatter/parser work, tests outside rules/, or application Rust services outside this path.
When should I use this skill?
Editing Rust rule implementations under crates/oxc_linter/src/rules/ and need performance guidance for Oxc linter rules.
What do I get? / Deliverables
You refactor the rule with cheaper ordering, selective node matching, and lazy diagnostics so lint passes stay fast on typical repos.
- Performance-optimized rule implementation
- Cheaper check ordering and visitation strategy
Recommended Skills
Journey fit
Build/backend is the canonical shelf because contributors are implementing linter rule logic in the Oxc Rust codebase, not shipping end-user product features. Backend fits compiler/linter rule engines in Rust rather than frontend UI or generic agent tooling docs.
How it compares
Meta performance guidance for Oxc rule authors, not an end-user ESLint replacement skill or a generic Rust perf audit.
Common Questions / FAQ
Who is performance-lint-rules for?
Rust developers contributing to Oxc who implement linter rules and need lintgen-aware performance patterns.
When should I use performance-lint-rules?
Only while editing files under crates/oxc_linter/src/rules/ when optimizing or authoring a rule implementation.
Is performance-lint-rules safe to install?
It guides local Rust edits in a known repo path; review the Security Audits panel on this Prism page for the skill package provenance.
SKILL.md
READMESKILL.md - Performance Lint Rules
This skill gives performance guidance for Oxc linter rule implementations. ## Scope 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. ## Performance Guidelines ### Prefer top-level node kind checks 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. ### Do cheaper checks first 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. ### Optimize for success 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. ### Iterate over the smallest set possible Avoid walking more syntax than necessary. - Use `run_once` when the rule only needs a whole-file pass and does not need to run on every node. - Iterate over symbols instead of AST nodes when looking for references to specific names. - Prefer targeted lists or semantic data over broad AST traversal when available. ### Avoid unnecessary regular expressions 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. ### Avoid heap allocations Minimize allocations in hot lint paths. - Use copy-on-write utilities when a value usually does not need to change. - Avoid intermediate `Vec`s and `String`s when iteration or borrowed data is enough. - Keep temporary data on the stack when practical. - Delay allocation until a diagnostic, fix, or transformed value is actually needed.