oxc-project/oxc is a Rust collection of tools for parsing, transforming, resolving, linting, formatting, and minifying JavaScript and TypeScript. It is used to build and maintain JavaScript development and build toolchains. Catalogue add-ons provide workflows for using Oxc tools.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/oxc-project/oxc/performance-lint-rulesnpx skills add oxc-project/oxc --skill performance-lint-rulesgit clone --depth 1 https://github.com/oxc-project/oxcWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/oxc-project/oxc/performance-lint-rules)<a href="https://agentmods.dev/skills/oxc-project/oxc/performance-lint-rules"><img src="https://agentmods.dev/badge/skills/oxc-project/oxc/performance-lint-rules.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00045 | $0.00865 |
| Opus 5 | $0.00023 | $0.00432 |
| Sonnet 5 | $0.00009 | $0.00173 |
| Haiku 4.5 | $0.00005 | $0.00086 |
Grade A, and why
performance-lint-rules scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Guidelines
Prefer top-level node kind checks
Put node kind checks at the rule entry point. If a rule only handles a few syntactic forms, start run with an AstKind match and return for all other nodes, even when a helper filters again internally. This lets lintgen derive narrower NODE_TYPES and avoids dispatching the rule on unrelated AST nodes.
After changing the relevant node kinds for a rule, regenerate the rule runner with cargo lintgen and consider adding or updating assert_rule_runs_on_node_types coverage in crates/oxc_linter/src/rule.rs.
Implement only the needed entry point. If a rule is a whole-file pass over semantic indexes, use run_once by itself. Implementing both run and run_once prevents useful node-type narrowing.
Do cheaper checks first
Order checks from cheapest and most selective to most expensive. Return quickly for common non-matches before doing semantic lookups, allocations, or deeper traversal.
- Matching a small fixed string set with
matches!before semantic checks. - Rejecting lowercase identifiers before global-object checks when only constructors can match.
- Checking whether a JSX attribute starts with
aria-before lowercasing it. - Checking for required syntax such as a
keyprop before looking up callback parameter symbols. - Checking
source_range(span).contains("this")before running a visitor that only findsthis.
Delay expensive context
Most files do not contain lint errors. Do not prepare diagnostics, labels, help text, fix data, ancestors, symbols, JSX element types, or replacement strings until the rule has found a syntactic candidate that could actually report.
Iterate over the smallest set possible
- Use
run_oncewhen 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.
- For name-based binding checks, use
ctx.scoping().get_binding(scope_id, name)instead of scanning every binding inget_bindings(scope_id). - For global or unresolved identifier checks, start from
ctx.scoping().root_unresolved_references().get(name)for the small set of relevant names instead of visiting everyIdentifierReference. - When iterating unresolved references, still verify the reference is the right kind: skip references with a symbol, type-only references, and nodes whose
AstKindis not the expected identifier or member access. - When checking imported specifiers or exported names, iterate the concrete specifiers or precomputed export set rather than scanning all root bindings for every item.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 58 lines · 45 tokens per session scan A 9fb9eb72ad7a
performance-lint-rules is a skill published in the GitHub repository oxc-project/oxc (22,563 stars, last pushed 5d ago), licensed MIT. It adds 45 tokens to every session and 865 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
oxc-docs
Comprehensive reference for the JavaScript Oxidation Compiler (Oxc) — a collection of high-performance JavaScript tools written in Rust. Covers parser design (lexer, AST, parser, errors, semantic analysis), architecture (parser, linter, test infrastructure, AST tools), ECMAScript specification and grammar, performance…
type-inference
Use this skill when working on Biome's Salsa-backed JavaScript and TypeScript inference, including type-aware lint rules, raw collection or inferred representations, analyzer requests, tracked queries, import or cycle resolution, profiling, and Salsa invalidation tests. Do not use for standalone CSS/HTML module-graph…
biome-code-review
Use this skill only when asked to review completed Biome changes in a PR, branch, commit range, diff, or working tree. Perform a read-only static review and report findings without editing files or running project code. Do not use for triage, reproduction, or implementation.
doc-comments
Use this skill whenever writing or editing Rust //, ///, or //! comments in Biome, including comments added incidentally and end-user rustdoc inside lint/assist declarations. For lint/assist rustdoc, also load lint-rule-development for content requirements. Do not use for formatter handling of comments in user code.
eslint-migrate-options
Use this skill when biome migrate eslint must preserve configurable ESLint rule options through source-option models, Biome conversions, typed rule variants, and migration fixtures. Do not use for generated severity-only mapping or general rule-option design.
lint-rule-development
Use this skill when creating or modifying Biome lint rules or assists, including analyzer queries, semantic bindings, rule state, code actions, fix safety, options, registration, and end-user rule rustdoc. Also load diagnostics-development for substantial message/advice design and testing-codegen for fixture or…