菜单
Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories has produced excessive noise.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when removing dead code, renaming symbols, or refactoring — any change with no external consumers. Triggers on deprecating dead code, wrapper shims, compatibility aliases, TODO-future-cleanup, or refactors that patch structure instead of simplifying.
Use when configuring custom providers for OpenCode.
Use when writing new React components that involve state derived from props, event-driven side effects, or external subscriptions. Also use when auditing existing code for unnecessary useEffect calls, reviewing useEffect-heavy components, or refactoring to eliminate cascading renders. Applies to React 18+ codebases.
Use when about to make git commits, when tempted to bundle unrelated changes behind a single message, or when commit history needs to support git bisect, revert, and cherry-pick workflows. Also use when reviewing a branch before creating a PR. If you are writing a plan, specify that the executor must load this skill before start working.
Use when a user provides examples prefixed by "for example", "such as", "e.g.", "like", or ends a list with "etc." / "and so on". For architecture/design tasks, abstract first to identify the concept, then enumerate. For research/clarification tasks, enumerate first — the concept organizes the output but the list is the deliverable.
Use when an agent violates a loaded skill despite it being present in context — a gap exists between what the skill says and what the agent did. Also use when reviewing skill effectiveness after a violation, or when deciding whether a skill needs enhancement vs the failure is tolerable.
| name | configuring-oxlint |
| description | Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories has produced excessive noise. |
| license | CC-BY-SA-4.0 |
Work in small batches. For each candidate rule: read docs → grep codebase → configure → lint → evaluate → iterate. Never bulk-enable categories.
For each rule (or small batch of related rules):
1. Discover candidates. Start at the rules listing. Filter by category (Pedantic/Perf/Style) and scan for 🛠️ or 💡 fix icons. These are your best candidates — autofixable rules add value with zero cleanup cost. Then dive into individual rule pages (.../rules/{plugin}/{rule-name}) for candidates that look promising. From each page, extract: fix status, whether it requires type-aware linting (💭 — skip if not configured), and config options (many rules have conservative modes).
2. Grep for noise. Search the codebase for violations. Zero matches → free to enable. Many matches → check if autofixable; if not, weigh signal against cleanup cost.
3. Configure & lint. Add the rule with the most conservative config scope for a first pass. Run pnpm lint, check exit code and output volume.
4. Evaluate. Are warnings actionable? If autofixable, does pnpm lint:fix produce a safe diff? Noise? Tighten config or remove. Genuine bugs? Keep. Then pick the next rule.
Framework conflicts to watch for: eslint/no-ternary is fatal for JSX. import/no-named-export contradicts hooks patterns. import/no-nodejs-modules false-positives on API routes. Grep for these patterns before enabling — in most cases, skip these rules entirely.
| Fix status | Action |
|---|---|
| 🛠️ safe autofix | Always enable. lint:fix eliminates all noise. |
| 💡 suggestion | Enable. Low cost, manually accept. |
| No fix, zero violations in codebase | Enable. Free future protection. |
| No fix, moderate violations | Judge signal vs noise. Good signal, few hits → enable. Low signal, many hits → skip. |
| ⚠️🛠️ dangerous autofix | Only with conservative config options. |
Arbitrary thresholds (max-*) | Skip unless explicitly desired. |
{
"categories": {
"correctness": "error",
"perf": "warn",
"suspicious": "warn"
// Don't add pedantic or style — enable rules individually
},
"rules": {
// Each rule added after the iteration loop above:
"eslint/arrow-body-style": "warn",
"eslint/curly": ["warn", "multi-line"]
}
}
"smart" mode or "multi-line" scope transform noisy rules into valuable ones.