The 7-File Claude Code Template I Clone for Every Client

By Lazar Milicevic · Published June 19, 2026 · 9 min read

Every Claude Code tutorial skips the one thing that actually decides whether the project ships: the folder you start in. If you've ever told Claude to build something, watched it invent its own conventions, and spent the next two hours correcting it, you're not bad at prompting. You're starting from an empty directory.

Here's exactly how I fixed that across three production systems running on my home server: a template repo with seven files. Clone it, rename two strings, and Claude is productive in about 40 minutes instead of two days.

The empty-folder problem nobody admits

You install Claude Code, open a fresh folder, and type the first prompt. Prompt 1: code looks fine. Prompt 3: it forgot your stack. Prompt 5: it invented a folder layout you didn't ask for. Prompt 8: it overwrote a file you told it not to touch.

That's not a Claude problem. That's an empty-folder problem. The model has no anchors, so it improvises. Improvisation on a junior engineer is annoying. Improvisation on an autonomous code-writer that touches 12 files per prompt is destructive.

The fix isn't better prompting. It's a project skeleton that answers Claude's three implicit questions before it has to ask them:

• What stack am I in?
• What rules does this codebase follow?
• What am I not allowed to touch?

Answer those three things on disk, and the model stops guessing.

The seven-file tree

This is the whole template. Nothing fancy:

client-project/
├── CLAUDE.md              # the brain
├── README.md              # human-facing project notes
├── Makefile               # canonical commands
├── .env.example           # required env vars, no secrets
├── docs/                  # decisions, postmortems, ADRs
├── scripts/               # seed, migrate, deploy helpers
└── .claude/
    └── commands/          # slash commands
        ├── plan.md
        ├── ship.md
        └── postmortem.md

Seven entries at the root. The .claude/commands/ folder is where the slash commands live — Claude Code picks them up automatically. The docs/ and scripts/ folders start nearly empty; they exist so Claude has the right place to put things instead of inventing a utils/ or helpers/ of its own.

When a new client engagement lands, I:

1. git clone template new-client
2. Rename the project string in CLAUDE.md and README.md
3. Adjust three lines of stack in CLAUDE.md if the client isn't on the default stack
4. Open Claude Code

Total setup: under 5 minutes. The first useful prompt lands inside 40.

CLAUDE.md: four sections, in this order

CLAUDE.md is the file Claude Code reads automatically every time it opens the project. Most people either skip it or dump a wall of text into it. Both are wrong. Mine is ~220 lines and has exactly four sections, in this order.

The four sections

• Stack — three lines. Runtime, framework, database. No prose.
• Conventions — 5 to 8 bullets on how this codebase is actually organized.
• Do Not Touch — explicit paths Claude must ask before modifying.
• Run Commands — how to start, test, seed, deploy. Four lines.

Here's a trimmed version of what an invoicing client's CLAUDE.md looks like:

# Project: AcmeInvoice

## Stack
- Python 3.11
- FastAPI + SQLAlchemy 2.0
- PostgreSQL 15

## Conventions
- Every endpoint lives in `app/routes/<resource>.py`
- Every DB call goes through `app/repositories/<resource>_repo.py`
- No business logic in route handlers — use `app/services/`
- Tests mirror source: `tests/routes/test_invoices.py`
- All money values are `Decimal`, never `float`
- Logs go through `app/core/logger.py`, never `print`
- New migrations: `alembic revision --autogenerate -m "..."`

## Do Not Touch
- `app/auth/` — touch nothing without explicit approval
- `migrations/versions/` — never edit existing files, only add new
- `app/core/config.py` — ask before adding fields
- `.env`, `docker-compose.prod.yml`
- Anything under `generated/`

## Run Commands
- Start: `make dev`
- Test: `make test`
- Seed: `make seed`
- Deploy: `make deploy`

Section one is the stack. Claude needs the runtime, not your life story. Section two is conventions — the rules the codebase actually follows. For the invoicing system above, "no business logic in route handlers" alone prevents about a dozen wrong choices per session.

Section three is the do-not-touch list. This is the section that saves the most pain. Name files explicitly. When Claude reads this section, it actually respects it. I haven't had a destructive overwrite in months.

Section four exists so when Claude needs to verify its own work, it runs the right command instead of inventing one. No more "I ran pytest" when the project uses make test with a specific config.

Three slash commands that do 80% of the work

Inside .claude/commands/ I keep three markdown files. Combined, they're maybe 60 lines. They run on every project I touch.

/plan — Claude reads the current task, writes a short plan in plain English listing the files it intends to touch, and waits for my "ok" before writing code. This single command eliminates ~90% of unwanted edits.

# /plan

Read the task I just described. Do NOT write code yet.

Output:
1. One-paragraph summary of what you understood.
2. A list of files you will CREATE (with one-line purpose each).
3. A list of files you will MODIFY (with what changes).
4. Any file from the "Do Not Touch" list you think you need —
   flag it explicitly and STOP for my approval.
5. A 3-step execution order.

Then wait. Do not write code until I reply "go".

/ship — runs the test suite, checks the diff against the do-not-touch list, writes a one-paragraph commit message in the style I want.

# /ship

1. Run `make test`. If anything fails, stop and show me.
2. Run `git diff --name-only` and check against the
   "Do Not Touch" list in CLAUDE.md. If any match, stop.
3. If clean, write a commit message:
   - One line summary, imperative mood, <72 chars
   - Blank line
   - 2-4 lines explaining WHY, not what
4. Show me the message. Do not commit until I say "commit".

/postmortem — I run this after something breaks. It reads recent commits, the error logs if I paste them, and writes a short post-mortem into docs/postmortems/ so the next time a similar bug shows up, Claude already has context.

# /postmortem

1. Read the last 10 commits (`git log --oneline -10`).
2. Ask me to paste the error or logs if not already shown.
3. Write a file at `docs/postmortems/YYYY-MM-DD-<slug>.md`:
   - What broke (1 paragraph)
   - Root cause (1 paragraph)
   - Fix (1 paragraph)
   - Prevention: 1-3 bullets, concrete
4. If the prevention bullets suggest a new convention,
   propose a diff to CLAUDE.md's Conventions section.

That last step is what makes the template self-improving. Every real bug ends up either as a new convention or a new entry in "Do Not Touch". The skeleton gets sharper with every project.

What happens on prompt one

Here's a concrete run. I clone the template into acme-invoice, rename two strings, and give Claude one prompt:

Build the endpoint that generates an invoice PDF for a given invoice ID.

No clarifications. Watch the chain:

1. Claude reads CLAUDE.md. Sees the stack — FastAPI, SQLAlchemy, Postgres.
2. Sees the convention: endpoints live in app/routes/<resource>.py. Opens app/routes/invoices.py.
3. Sees: no business logic in handlers. Creates app/services/invoice_pdf.py for the rendering logic.
4. Sees: every DB call goes through the repo layer. Adds a get_invoice_by_id method in app/repositories/invoice_repo.py instead of querying inline.
5. Sees the do-not-touch list. Doesn't go near app/auth/ even though the endpoint needs auth — instead it imports the existing current_user dependency.
6. Runs /plan. Shows me three files it wants to create, one it wants to modify. I type "go". It writes the code.
7. Runs /ship. Tests pass. Commit message proposed. I approve.

First try. No corrections. The endpoint works.

That's not a prompting trick. That's the template doing the work.

Template vs. empty folder — the actual numbers

I tracked this across the last six client kickoffs (three of mine, three I helped a friend bootstrap). Same model, same Claude Code version. The only variable was whether we started from an empty folder or the template.

The empty-folder runs all eventually got somewhere. They just burned a day and a half of correction loops first. The template runs felt like onboarding a junior who actually read the docs.

The difference between a Claude Code project that ships and one that drowns isn't the model, the course, or your prompting skill. It's whether the folder you opened on day one already knows what kind of project it is.

Why bizflowai.io helps with this

At bizflowai.io the standard client onboarding starts with exactly this kind of skeleton — a project template, a CLAUDE.md tuned to the client's stack, a do-not-touch list scoped around their production code, and the three slash commands wired in before the first task is queued. It's the boring infrastructure layer that decides whether an AI build engagement ships in two weeks or stalls in a correction loop, and we set it up once per client so the agents stay productive instead of drifting.

Frequently asked questions

What is a CLAUDE.md file and why does it matter?

CLAUDE.md is a file Claude Code reads automatically every time it opens a project. It should contain four sections: the stack (runtime, framework, database), conventions (file naming, architecture rules), a do-not-touch list (files Claude cannot modify without asking), and run commands (how to start, test, and deploy). Keeping it focused prevents Claude from forgetting context or overwriting protected files.

How do I stop Claude Code from overwriting files I told it not to touch?

Add an explicit do-not-touch section to your CLAUDE.md file that names protected files and folders like migrations, production config, auth modules, and generated code. Claude reads this section on every prompt and respects it. Combined with a /plan slash command that forces Claude to list intended file changes before writing code, this approach eliminates roughly ninety percent of unwanted edits.

What slash commands should I set up for Claude Code?

Three slash commands cover most workflows: /plan tells Claude to write a short plan listing files it intends to touch and wait for approval before coding; /ship runs tests, checks the diff against the do-not-touch list, and writes a commit message; /postmortem reads recent commits and error logs to write a post-mortem into the docs folder for future context.

How do I make Claude Code productive on a new project quickly?

Use a template repo with seven files: CLAUDE.md, README.md, Makefile, a dotenv example, a docs folder, a scripts folder, and a hidden .claude folder containing slash commands. Clone the template for each new project and rename two strings. This setup gets Claude productive in about forty minutes instead of two days spent correcting hallucinated structures and forgotten context.

Why does Claude Code forget the stack and invent folder structures?

It happens because the project folder is empty of context. Claude has no persistent file telling it the runtime, conventions, or constraints, so it guesses on every prompt. This is not a Claude limitation but an empty-folder problem. Fix it by adding a CLAUDE.md file with the stack, conventions, protected files, and run commands so Claude reads consistent context every session.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.