What problem does it solve? Adding a custom lint rule to an oxlint-based repo involves wiring across several files — rule modules, plugin registration, config enablement, and fixture tests — and missing any one of them silently disables the rule. This Skill walks through the complete authoring workflow so a new rule actually runs, is tested, and rolls out cleanly over existing violations. ## Core Features & Use Cases - Rule Authoring: Build rules with the rule(description, create) helper, AST accessors from plugin-helpers.ts, and report() for diagnostics, grouped by domain in rules-*.ts modules. - Registration & Enablement: Wire rules into openrouter-plugin.ts, enable them in oxlint.config.ts (openrouterRules or path-scoped overrides), and register names in test.config.ts so the fixture harness picks them up. - Fixture Testing & Rollout: Add should trigger: / should not trigger fixtures, run bun run test:oxlint-rules, and handle pre-existing violations via baseline modules or registry files before flipping a rule to 'error'. - Use Case: You want to forbid a deprecated API across the monorepo. Write the rule in the right domain module, enable it, add a fixture with positive and negative cases, scan the repo, and check in a baseline for the grandfathered hits — all in one PR. ## Quick Start Help me write a new custom oxlint rule that bans direct fetch calls in route handlers, including its fixture test and rollout plan.
