Why this is harder than it sounds

When you captured knowledge in Chapter 02, you probably noticed something uncomfortable: there was more to it than you expected. You started explaining one rule and realized it had three exceptions. You mentioned a vendor name and realized you needed to clarify which vendor because two of them sound the same. The knowledge is layered and interconnected in ways you do not notice until you try to make it explicit.

This is organizational opacity, and every company has it.

The bookkeeping firm from Chapter 01 — six weeks of documentation before a line of agent code. The bookkeepers did not think their knowledge was complex. “We just categorize transactions,” they said. But when we sat with them, the exceptions multiplied. This customer uses a non-standard chart of accounts. That client wants vendor payments split a particular way. In Q4, everything changes because of year-end tax adjustments. Six weeks.

At the construction company, 224 commits from one developer. Not building an AI system — just writing down what one person already knew about cost code mappings. Two hundred and twenty-four commits to capture the contents of one human’s head.

Organizational opacity protects turf, too. The person who holds the tribal knowledge is the person who cannot be fired. Making that knowledge explicit can feel threatening. But it is also the only way forward, because you cannot delegate to a system that does not understand your work. And you cannot onboard a new hire efficiently if the knowledge only exists in oral tradition.

Everything you build to make the organization legible to machines also makes it better for humans. The bookkeeping firm’s documentation did not just enable an AI system — it meant new hires could onboard in days instead of months. The construction company’s cost code mapping did not just feed a model — it became the reference document the whole team used.

The developer’s version of project memory

Projects give conversations persistent knowledge on claude.ai. When you get to Claude Code (Chapter 06), the same idea appears in a different costume: CLAUDE.md.

Every Claude Code project can have a CLAUDE.md file at its root. Claude reads this file at the start of every session. It is the project’s long-term memory — accumulated instructions, learned behaviors, edge cases discovered over time.

The pattern is simple. You have a conversation with Claude. You figure something out. Then you say: “Add instructions to CLAUDE.md so you can do this again next time.” The knowledge moves from a single conversation — which disappears when the session ends — into a persistent file that every future session inherits.

This is the conversation-to-documentation loop:

1. Ask Claude to do something once — “Categorize this invoice from Chen’s Produce”
2. It figures out how — asks you questions, learns the rules, gets it right
3. Ask it to make that repeatable — “Now add these categorization rules to CLAUDE.md so you know them next time”

By the end of a working week, your CLAUDE.md might be 100 lines of accumulated instructions. Every session gets smarter because every session inherits what the previous ones learned.

Notice the parallel: project instructions are to claude.ai what CLAUDE.md is to Claude Code. Both are standing context, loaded automatically, scoped to one workspace. And both share the same limitation: the knowledge lives in one place. It is not shareable. It is not composable. When the knowledge matures — when you have tested it, refined it, and know it works — you formalize it into a skill.

Check your understanding

Answer in your own words — write it down before opening the key. Your tutor grades against the criteria and generates fresh variants on retries.

Q1. Projects (claude.ai) and CLAUDE.md (Claude Code) solve the same problem and share the same limitation. Name the problem, the limitation, and what a SKILL.md changes.

Next: Write Your First Skill