Don't copy this. Build your own.

There is a whole genre of content I want you to ignore: the "ultimate CLAUDE.md," the "100 skills you must install," the workflow some stranger swears by. Paste one of those into your project and you have just installed someone else's habits into your own head. Reference them, steal an idea, sure. But obeying them is how you end up working the way someone else likes to work, which is never quite the way you do.

I am a project manager, not an engineer. I ship real apps anyway, at night, mostly with Claude Code doing the typing while I make the calls. People ask for my config like it is a cheat code. It is not. The config is the least transferable part. What actually matters is the thing underneath it, and that part you have to build yourself.

So this is not a template. It is how I think about working with an AI assistant, and why every rule I have exists.

Claude is an assistant you manage, not a vending machine

The single biggest shift is to stop treating the model like a search box that returns code, and start treating it like a smart, fast, slightly forgetful colleague who is occasionally very confident and very wrong.

You manage a colleague by talking to them. When mine does something dumb, I do not just fix the output and move on. I tell it what was wrong, why it annoyed me, and what I want instead. Then, if it is the kind of thing that will happen again, I turn that conversation into a rule.

That is the real origin of every line in my CLAUDE.md. None of it was downloaded. All of it is sediment left behind by a moment of friction. Which is exactly why copying mine would not help you. Your friction is different.

Put the relationship in writing

The first thing I tell a fresh project is who we are to each other. I am the product owner and I am not technical about the code. Claude is the lead developer. And then the part that matters most: it is allowed, in fact required, to disagree with me.

By default these models agree with you. They hedge, they flatter, they soften. That is poison when you are making real decisions, because you cannot tell the difference between "this is a good idea" and "you seem to want this to be a good idea." So I ask for the opposite. Push back when I am wrong. Own the technical calls instead of handing them back to me. Be direct, skip the politeness tax. And the one I lean on hardest: verify before claiming, never tell me something exists or works or is broken from memory. Go look, then talk.

I cannot count the times that last rule has saved me. The model will state a thing with total confidence that turns out to be stale, half-remembered, or just invented. "Verify before you claim" turns a confident guess back into a quick check, and a quick check is always cheaper than unwinding a wrong decision later.

Make it remember without burning money

The honest weakness of these tools is that they forget everything the moment a session ends. The next day you are explaining your own project to a stranger again.

My fix is boring on purpose: a folder of plain Markdown files the assistant reads and writes itself.

• An index that maps the project, so the first move when looking for something is to read the map, not to search the whole codebase.
• An architecture file: the stack, the conventions, the patterns.
• A long memory of decisions and milestones, so old choices do not get silently re-litigated.
• A short memory, capped small and overwritten every session, that holds only "where are we right now, what is next, what is blocked."
• A lessons file with both the mistakes and the things that worked.

There are fancier memory tools. I do not use them. Files are cheap, they live in git so I can see every change, and I can open and edit them myself when the model gets something wrong. A memory I cannot read or correct is not a memory I trust.

The rule that makes this pay off: read the short memory and the lessons at the start of every session, and update them as you go, not "later." Created a file, update the index. Solved a bug, write the lesson. The system is only as good as the discipline of keeping it current.

A session, start to finish

It always runs the same shape.

Start. It reads the short memory and the lessons and tells me where we left off. Thirty seconds, and we are not strangers anymore.

During. Small, verified steps instead of one heroic dash. Every real change, a file edit, a command, a decision, gets checked before the next one. When something repeats for the second time, it becomes a skill so we never hand-roll it again.

End. Update the short memory with status, next steps, and blockers. Promote anything worth keeping to the long memory. Leave the campsite cleaner than we found it, because tomorrow's session starts by reading it.

Spend tokens like they are your money, because they are

I am cheap, and that turned out to be a feature. When every search and every file read costs something, you get disciplined fast.

Check the index before grepping the whole repo. Edit a file instead of rewriting it. Prefer a one-line command over a heavy tool call that does the same thing. Read the part of a file you need, not the whole thing. Do not re-read what you read an hour ago. The point of all of it is to keep the context window for thinking, not for re-discovering your own codebase for the fifth time.

None of this is about being stingy for its own sake. A cluttered context makes worse decisions. Frugal and sharp turn out to be the same habit.

You do not need a team of agents

This is the most expensive mistake I see people get talked into. Spinning up a swarm of agents, one to plan, one to code, one to review, one to "orchestrate," is the fastest way to burn money for the least reliable result. It demos beautifully. It reads like the future. In practice the coordination overhead and the cross-talk cost more than they return, and the quality is a coin flip.

Almost nobody needs more than one good agent, managed well. A single assistant that reads its memory, works in checkpoints, and actually listens to you will out-ship a committee of bots every time. If you are reaching for a team of agents to feel productive, that is the tell. Drop it. Get the one-on-one right first, and you will almost never miss the rest.

Rules are scars

If you read my config it looks strict. Investigate before you touch code. Read a file before you edit or delete it. Fail loud, never swallow an error or quietly fall back to a default. Make surgical changes, do not "improve" things nobody asked you to touch. Keep it simple before you keep it clever.

Every one of those is a scar. Each rule is a specific afternoon I lost to the exact thing it now prevents. That is the whole method: when the assistant burns you, do not just sigh and fix it. Write the rule. Over a few projects the rules stop being a list and start being a way of working, and the work gets calm.

It compounds, and it should evolve

The lessons, the skills, and the memory are not decoration. They make the next session smarter than this one. That is the quiet magic: a setup that gets better while you sleep, because the mistakes are written down and the wins are reusable.

My setup today looks nothing like my first project. The early ones had ad-hoc notes scattered everywhere and a memory that was really just hope. What I have now is a small operating system I carry from repo to repo and extend per project. The important part is that I rewrote how I work, not just what I shipped. The tools got me to "I can build anything." Learning to operate them got me to "I can build the right thing without going broke or insane."

The takeaway

Do not download a workflow. Build one, with your assistant, out of your own friction. Reference other people for ideas and obey none of them. The actual skill of this era is not collecting prompts or configs. It is becoming a good operator: someone who knows how to brief, correct, remember, and say no.

You can take any single idea here. Just do not paste the whole thing in and call it yours. It is not mine to give. It is the residue of a hundred small arguments with a machine, and yours will look different.

And do not feel like you have to write any of this by hand. The rules, the memory files, the skills, even this post: I did not type them from a blank page. I talked it through with my assistant and let it do the writing, then I reviewed and pushed back until it was mine. That is the whole point. You are already paying for it every month. Use it for the boring parts too, not just the code. Go have your own arguments.