Portable Expertise: How CLAUDE.md, Skills, and Wikis Became Code

I keep a folder on my laptop called claude-things. It has CLAUDE.md files I've written for ten different projects, a few skills I've reused across them, an AGENTS.md template I share with clients, and an experimental MEMORY.md I'm still refining. Three years ago, this folder would have been a folder of prompts. The fact that it's now a folder of structured manifest files is the shift I want to talk about.

The pattern matters because it answers a question every leader I work with asks at some point: "How do I keep the value when the senior engineer leaves?" The answer used to be documentation, runbooks, wikis nobody reads. The answer now is: the senior engineer's expertise has, in part, already been written down — as the file the agent reads on every run.

What the manifest files actually do

There is a thoughtful guide by Amit Ray comparing CLAUDE.md, AGENTS.md, SKILL.md, MEMORY.md, and CONTEXT.md that I send to people who are trying to make sense of the ecosystem. The naming is messy because every tool vendor invented its own file. The underlying pattern is consistent:

• Project memory — facts about this project. Conventions, decisions, the libraries we don't use and why.

• Agent personality and role — how should the agent behave. Tone, depth, willingness to push back.

• Skills — reusable capabilities. A markdown file (or a folder of them) that captures a procedure.

• Context — what to load when. Sometimes a config file, sometimes a routing layer.

Different tools privilege different parts of this. Claude Code uses CLAUDE.md heavily, with a skills directory and an MCP-server config. Cursor uses .cursorrules. Cline has its own. The ecosystem hasn't settled on names, but every meaningful tool has equivalents to all four.

Why this pattern beat the alternative

The alternative was "fine-tune a model on your company's playbook." Through 2024, that was the recommendation from every vendor selling enterprise AI. Train a custom model. Embed your expertise in the weights.

That recommendation died in 2025 for three reasons:

1. The base models improved faster than fine-tunes could keep up. Every six months a new model release made the fine-tuned model worse, relative to the base.

2. Maintenance cost was crippling. Fine-tuned models drift. They need re-training as the underlying business changes. The cost is real and rarely budgeted.

3. You couldn't read what the model knew. A fine-tuned model is an opaque artifact. You can't audit it. You can't see what it's doing differently. When it makes a mistake you can't fix the source.

Manifest files solve all three. They live in version control. They are diffable. They are inspectable. When the base model changes, the manifests don't. When a junior engineer wants to know how the senior engineer thinks, they read the file.

The wiki-as-code shift

The deeper change is that organizational knowledge has stopped being prose and started being structured manifest. A 2022 wiki page said "When you onboard a new customer, you should consider X, Y, Z." A 2026 manifest is precise enough to execute: when-to-use trigger, required information, step-by-step procedure, validation checks.

That isn't documentation. That is instruction. The agent reads it and executes it. Which means it has to be precise enough to execute, which means writing it forces clarity that wiki prose let you dodge.

Teams that write good manifest files write better wikis. Teams that write bad wikis write much worse manifest files. The skill is the same, but the manifest format raises the bar.

Skills as the new asset class

The most interesting development is what's happening around skills as a transferable category. A skill is, at minimum, a markdown file with a title, a when-to-use trigger, and a procedure. Some skills are just text. Some bundle Python helpers or shell commands. Some reach for MCP servers. The Claude Code ecosystem ships with a default set, and you can write your own.

This is starting to look like an asset class. I see three patterns emerging:

• Internal skills libraries. Companies maintain a skills folder, version-controlled, shared across the engineering org. Onboarding includes "read this library." This is where expertise actually lives now.

• Vendor-published skills. Anthropic publishes skills. Other ecosystem players are starting to. The procurement question becomes "does this vendor ship skills for the workflows I care about?"

• Marketplace skills. There are early marketplace experiments. I'm skeptical that a horizontal marketplace will work, because the value of a skill is so context-dependent. Vertical marketplaces — skills tuned for healthcare, for finance — are more plausible.

The piece I think most people miss is that skills are testable in a way prompts never were. You can write a skill, write a set of inputs, run them through an agent, evaluate outputs. That makes skills the first artifact in this space that fits a normal software-engineering workflow: write, test, version, deploy.

What this changes for engineering leaders

If you accept that manifests and skills are now part of your codebase, two things follow:

• You need a manifest review process. Skills get reviewed like code. CLAUDE.md changes get diffed and discussed. Otherwise drift sets in, and the file that was supposed to encode senior judgment becomes a graveyard of stale assumptions.

• Your hiring criteria shift. When I interview engineers now, I ask them to read a CLAUDE.md file out loud and tell me what they'd change. It is the most informative signal I've found for whether someone understands the new mode of work.

The teams at Applied Futures who put real investment into their skills libraries report two things consistently. First, the agents get noticeably better — faster, more on-brand, more aligned with how the team actually works. Second, the humans get better too. The act of writing manifests forces decisions that previously hid in tribal knowledge.

The continual-learning thread

The reason I'm writing about manifests in Week 6 — and not waiting until the world-models post in Week 12 — is that they are the early signal for what's coming. Continual learning, in the LangChain framing, happens at three layers: model (re-training, expensive, slow), harness (rewriting the agent's code, medium cost), and context (updating the manifest, cheap, fast).

The context-layer learning is what scales. It's what an OpenClaw is doing with its SOUL.md that updates over time. It's what every team that maintains a CLAUDE.md is doing already. The agent does something. You notice it didn't go well. You add a line to the manifest. Next run, the agent does better. The "training" happens in the file you can see.

Manifest files are how you continually learn at organizational speed.

Next week, the term that has organized the entire conversation: harness engineering. The full Week 7 post is the centerpiece of this series and the direct extension of my London talk.