Ask Claude to Write a Custom ESLint Rule
The ESLint plugin ecosystem is huge but it never has the exact rule your team needs. Claude knows the AST visitor API and can write a working custom rule from a plain-English description.
Write a custom ESLint rule called no-hardcoded-urls that reports an error
when a string literal starts with "https://" or "http://" and isn't
assigned to a constant named with ALL_CAPS.
Claude generates the rule file, the correct visitor structure (Literal node visitor), and a full test file using RuleTester with passing and failing cases. You don't need to know anything about AST node types.
Write an ESLint rule called require-error-boundary-in-async-components that
warns when a React component uses useQuery or useSWR but doesn't have an
ErrorBoundary wrapper in its nearest parent component tree.
For enforcement in your codebase, Claude will also show you how to wire the rule into your eslint.config.js:
// Claude will generate this setup
import noHardcodedUrls from './eslint-rules/no-hardcoded-urls.js'
export default [
{
plugins: { local: { rules: { 'no-hardcoded-urls': noHardcodedUrls } } },
rules: { 'local/no-hardcoded-urls': 'error' }
}
]
If you can describe the bad pattern, Claude can write the rule that catches it.
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.