performance-lint-rules

performance-lint-rules is a skill for Claude Code, Codex from oxc-project/oxc. It costs 45 tokens per session (865 once invoked), scanned A, original, MIT.

Performance-review rules for writing Oxc linter checks in Rust, where a linter check examines code for a particular problem.

In plain words
What is it for?
Reviewing or improving rules under Oxc’s Rust linter directory, including node filtering, check ordering, and rule-runner coverage.
Why use it?
They help keep checks fast by rejecting irrelevant code early and avoiding unnecessary analysis, memory use, and tree traversal.

Skill for Claude CodeCodex

About the project

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.

oxc-project/oxc · 22,563 stars · on GitHub

Install

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.

agentmods
npx agentmods add skills/oxc-project/oxc/performance-lint-rules
Any agent
npx skills add oxc-project/oxc --skill performance-lint-rules
Clone the repo
git clone --depth 1 https://github.com/oxc-project/oxc

Made for: Claude Code, Codex.

Wrote 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.

agentmods badge for performance-lint-rules

README.md
[![agentmods](https://agentmods.dev/badge/skills/oxc-project/oxc/performance-lint-rules.svg)](https://agentmods.dev/skills/oxc-project/oxc/performance-lint-rules)
Your own site
<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>
Per session 45 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 865 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 5d ago against content hash 9fb9eb72ad7a, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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.

.agents/skills/performance-lint-rules/SKILL.md · 58 lines

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 key prop before looking up callback parameter symbols.
  • Checking source_range(span).contains("this") before running a visitor that only finds this.

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_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.
  • For name-based binding checks, use ctx.scoping().get_binding(scope_id, name) instead of scanning every binding in get_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 every IdentifierReference.
  • When iterating unresolved references, still verify the reference is the right kind: skip references with a symbol, type-only references, and nodes whose AstKind is 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.

Read the full file on GitHub · 58 lines

Changes

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.

  1. 5d ago First seen · 58 lines · 45 tokens per session scan A 9fb9eb72ad7a

Subscribe to this mod's changes

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.

Related

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…

pledgeandgrow/pledge-skills · 131 tokens

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…

biomejs/biome · 78 tokens

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.

biomejs/biome · 61 tokens

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.

biomejs/biome · 70 tokens

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.

biomejs/biome · 53 tokens

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…

biomejs/biome · 65 tokens