Where to Find Good AI Rules for Claude Code (And How Not to Sound Like a Robot Whisperer)

What Are AI Rules Anyway?

If you've used Claude Code, Cursor, or any AI coding assistant, you've probably noticed something: the AI is only as good as the instructions you give it. These instructions go by many names:

• CLAUDE.md files (Claude's official format)
• .cursorrules files (Cursor's version)
• System prompts (the fancy term)
• Rules files (the casual term)
• "That thing I copy-pasted from Reddit" (the honest term)

These files tell the AI how to behave, what patterns to follow, what to avoid, and basically how to not embarrass you in front of your codebase.

Why You Need Good Rules

Without rules, your AI assistant is like a very enthusiastic intern who read every programming book ever written but has never seen YOUR codebase. They'll write "correct" code that:

• Uses a completely different naming convention than your project
• Adds 47 dependencies you didn't ask for
• Refactors working code because "best practices"
• Creates files in random locations
• Uses React when you're writing vanilla JavaScript
• Adds TypeScript types to your JavaScript project (thanks, I hate it)

Good rules turn that chaotic intern into a team member who actually read the README.

Where to Find Good AI Rules

1. GitHub: The Mother Lode

Search GitHub for CLAUDE.md or .cursorrules and you'll find hundreds of examples. Some gems:

• Anthropic's Official Cookbook - Straight from the source. If anyone knows how to talk to Claude, it's the people who made Claude.
• awesome-cursorrules - A curated collection of Cursor rules for different frameworks and languages. It's like a buffet of AI instructions.
• Search for filename:CLAUDE.md on GitHub to find real-world examples from actual projects

2. cursor.directory

cursor.directory is a community-maintained collection of Cursor rules organized by framework, language, and use case. It's basically a shopping mall for AI instructions. Need rules for Next.js 14? They got it. React Native? Yep. "I just want the AI to stop adding semicolons"? Probably that too.

3. Reddit and Twitter/X

The r/cursor and r/ClaudeAI subreddits are goldmines for rules that people have battle-tested. Twitter/X is also surprisingly good if you search for "CLAUDE.md" or "cursorrules". Just be prepared to scroll past 47 threads about AI taking over the world first.

4. The Official Docs (Revolutionary, I Know)

• Claude Code Documentation - Anthropic's official guide includes best practices for CLAUDE.md files
• Cursor Docs on Rules - How Cursor expects rules to be formatted

Anatomy of a Good Rules File

Let's break down what makes rules actually useful versus what makes them a creative writing exercise.

# Code Style
- Use 2-space indentation
- Prefer const over let, never use var
- Use arrow functions for callbacks
- Always add explicit return types to functions
- File names should be kebab-case (user-profile.ts)

# Project Structure  
- Components go in src/components/
- API routes go in src/app/api/
- Shared utilities go in src/lib/

# Testing
- Write tests in __tests__ folders next to the code
- Use describe/it pattern
- Mock external APIs, never call them in tests

# Guidelines
- Write clean code
- Follow best practices
- Make it readable
- Be consistent
- Think about performance
- Code should be good

Real Examples That Actually Work

Example 1: The "Stop Over-Engineering" Rule

Every AI's favorite hobby is turning a 5-line function into an enterprise architecture. Here's how to stop it:

# Simplicity Rules
- Do not add abstractions unless explicitly asked
- Do not create helper files for one-time operations
- Do not add error handling for impossible scenarios
- Prefer inline solutions over creating new utilities
- If a feature can be done in under 10 lines, do it inline
- NEVER add backwards-compatibility shims. Just change the code.

# What NOT to do
- Don't create a utils/helpers.ts for a single function
- Don't add try/catch around code that can't fail
- Don't suggest "we could make this more reusable" unless asked

Example 2: The "Match My Existing Code" Rule

Because nothing says "AI wrote this" like code that looks completely different from everything else in the file:

# Code Consistency
- Before writing new code, read the surrounding code style
- Match existing naming conventions exactly
- If the file uses double quotes, use double quotes
- If the file doesn't use semicolons, don't add them
- If functions use function keyword, don't switch to arrows
- Copy the formatting style of nearby code

# Examples from this codebase
- We use camelCase for variables, PascalCase for components
- We don't use index files (no barrel exports)
- We prefer named exports over default exports
- Error messages should start with "Failed to..."

Example 3: The "I'm Using a Specific Framework" Rule

Nothing worse than getting React code when you're writing Svelte:

# Framework: Next.js 14 App Router
- Use Server Components by default
- Only add "use client" when absolutely necessary
- Use next/image for all images
- Use next/link for all internal links
- API routes go in app/api/[route]/route.ts
- Server actions go in lib/actions.ts
- DO NOT use pages/ directory, this is App Router only
- DO NOT suggest getServerSideProps or getStaticProps

# State Management
- Use React useState for local state
- Use URL params for shareable state (useSearchParams)
- Use Server Components + fetch for data
- We do NOT use Redux, Zustand, or any state library

Example 4: The "Commit Message Therapist" Rule

If your AI keeps writing commit messages like it's being paid by the word:

# Git Commits
- Commit messages should be under 50 characters
- Use present tense ("add feature" not "added feature")
- No periods at the end of the subject line
- Format: type(scope): message
- Types: feat, fix, docs, style, refactor, test, chore

# Good examples
- feat(auth): add password reset flow
- fix(api): handle null response from users endpoint
- docs: update README with setup instructions

# Bad examples (don't do this)
- "Updated the authentication system to include password reset functionality with email verification"
- "Fixed bug"
- "WIP"
- "asdfasdf"

My Personal CLAUDE.md Template

After months of iteration (and many "why did you do that" moments), here's what I actually use:

# About This Project
[Brief description of what the project does]

# Tech Stack
- Framework: [Next.js 14 / React / etc.]
- Language: [TypeScript / JavaScript]
- Styling: [Tailwind / CSS Modules / etc.]
- Database: [Postgres / MongoDB / etc.]

# Code Style
- Indentation: 2 spaces
- Quotes: single quotes for JS, double for JSX attributes
- Semicolons: yes
- Trailing commas: yes
- Max line length: 100 characters

# File Organization
- Components: src/components/[ComponentName]/index.tsx
- API: src/app/api/[route]/route.ts
- Utils: src/lib/[utility-name].ts
- Types: src/types/[domain].ts

# Naming Conventions
- Files: kebab-case (user-profile.tsx)
- Components: PascalCase (UserProfile)
- Functions: camelCase (getUserProfile)
- Constants: SCREAMING_SNAKE_CASE (MAX_RETRIES)
- Types/Interfaces: PascalCase with I prefix for interfaces (IUserProfile)

# Do NOT
- Add dependencies without asking
- Create abstraction layers for single-use code
- Add comments that just restate the code
- Refactor code that isn't related to the current task
- Use deprecated APIs or patterns
- Add console.logs to production code

# Do
- Ask clarifying questions when requirements are ambiguous
- Match existing code patterns exactly
- Keep changes minimal and focused
- Test on edge cases (null, undefined, empty arrays)
- Consider mobile/responsive if touching UI

Common Mistakes (And How I Made All of Them)

Mistake 1: Rules That Are Too Long

I once wrote a CLAUDE.md that was 500 lines. The AI basically ignored half of it because there's only so much context it can hold. Keep it focused. If your rules file is longer than your actual code, you've gone too far.

Mistake 2: Contradictory Rules

Actual thing I did once:

# Line 47
- Always use explicit types

# Line 203 (forgot about line 47)
- Prefer type inference when possible

The AI got confused. I got confused. Everyone was confused.

Mistake 3: Not Updating Rules

Your rules should evolve with your project. If you migrated from Pages Router to App Router six months ago but your rules still say "use getServerSideProps", you're going to have a bad time.

Mistake 4: Being Too Strict

Rules like "NEVER use any" in TypeScript sound good until you're wrapping a library with garbage types and the AI refuses to help because it's been told any is forbidden. Leave room for judgment.

Pro Tips

• Start minimal, add rules when you see problems. Don't try to anticipate every issue upfront. Wait until the AI does something annoying, then add a rule for it.
• Include examples. "Use camelCase" is good. "Use camelCase, like getUserById not get_user_by_id" is better.
• Reference your actual project. Instead of generic rules, point to real files: "See src/components/Button for component structure".
• Keep a "Recently Added" section. It helps you remember why you added rules and whether they're still relevant.
• Test your rules. After adding new rules, try a few prompts to make sure they're being followed. AI is good at pretending it understood.

Quick Reference: File Locations

Final Thoughts

Good AI rules are like good documentation: nobody wants to write them, but everyone wishes they existed. The 30 minutes you spend writing a solid rules file will save you hours of "no, not like that" conversations with your AI assistant.

Start simple. Iterate often. And remember: if you find yourself typing the same correction to the AI more than twice, it should probably be a rule.

Now go forth and create rules files that would make even the most chaotic AI behave like a senior developer. Or at least like a mid-level developer who actually reads the PR requirements.

Happy prompting!