| name | eslint-rule-creator |
| description | Use when creating a new ESLint rule for eslint-cease-nonsense-rules, adding a lint rule, or when user provides incorrect/correct code examples for a new rule |
Creating ESLint Rules for eslint-cease-nonsense-rules
Overview
Creates complete ESLint rules with all required files: rule implementation, tests, documentation, and registry updates.
When to Use
- User asks to "create a new ESLint rule"
- User asks to "add a lint rule"
- User provides examples of "bad code" and "good code" for linting
- User describes behavior they want to lint against
Required Files Checklist
ALWAYS create/update ALL of these:
src/rules/{rule-name}.ts- Rule implementationtests/rules/{rule-name}.test.ts- Test file (100% coverage required)docs/rules/{rule-name}.md- DocumentationREADME.md- Add rule to appropriate categorysrc/index.ts- Register rule and export types
CONDITIONALLY update:
src/utilities/configure-utilities.ts- Only if rule has configurable options
Gathering Requirements
Before writing code, ask the user for:
- Rule name (kebab-case, e.g.,
no-foo-barorprefer-xyz) - What it detects (the bad pattern)
- What it suggests (the good pattern)
- Examples of incorrect code
- Examples of correct code
- Should it have options? If yes, what options?
- Should it auto-fix? If yes, what's the fix?
- What category? (Type Safety, React, Logging, Resource Management, Code Quality, Performance, Module Boundaries, TypeScript)
Implementation Patterns
Rule File Structure
See templates/rule-simple.ts.template for rules without options.
See templates/rule-with-options.ts.template for rules with options.
Key points:
- Use
createRulefrom../utilities/create-rule - Use AST selectors when possible (cleaner than visitor functions)
- Define
type MessageIdsfor type-safe message IDs - Export options interface if rule has options
Test File Structure
See templates/test.ts.template for the pattern.
Key points:
- Import
describefrombun:test - Import
RuleTesterfromeslint - Cover all branches for 100% coverage
- Test both valid and invalid cases
- Test options if applicable
Documentation Structure
See templates/docs.md.template for the pattern.
Key points:
- Start with
# rule-nameand description - Include
## Rule Detailsexplanation - Include
## Optionssection if applicable - Include
## Exampleswith### Incorrectand### Correct - End with
## When Not To Use Itand## Related Rules
README.md Update
Add to appropriate category section following existing format:
#### `rule-name`
Short description of what the rule does.
**Configuration** (if options exist)
\`\`\`typescript
{
"cease-nonsense/rule-name": ["error", { option: value }]
}
\`\`\`
**Incorrect**
\`\`\`typescript
// bad code example
\`\`\`
**Correct**
\`\`\`typescript
// good code example
\`\`\`
src/index.ts Updates
- Add import:
import ruleName from "./rules/rule-name"; - Export type (if options):
export type { RuleNameOptions } from "./rules/rule-name"; - Add to
rulesobject:"rule-name": ruleName, - Add to
recommendedconfig if it should be on by default
configure-utilities.ts Updates (if options)
Add a factory function:
export function createRuleNameOptions(options: Partial<RuleNameOptions> = {}): RuleNameOptions {
return { defaultValue: "default", ...options };
}
Verification Checklist
Before declaring done:
-
bun run typecheckpasses -
bun run lintpasses -
bun testpasses with 100% coverage for new rule -
bun run buildsucceeds - All 5+ files created/updated
- Rule appears in README under correct category
- Examples in docs match the actual rule behavior