Turn Claude into your expert
pair programmer
A single file — CLAUDE.md — gives Claude persistent memory about your project. No more repeating yourself. No more off-brand suggestions. Just Claude that already knows your stack.
Persistent context
Claude remembers your conventions across every conversation — no copy-pasting instructions ever again.
On-brand code
Always gets the right framework, the right patterns, the right libraries. First time, every time.
10× faster reviews
Stop correcting Claude on basics. Spend your time on actual architecture and business logic.
Team consistency
Commit one CLAUDE.md and every engineer on the team gets the same opinionated Claude.
Before & after
Here's the same prompt, asked to Claude with and without a CLAUDE.md rule.
Your prompt
"Add a user profile card component."
// Claude guesses your stack
import React, { Component } from 'react';
import './ProfileCard.css'; // vanilla CSS
class ProfileCard extends Component {
render() {
return (
<div className="profile-card">
<img src={this.props.avatar} />
<h2>{this.props.name}</h2>
</div>
);
}
}- Class component instead of functional
- Vanilla CSS instead of Tailwind
- No TypeScript types
- Props missing, no error handling
// Claude knows your exact stack
interface ProfileCardProps {
name: string;
avatar: string;
role?: string;
}
export function ProfileCard({
name, avatar, role
}: ProfileCardProps) {
return (
<div className="flex items-center gap-3
rounded-xl border border-zinc-800
bg-zinc-900 p-4">
<img src={avatar} alt={name}
className="h-10 w-10 rounded-full" />
<div>
<p className="font-medium text-zinc-50">
{name}
</p>
{role && (
<p className="text-sm text-zinc-400">
{role}
</p>
)}
</div>
</div>
);
}- Functional component with TypeScript
- Tailwind CSS — matches your codebase
- Typed props with optional fields
- Correct naming & file conventions
Your prompt
"Write a test for the login function."
// Wrong test library entirely
const assert = require('assert');
describe('login', () => {
it('should work', () => {
const result = login('user', 'pass');
assert.equal(result.success, true);
});
});- Uses assert instead of Vitest/Jest
- CommonJS require instead of ESM
- Vague test description
- No mocking of dependencies
// Knows you use Vitest + MSW
import { describe, it, expect, vi }
from 'vitest';
import { login } from './auth';
import { mockServer } from '@/test/server';
describe('login()', () => {
it('returns session on valid credentials',
async () => {
mockServer.use(authHandlers.success);
const session = await login({
email: 'user@test.com',
password: 'secret'
});
expect(session.userId).toBeDefined();
});
});- Correct test runner (Vitest)
- Matches your ESM import style
- Uses your MSW test server setup
- Descriptive, structured test names
Set it up in 3 steps
Takes under 5 minutes. Works with Claude Code and Claude Desktop.
Create the file
Create a CLAUDE.md file at the root of your project — the same folder as your package.json.
touch CLAUDE.md
Pick a rule from clauderules.net
Browse rules by your framework or language. Copy the content directly into your CLAUDE.md. Or use the Generate page to create a custom one for your stack.
# Project Rules You are an expert in Next.js 14, TypeScript, and Tailwind CSS. ## Conventions - Use the App Router, never Pages Router - Always use TypeScript with strict mode - Prefer server components — mark client components with "use client" only when needed - Use Tailwind for all styling, no CSS files ## Code Quality - Write self-documenting code — names over comments - Keep functions under 30 lines - Co-locate tests next to the files they test
Open Claude Code
Claude Code automatically reads CLAUDE.md when you open your project. No configuration needed — just start chatting.
claude # opens Claude Code in your project
Commit CLAUDE.md to git so every teammate automatically gets the same rules.
Pro tips
Start with a rule from this site
Don't write from scratch — find one that matches your stack and personalise it. Most good rules are 20–50 lines.
Be specific, not generic
"Use Zod for validation" beats "write clean code". The more concrete your rules, the more consistent Claude's output.
Include your "don't do" list
Telling Claude what not to do is as powerful as telling it what to do. e.g. "Never use any, always type explicitly".
Nest rules in subdirectories
You can have multiple CLAUDE.md files — one at the root for global rules, and sub-rules inside specific folders for specialised context.
Use the Generate page for a head start
Pick your framework and language and our AI generates a solid starting rule. Tweak it to match your conventions.
Join the community
Thousands of developers are sharing the rules that make Claude exceptional. Sign in with GitHub to save your favourites, submit your own rules, and level up your whole team.