A CLAUDE.md for your business, not just your repo

Give the business its own context file: an AGENTS.md in a business folder beside your repos, with your customers, pricing, numbers, roadmap, decisions and voice. Then import it from each repo’s CLAUDE.md with one line, @~/business/AGENTS.md, and Claude Code starts every session knowing the business as well as the code.

Codex and Cursor can read the same file, so you write the business down once.

What your repo’s CLAUDE.md can’t tell Claude

A repo’s CLAUDE.md holds how the code works: build commands, conventions, where things live. The state of the business sits somewhere else. Pricing lives in Stripe, the reason you dropped the free plan is in an old chat, and this month’s priority is in your head.

So Claude Code writes an onboarding email that promises a plan you retired, or starts on the feature you ruled out in March. The code is fine. The context is missing, and you paste it back in, session after session.

Give the business its own folder

Keep the business next to the code, not inside a repo:

~/business/
  AGENTS.md        the business context, one page
  CLAUDE.md        one line: @AGENTS.md
  customers/
  money/
  decisions/
  launches/
~/code/my-app/
  AGENTS.md        how this repo works
  CLAUDE.md        imports both files

Three reasons: the business outlives any one codebase, a second product can read the same file, and a public repo is no place for revenue and customer names.

A business context file to copy

Keep it to a page. Name detail files by their full path, so an agent working in a repo can find them, and don’t put an @ in front of them: Claude Code imports any @path outside backticks, and imported files load into every session.

# Business context
Read before work on pricing, onboarding, emails, copy or the roadmap.
Open the detail files only when a task needs them.

# The business
- Product: [what it does, for whom, in one line]
- Customer: [who pays, and the problem they pay to fix]
- Not for: [who you turn away]
- Numbers: [MRR, paying customers, month] from ~/business/money/snapshots/

# Pricing
- Plans: [names, prices, what each includes]
- Rules: [trial length, refunds, discounts you never give]
- Detail: ~/business/money/pricing.md

# Roadmap
- Now: [the one thing shipping this month]
- Next: [two or three items]
- Not doing: [what you ruled out, and why, in a line]

# Decisions that stand
- [date]: [decision], because [reason]. ~/business/decisions/[file].md

# Voice
- [plain, direct, the words you never use]
- Write for [your customer], not for developers.

# Rules for agents
- Customer names, emails and revenue never go into code, commits or tests.
- Ask before changing prices, plan limits or onboarding emails.
- If a task contradicts a decision above, stop and ask.
- Nothing is sent, published or deployed without a yes.

Load it from every repo

In each repo, make CLAUDE.md import both files:

@AGENTS.md
@~/business/AGENTS.md

Claude Code expands each @ line when a session starts, so the business loads beside the repo’s own rules. Relative paths resolve from the file that holds the import, and ~ is your home folder. The first time Claude Code meets an import from outside the repo, it asks you to approve it, once per project. Decline, and the import stays off.

In a public repo the import names only a path, but you can keep even that out of git: put it in a CLAUDE.local.md listed in .gitignore. Run one business? The same line in ~/.claude/CLAUDE.md loads it in every project.

Codex, Cursor and the other agents

AGENTS.md is the open format that Codex, Cursor and a long list of other coding agents read, which is why the business file carries that name. Recent versions of Claude Code read it too when a folder has no CLAUDE.md. The one-line @AGENTS.md import covers the other cases, and Claude Code doesn’t load the file twice.

The @ import is Claude Code’s own syntax, so give the other agents a pointer in words. Codex reads ~/.codex/AGENTS.md in every repo, so one sentence there reaches all your projects:

Business context: ~/business/AGENTS.md. Read it before pricing, copy, onboarding or roadmap work.

The same sentence works in any repo’s AGENTS.md. A pointer is weaker than an import: the agent opens the file when it decides a task needs it, not at every start.

Where Oknola fits

A context file is only as current as the folder behind it, and the folder is the part that slips in a busy month. Oknola keeps that folder for indie SaaS builders: MRR next to the API and hosting bills, launches, customers and the decisions behind them, in plain markdown. Oknola types, tags and files what lands in it, so the files your context file points to stay where it says they are. Your repo keeps its CLAUDE.md, and your agent reads both. There’s no connector: if a tool can read a folder, it can work on your business.

I run my own business from this structure, in a folder of about 34,000 files. What is available today is on the roadmap.

Questions people ask

Why not paste the business into each repo’s CLAUDE.md?

You’d keep three copies of your pricing, and by spring they’d disagree. One file, imported, stays one source, and it keeps revenue out of repos you might open-source.

Does the imported file cost tokens every session?

Yes. It loads at launch, like the CLAUDE.md that imports it. A page costs little. Keep the details in their own files and let the agent open them when a task needs them.

What should never go in it?

Secrets and personal data: API keys, passwords, customer emails, card details. The file goes into every session. For files that must stay private, scope what each agent can see.

How does it stay current?

Update the numbers line when you close the month (tracking MRR and costs in markdown). Add a decision the day you make it, with the reason. Then give the file five minutes in your weekly review.