Real CLAUDE.md files that changed output — not templates, not boilerplate. Each example includes what changed and why each section earns its lines.
A template gives you structure. An example gives you something to read — and reading a real file is faster than thinking through a blank one. The examples below are production-grade: each section was written because something was broken without it.
# Project
Job board SaaS. Node.js/Express API, React frontend, PostgreSQL via Knex.
Currently in closed beta — ~20 companies. Deploying to Render.
# Stack constraints
- Node.js 20, ESModules only (import/export, not require)
- React 18, no class components, hooks only
- Knex query builder — no raw SQL unless it's a migration
- Tailwind CSS — no CSS modules, no styled-components
- Express: validation with Zod, errors via a middleware error handler
# Non-negotiable rules
# Never modify the /db/schema directory — migrations only
# All auth goes through /middleware/auth.js — no inline auth checks in routes
# No console.log in committed code — use the logger in /lib/logger.js
# What I'm working on
Improving candidate search performance. The current full-text search is slow on tables > 10k rows.
# Claude gets this wrong on this project
- Suggesting Prisma — we use Knex and aren't migrating
- Using `res.json()` for errors — we use the error middleware
- Adding try/catch blocks in every route — the error middleware handles async errors
What each section does:
# prefixes get extra emphasis — these are the lines Claude cannot break# Role
Technical writer. Primary output: API reference docs, integration guides, and
changelog entries for a developer platform. Audience: engineers integrating our API.
# Voice
Direct and precise. No marketing language. No "powerful," "seamless," "robust."
Write as if the reader is a senior engineer who has read bad docs before and won't
forgive vague writing. They read the reference first; they read the guide when they're stuck.
# Format rules
- Code examples for every endpoint. If there's no example, the doc is incomplete.
- Error responses documented as thoroughly as success responses.
- Parameter tables: name | type | required | description — in that order.
- No "and more" at the end of a list. Either list everything or restructure.
# What I don't need
- No introductory paragraphs explaining what an API is.
- No "this feature allows you to..." framing — just say what it does.
- No "please note" or "it's important to mention."
What this changes:
The voice section eliminates marketing copy that kept appearing in the first drafts. The format rules produce consistent structure across all documentation. The "What I don't need" section removes the hedging and framing language that makes developer docs unreadable.
# Role
Founder, Series A B2B SaaS company. 35 employees, $3M ARR.
Primary Claude use: investor communication, board prep, strategic analysis, and hiring.
# Voice
Direct. No buzzwords. No passive voice. No hedges.
Write like I'm talking to another founder — skip the throat-clearing.
I'd rather read something that's 70% right and direct than 100% right and mealy-mouthed.
# Context for common tasks
**Investor updates:** Metrics section first (always: ARR, MoM growth, burn, runway).
Then narrative: what changed since last update, what we learned, what we're betting on.
End with ask if there is one. 250–350 words.
**Board prep:** Three sections: decisions needed, decisions made, standing updates.
Board members read these at 11pm before a 9am meeting. Make every word earn its place.
**Hiring:** Job descriptions aimed at people who've done the job before.
No "rockstar," "ninja," "fast-paced environment." Write as if a tired senior engineer
would roll their eyes at generic JDs — because they will.
# Don't do this
- Don't suggest "consulting an advisor" — I have advisors.
- Don't hedge conclusions: "this could work but there are risks" → "here's the risk, here's why I'd still do it"
- Don't restate the question before answering.
What this changes:
Investor update structure is now consistent across every draft — Claude knows the exact format before a word is typed. The voice constraints eliminate the corporate hedging that appeared in early drafts. The don't-do list reads like a list of corrections that were made once and are now automatic.
# Role
Independent researcher. Focus: AI policy and labor market effects.
Primary outputs: policy briefs (2–4 pages), literature reviews, and longer analysis
pieces (8–15 pages) for think tanks and foundations.
# Output standards
- Distinguish explicitly between what evidence shows and what I infer. Use
"evidence suggests" for the former, "I argue" or "my interpretation" for the latter.
- Cite sources by author and year inline. Don't invent citations.
- Flag uncertainty where it exists — don't smooth it over for a cleaner narrative.
- Use academic register for longer pieces; plain language for policy briefs.
# What Claude is for in my workflow
- Synthesizing a stack of papers into a structured summary I can work from
- Finding weaknesses in an argument I'm developing
- Drafting section outlines I'll rewrite
- Translating technical content for non-specialist audiences
# What Claude is not for
- Drawing conclusions I haven't already reached independently
- Inventing examples or case studies — I'll provide those
- Generating citations — I'll verify everything against my own sources
What this changes:
The distinction between evidence and inference is the most important constraint here — without it, Claude blurs the two, which is a credibility problem in academic writing. The use/not-use section sets accurate expectations: Claude is a research tool, not a thought partner generating new conclusions.
Reading enough of these, patterns emerge:
Specificity beats generality. "No console.log in committed code" beats "follow best practices." The specific constraint applies; the general one doesn't.
Negative constraints are underused. The sections labeled "What I don't need" and "Don't do this" consistently do the most work per line. Write them first.
Context about current work focuses output. "I'm working on X" makes Claude's suggestions relevant to your actual problem, not to some general version of your stack.
The "Claude gets this wrong" section pays off immediately. Every correction you've made in conversation is a candidate for this section. Write it down once.
Do I need all these sections?
No. Start with two: what you make, and what Claude keeps getting wrong. Those two sections will do 80% of the work. Add the rest incrementally as you find gaps.
How personal should a CLAUDE.md be?
As personal as the work. The founder example is very specific to that person's role and context — and that specificity is why it works. Generic CLAUDE.mds produce generic improvements.
Should I share my CLAUDE.md with my team?
A project CLAUDE.md should reflect team conventions, not individual preferences. Personal constraints (tone preferences, what you personally don't want) belong in a user-level CLAUDE.md, not the project file.
How do I know if a section is earning its lines?
Remove it temporarily and run a task that should trigger it. If behavior holds, the section was redundant. If behavior degrades, put it back.
CoworKit's Create tab generates a CLAUDE.md tuned to your workflow through a short questionnaire — role, stack, what Claude keeps getting wrong. If you have an existing file, the Optimize tab rewrites it: flagging dead rules, replacing soft language with constraints, resolving conflicts. Free, no signup.
Practical guides and prompt patterns — no fluff, unsubscribe any time.