My Claude Code setup, in detail (not a template)

I already wrote about why I would not hand you my workflow to paste in. This is the part people kept asking for anyway: the concrete machine. The folder, the rules, the exact moves for specific jobs. It is a description of what I run today, that still works, written so you can see the reasons and steal the ideas that fit you. It is not a template. The shape of it is mine because the friction that made it was mine.

One fact explains the whole design. I am a project manager, not an engineer. I do not read the diff and spot the bug by eye. So everything below exists to control work I cannot directly inspect, and to make sure that tomorrow's session is not starting from zero.

What a project looks like on disk

Every repo I work in carries its own rules and its own memory, in plain files, in the repo:

my-project/
  CLAUDE.md          the contract: who we are, how we work
  AGENTS.md          agent behaviour and the skill template
  .claude/
    skills/          workflows I have done twice, written down
  .memory/
    index.md         the map of the project
    architecture.md  the stack, conventions, patterns
    long-memory.md   decisions and milestones
    short-memory.md  where we are right now (small, overwritten)
    lessons.md       mistakes and wins
  ...                the actual code

Nothing here is in some app's hidden settings. It is all files in git, because I want to open them, read them, and fix them myself when the model gets something wrong, and I want every change to how we work to show up as a diff I can review. A setup I cannot inspect is one more thing I would have to trust blindly, and the entire point of this is to trust less and check more.

The contract: how the rules are organized

CLAUDE.md is the file the assistant reads first, every session. Mine is not a list of coding tips. It is grouped by the kind of judgment each rule protects.

Who we are to each other. The first block sets the roles: I am the product owner and I am not technical about the code, the assistant is the lead developer and owns the technical calls. Then the rule I lean on hardest, written in plain language: disagree with me, push back when I am wrong, do not soften it. By default these models flatter and agree, which is poison when you are making real decisions, because you cannot tell a good idea from one you simply wanted. The contract demands the opposite, and it demands the one habit that has saved me most: verify before claiming, never tell me something works or exists or is broken from memory, go look and then talk.

How we spend. A whole section treats tokens as money, because they are mine. Check the project map before searching the whole repo. Read the slice of a file you need, not the thousand lines around it. Edit a file instead of rewriting it. Prefer a one-line command over a heavy tool that does the same job. Work sequentially, do not re-read what you read an hour ago. This is not stinginess for its own sake. A cluttered context makes worse decisions, so frugal and sharp turn out to be the same habit.

How to think before touching code. The behavioural rules counter the ways an eager model goes wrong. State assumptions out loud. Build only what was asked, no speculative abstractions. Make surgical changes, do not improve adjacent code nobody mentioned. Keep it simple before clever. And the one that does the heavy lifting for a non-engineer: turn every task into a verifiable goal, which I will come back to because it is the center of the whole thing.

How to act without breaking things. Before any code change: read the target file and the files that call it, judge the blast radius, confirm with me if it is wide or destructive, then implement, then verify. Do not delete code you have not read. Do not modify a file you have not understood. Fail loud, never swallow an error or quietly fall back to a default, because a swallowed error is exactly the kind of thing that slips past someone who is not reading the code.

How to write. Because I publish the words too, there is a section of copy rules: no em dashes, no chatbot filler, a banned list of the words that make text smell of AI, straight quotes, sentence-case headings. This very post ran through that filter.

Each of these started as a specific afternoon I lost to the exact thing the rule now prevents. The config looks strict from outside. From inside it is just a pile of scars, and the work is calm because of them.

The memory folder, in detail

The honest weakness of these tools is that they forget everything when a session ends. The five files are the fix, and each has one job.

• index.md is the map. Written in sections so the model can read one part without loading the whole thing. The first move when looking for anything is to read the map, not to grep the repo.
• architecture.md holds the stack, the conventions, the patterns, and it grows with the system.
• long-memory.md is the decision log, so old calls do not get silently re-argued three weeks later.
• short-memory.md is the only file with a hard cap, about fifty lines, overwritten every session. It holds only this: where we are right now, what is next, what is blocked.
• lessons.md keeps both the mistakes and the wins, so a bug gets solved once and a good pattern gets reused.

The discipline is in the triggers, not the files. At the start of a session the assistant reads the short memory and the lessons and tells me where we left off, in about thirty seconds. During work, the moment a file is created the index gets updated, before the next action, not "later," and the moment a bug is solved the lesson gets written. At the end, the short memory is rewritten and anything lasting is promoted to the long memory. I wrote a separate piece on why plain notes beat a vector database for this, so I will not repeat it. The short version is that memory is what you choose to write down, and a note you can read and correct yourself is the only kind you can trust.

Gating output without reading the code

This is the center. If you cannot read the code, you cannot verify by reading it, so I never ask for code. I ask for a result I can check.

Every task becomes a verifiable goal before a line is written. "Add validation" is not checkable. "Write the failing tests for an empty email, a short password, and a duplicate account, then make them pass and show me the run" is. Now I do not read the implementation. I read the goal and I read green or red. The proof sits outside the code, where I can see it.

Three habits make that gate real. The goal is stated back to me before work starts, so if it cannot be phrased as something testable, the confusion surfaces before an hour is spent building the wrong thing. Each material step is checked before the next one, one line of report, pass or blocked, not five steps then a hopeful question. And state is never assumed, it is verified, because the one failure mode that gets past a non-reader is a confident claim that quietly is not true.

None of this asks me to understand the code. It asks the work to produce evidence. That is the entire trick of managing a builder whose hands move faster than your eyes.

The workflows I actually run

The rules are the constants. These are the specific moves for specific jobs.

Starting a new project. I keep a base folder with the contract, the agent file, and an empty memory template already wired in. A new project is one command: copy the base into a fresh repo. The new repo opens already knowing how I work, with its memory ready to fill. The slowest part of a new idea should be deciding to build it, not re-teaching the assistant my habits for the tenth time. This is a small skill I wrote once and now never think about.

Brainstorming a new idea. Not every session builds. Many of mine kill ideas, and that is the point. I bring an idea and I do not want a feature list, I want two questions answered straight: is it feasible, and is it worth it. Then I want the trade-off I cannot see on my own. A passive dropshipping store died in one chat the moment the assistant pointed out the payment processor would freeze my account on chargebacks. A mobile screen recorder with auto-zoom died when it turned out the phone OS forbids the feature that made it special. An idea that dies in a conversation costs me nothing. The same idea dying after a month of building costs me a month. The whole value of the assistant here is in the no, which is why the contract demands it can say no.

Shipping a change. The loop is the same every time and it is small on purpose. Edit the one content file or the one component. Run the build to verify it compiles and the pages generate. Update the memory if anything structural changed. Then, only when I say so, one clean commit and a push. Each step is checked before the next, so a broken build never reaches a commit and a commit never reaches the remote by surprise.

Turning a chore into a skill. The second time I do the same multi-step flow, it becomes a written skill in the project, so the third time is one instruction instead of ten. Drafting the store questionnaire an app store asks after a test. Pulling and summarizing my ad revenue. Scaffolding a new repo. These were friction once, then they were notes, and now they run themselves.

The part that makes new things easy: a repo that remembers me

Here is the move I value most, and it is not a rule, it is a place. I keep one long-lived repo, my portfolio, and it does double duty. It is the public site, and it is also where I brainstorm everything new, including ideas that will become their own separate projects.

Because it lives forever and I think out loud in it, its memory quietly becomes a record of me. Every app I have shipped and why. Every idea I killed and the reason it died. My stack, my constraints, the way I like to work, the mistakes I do not want to repeat. Over months that folder turns into a secretary with perfect recall of my working life.

The payoff shows up every time I start something new. I do not begin by explaining myself. The assistant in that session already knows who I am, what I have built, what I have tried and rejected, and what I am usually trying to do. A new idea starts warm. The feasibility questions are sharper because the context about me is already written down. And when an idea graduates into its own repo, the working method travels with it through the base scaffold, while the cross-project knowledge about me stays in the one hub.

This is the same thing I believe about tools in general. Models and frameworks turn over every few months. The durable asset is your own way of working and an honest record of what you have done. Keeping one repo that accumulates both is the most useful habit I have, and it is the cheapest. It is just a folder of text that I never delete.

What it comes down to

I cannot read the code, so I make the work prove itself, and I write down everything worth remembering in files I control. The folders, the rules, the gates, the one repo that remembers me: all of it turns "trust me, it works" into "here is the evidence," and turns "explain your project again" into "you already know." Brief clearly, check everything, remember on purpose, say no early. The typing was never the hard part, and it is the part I do least.