One CLAUDE.md File Runs My 3 Production Apps (No Subagents)

By Lazar Milicevic · Published June 15, 2026 · 10 min read

You opened Claude Code, shipped a small project, felt the magic — then added a second repo and watched it forget your stack. By the third project, you're spending the first ten minutes of every session re-explaining your own business. That's not a prompting problem. That's a missing operating layer, and almost no one shows you how to build it.

I run three live production apps from one global CLAUDE.md and three slash commands. No subagents. No orchestrator. No template pack. Here's exactly what's on my machine.

The real problem isn't Claude — it's context decay across projects

Every solopreneur I talk to hits the same wall around project three:

• Claude writes Python when the repo is Node.
• It suggests Mongo when you've been on Postgres for two years.
• It re-asks the same clarifying questions every session.
• You context-switch and lose 10 minutes of mental warmup per switch.

The course-sellers' answer is always more: more agents, more tools, a seven-subagent stack you'll pay $497 for. The actual fix is the opposite — one global memory file, a handful of slash commands, one project-routing rule.

That's the whole architecture. The rest of this post is the file layout, line by line.

The global CLAUDE.md — four blocks, ~180 lines

Lives at ~/.claude/CLAUDE.md. Claude Code reads it on every session, regardless of which directory you're in. Mine has four blocks and nothing else.

Block 1 — Identity (3 lines)

Three lines. Who I am, what I build, who I build it for. Just enough that Claude stops asking dumb clarifying questions.

# Identity
I am Lazar. Senior engineer shipping custom AI automations.
I build production tools for solopreneurs and small teams (1-10 people).
Default frame: ship working code, not tutorials or explanations.

That's it. No resume. No backstory. No "you are a 10x developer" prompt theater.

Block 2 — Tech stack defaults

This is where most people overwrite. Keep it tight. List your real defaults so Claude has somewhere to fall back when a repo has no local config.

# Stack defaults (override per project)
Language: Python 3.11 (fallback: Node 20)
Framework: FastAPI for APIs, Typer for CLIs
Database: Postgres 15 (SQLite for prototypes)
Testing: pytest with -x --tb=short
Deploy: VPS via systemd + Caddy
Style: black, ruff, type hints required on public functions

Now when I start a fresh repo and say "build me a webhook handler", there is zero back-and-forth. It already knows.

Block 3 — Output rules (the block almost nobody writes)

This block has the highest signal-to-noise payoff in the entire file. Three rules:

# Output rules
1. Never explain code I didn't ask you to explain.
2. Never suggest alternatives unless I ask.
3. When you finish a task, give me the exact command to run next.

Before I added rule 3, every session ended with "Now you can test this by...". After: "Run: pytest tests/test_webhook.py::test_retry -x". That difference compounds across hundreds of interactions a week.

Block 4 — Project routing

The secret to running multiple apps from one setup. One line per project: name, stack, phase.

# Active projects
~/code/fakturko        — Invoicing SaaS, Python/FastAPI/Postgres, MAINTAIN
~/code/una-intel       — Gmail-Telegram bot stack, Python/aiogram, SCALE
~/code/bizflowai.io-cat     — Lead-gen agent system, Python/FastAPI, BUILD

Three phases I actually use:

• BUILD — green-field, lots of new code, low test coverage acceptable.
• MAINTAIN — feature-frozen, only bug fixes, every change needs a test.
• SCALE — performance and reliability work, no new features without measurement first.

When I cd into ~/code/fakturko, Claude reads the global file, matches the directory, and knows: this is the invoicing app, MAINTAIN mode, write a test before touching anything. Zero re-explaining.

The local CLAUDE.md — inheritance, not duplication

On top of the global, every project has a CLAUDE.md at its repo root. It inherits everything global and only adds what's project-specific.

# Fakturko — local context
Schema: see db/schema.sql. Invoices table has soft-delete via deleted_at.
Deploy: ./scripts/deploy.sh (runs migrations, restarts systemd unit fakturko.service)
Open bugs:
  - PDF rendering breaks on invoices >50 line items (see issue #42)
  - VAT rounding mismatch for Croatian clients (PR #51 in review)
Never touch: billing/legacy_export.py (used by accountant's tool, breaks silently)

That's the memory hierarchy:

Claude reads both automatically when you open a session in that directory. That's the entire architecture. No vector stores. No memory plugins. Two markdown files.

Three slash commands. That's the whole tooling layer.

You don't need seven subagents. You need to do three things: load context, push work out, recover from errors. One command for each.

Slash commands live in ~/.claude/commands/ as markdown files. The filename becomes the command name.

/context — load state in 30 seconds

~/.claude/commands/context.md:

Read the local CLAUDE.md in the current directory.
Read the last 3 git commits (git log -3 --stat).
Read any TODO.md or NOTES.md files in the repo root.
Give me a one-paragraph summary of where this project is right now,
followed by a single sentence: "Most likely next task: <X>".
Do not suggest what to do next beyond that one sentence.

I run it the second I open a session. Thirty seconds later I know where I left off. Used to take me 10 minutes of scrolling through code.

/ship — edit to production in one command

~/.claude/commands/ship.md:

1. Run the test suite (pytest -x --tb=short). If anything fails, stop and report.
2. Run git diff --stat. Generate a conventional commit message based on the diff.
   Format: <type>(<scope>): <subject>. Types: feat, fix, refactor, chore, docs.
3. git add -A && git commit with that message.
4. git push origin <current-branch>.
5. If deploy.sh exists in repo root, run it. Otherwise stop.
6. Report: commit hash, files changed, deploy status.

Took me about 20 minutes to write. Saves hours every week. From edit to production is one command.

/debug — structured triage, not random fixes

~/.claude/commands/debug.md:

I will paste an error below. Answer these four questions in order, nothing else:

1. What is the actual error? (one sentence, no speculation)
2. What is the most likely cause given this codebase? (cite specific files)
3. What is the smallest test that confirms or denies the hypothesis?
4. What is the fix? (code diff, no prose)

Do not suggest alternative approaches. Do not explain the language or framework.

Four questions, always in that order. Stops me from spiraling into random fixes when something breaks at 11pm.

What this looks like in practice

Here's a real Tuesday. Two project switches, both under 30 seconds of warmup.

# Working on Fakturko — tax calculation edge case
$ cd ~/code/fakturko
$ claude
> /context
# Claude: "Fakturko, MAINTAIN. Last 3 commits touched VAT rounding.
#  Open bug: Croatian VAT mismatch (PR #51). Most likely next task: merge PR #51."

> Fix the rounding in invoices/tax.py — Croatian rate should round half-up at 2dp.
# ... edit happens ...

> /ship
# Tests pass. Commit: "fix(tax): Croatian VAT rounds half-up at 2dp". Deployed.

# Now switch to UNA_Intel — completely different stack
$ cd ~/code/una-intel
$ claude
> /context
# Claude: "UNA_Intel, SCALE. Last commit added Telegram webhook retry.
#  Open: retry backoff not tested under load. Most likely next task: load-test retries."

From one app to another, fully loaded context, in under 30 seconds. I do four or five of these switches a day now. Used to lose 40-50 minutes a day to context warmup alone.

What I deliberately don't use (and why)

The market is full of advice that looks productive and isn't. Here's what I tried and dropped:

The pattern: every tool I dropped was solving a problem I didn't have. A global CLAUDE.md and three slash commands solve the problem I actually have — context decay across projects.

Why bizflowai.io helps with this

This same operating-layer thinking is what I build into client projects at bizflowai.io. Most small teams don't need an "AI strategy" — they need one boring memory layer so their tools stop forgetting them. When I ship automations for clients (invoicing flows, lead routing, inbox triage), I write the operating doc first, the code second. The doc is what makes the system maintainable six months later, when the founder wants to change a rule and doesn't remember how anything connects. The code is the easy part.

Copy this tonight

If you want to steal this setup verbatim:

1. Create ~/.claude/CLAUDE.md with four blocks: identity, stack defaults, output rules, project routing.
2. Add a CLAUDE.md to each repo root with schema notes, deploy command, open bugs.
3. Create ~/.claude/commands/context.md, ship.md, debug.md with the contents above.
4. cd into a project, run /context, see if it actually summarizes the state correctly.
5. If it doesn't — your local CLAUDE.md is missing information. Add it. That's the whole iteration loop.

You'll know it's working when you stop dreading project switches. That's the only metric that matters.

Frequently asked questions

What is context decay in Claude Code and why does it matter for solopreneurs?

Context decay is when Claude Code forgets your stack, business, and preferences across multiple projects, forcing you to re-explain everything at the start of each session. For solopreneurs running several apps, it's the real productivity killer — not prompting or model choice. It causes Claude to use the wrong language or database, wasting the first ten minutes of every session on re-onboarding a tool meant to remember.

How do I set up a global CLAUDE.md file for multiple projects?

Create a CLAUDE.md inside the ~/.claude folder structured in four blocks: identity (three lines on who you are and what you build), tech stack defaults (preferred languages, database, deployment target, testing framework), output rules (how Claude should respond), and project routing (one line per project listing folder name, stack, and current phase). Around 180 lines total is enough to eliminate repeated context-setting.

What is the difference between a global and local CLAUDE.md file?

The global CLAUDE.md lives in ~/.claude and defines who you are, your default stack, output rules, and project routing. The local CLAUDE.md lives inside each project repo and inherits from the global, adding only project-specific details like database schema notes, deploy commands, and open bugs. Claude automatically reads both when you open a session in that directory, creating a memory hierarchy.

What slash commands should I create in Claude Code?

Three commands cover most needs: /context reads the local CLAUDE.md, last three git commits, and open TODOs to summarize where the project stands; /ship runs tests, writes a conventional commit from the diff, pushes, and triggers deploy; /debug structures error triage into four steps — actual error, likely cause, smallest confirming test, and the fix. Together they replace most repetitive session work.

Why should I write output rules in my CLAUDE.md file?

Output rules dramatically improve signal-to-noise in every Claude Code session. By telling Claude to never explain code you didn't ask about, never suggest alternatives unless requested, and always end with the exact next command to run, you eliminate filler responses. Most users skip this block, but it's the highest-leverage section because it changes the shape of every reply Claude gives you.

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.