How to Set Up a Project From Scratch So Claude Code Works at Its Best Anthropic's Claude Code performs best when projects are set up with a CLAUDE.md contract, a nine-step per-feature development loop, separate review models, and living Markdown boards, according to a walkthrough by an unnamed author. The setup, which requires no exotic tooling, aims to prevent context drift and improve agent performance across sessions. Open a fresh repository, start a Claude Code session, and ask it to build a feature. It will. The code compiles, the tests pass, and for about twenty minutes it feels like magic. Then you ask for the next feature, and the one after that, and slowly the thing drifts — inconsistent structure, decisions relitigated every session, a reviewer that’s the same model that wrote the code, and no record of why anything is the way it is. The reflex is to reach for a better prompt. That’s the wrong lever. A capable agent dropped into an empty repo behaves like a brilliant contractor with no brief: fast, confident, and pointed in a slightly different direction every day. What raises the ceiling isn’t a cleverer instruction — it’s giving the agent a project it can reason about : a contract, a loop, and a memory. This is a walkthrough of exactly that setup. Do it once, at the start, and every session afterward gets sharper instead of noisier. Most “project setup” advice stops at a folder tree and a linter. That’s plumbing. The setup that changes how an agent performs is closer to an operating system for the project — the planning docs, the standards, the per-feature development loop, and the living boards that track what’s done, what’s risky, and what’s still an open question. The distinction matters because agents don’t hold context between sessions the way a teammate does. Anything not written down is re-invented. So the whole game is to make the implicit explicit once , in files the agent reads first, and then keep those files honest. Seven moves get you there. None require exotic tooling — most are Markdown. The single highest-leverage file is a CLAUDE.md at the repo root: the operating contract the agent reads before anything else. It answers, in one place, the questions an agent would otherwise guess at every session. It should state: Keep it current. A contract that drifts from reality is worse than none, because the agent will follow the file, not your intentions. When the stack changes, the contract changes in the same commit. Ad-hoc prompting produces ad-hoc results. A repeatable per-feature development loop turns “build me a thing” into a process you can supervise and trust. A version worth stealing has nine steps: The rule that makes it work is the last one: a feature isn’t done until its docs are updated. That’s what stops the drift. The loop is written once in a strategy doc and referenced from the contract, so the agent can run it without being re-taught. Self-review isn’t review. An agent grading its own homework will confidently miss the same blind spots twice. The fix is structural: the review model or configuration must differ from the coder’s. One agent writes; a different one reviews the diff, runs the security pass, and checks the work against the acceptance criteria. This is the cheapest quality upgrade available, and it mirrors how real teams work — you don’t merge your own PR unreviewed. Bake it into the contract as a non-negotiable so it isn’t quietly skipped when you’re moving fast. Chat history is not project memory. The moment a session ends, anything not written to a file is gone. Three living boards fix that, and they’re just Markdown. Two sit at the repo root; the third lives with your planning docs: The payoff: any new session — yours or the agent’s — can read three files and know exactly where things stand, instead of reconstructing it from memory that doesn’t exist. If you find yourself re-explaining your coding conventions, data-modeling rules, or PR checklist every session, that’s a signal to vendor them as skills the agent loads automatically — small, named standard folders under .claude/skills/, each holding its own SKILL.md. Two rules keep this honest. First, name the mandatory skills apply on every relevant change separately from the referenced ones you invoke on demand. Second — and this is the one people skip — if you can’t locate the real standard, write a stub that references it and flag the gap. Don’t let the agent invent a standard to fill the hole. A flagged stub that says “TODO: real Python standard lives at X” is safe; a fabricated one that reads authoritative is a landmine. Dual-track any stub with a row in RISKS.md and open-questions.md until it's real. Autonomy without brakes is how you wake up to a force-pushed main branch. Two guardrails, stated plainly in the contract, prevent the expensive mistakes: Add least-privilege identities and a cap on spawn/cost, and you’ve turned “the agent can do anything” — which is terrifying — into “the agent can do a lot, within rails you set” — which is useful. The final habit is a working posture, not a file. For anything non-trivial, drive the agent through four beats: express intent → validate a plan → let it create → verify the result. Don’t let it write files before you’ve approved the plan. Ask when a choice changes structure; pick a sensible default and state it when it doesn’t. This is the difference between supervising and hoping. You’re not typing every line — you’re setting intent, checking the plan against reality, and enforcing the gates. The acceptance criteria Gherkin’s Given/When/Then works well are the contract you brief the agent against, so “done” means something specific instead of “looks fine to me.” Put concretely, the setup lands as a small, legible structure: