The common advice right now is to install skills. Someone publishes a hundred marketing skills, you copy the folder into your setup, and your AI supposedly does marketing now. I have tried working this way, and it does not hold up.
A hundred skills from someone else is a hundred of someone else’s decisions, made for someone else’s product. You cannot tell which six of them matter to you, and the ones that do are buried under the ninety-four that do not. What comes back is competent and generic, aligned to nothing in particular.
What I do instead
Over the last year most of my work has moved into Claude, and the thing that improved the output most was not a skill. It was a single file.
The file is called CLAUDE.md, it sits in the root of the project, and the agent reads it at the start of every session. It holds what should be true of everything the agent does: what the company is, who the customer is, the positioning, the constraints, the way I want it to work. The file stays short on purpose. A docs/ folder beside it holds the depth, and the main file points there only when a task needs it.
That is the whole thing. One always-loaded file, one folder of depth. It works not because of the format but because the file is small enough to actually maintain, and specific enough that the agent stops guessing.
The part that does the work
The section I think about most is the constraints. These are decisions a company already paid to learn and should not have to make twice. One client tried tiered pricing once and retired it, so their file says, in plain words, that pricing changes happen inside the single flat plan, never by adding tiers. An agent that did not know this would happily propose a tiered pricing page, because tiered pricing is the obvious move. The file is what stops it.
A skill cannot do that for you, because the constraint is not general knowledge. It is yours, learned the hard way, and nobody else’s folder contains it.
Maintaining the file is the real work
A brain like this is not something you write once. The real work is what you do when the agent ignores it, and it will.
You write a clear instruction, the agent reads the file, and then it does the other thing anyway. When that happens you escalate: move the line higher, make the wording more forceful, state it in more than one place. I once relabelled a step from review to lint, because the agent treats lint as a hard gate and review as optional. Blunt, unambiguous phrasing sticks where soft phrasing slides.
The other half is knowing what should change and what should not. The file has two layers. A malleable one, the things true this month: the current plan, the experiment I am running, an angle I am still sharpening. That should move. And a locked one, the settled calls: the pricing constraint, the customer. That should not. People get this wrong in both directions. Freeze everything and the file goes stale. Let everything drift and the strategy erodes a sentence at a time.
Why you cannot copy mine
I run this on three projects, and the useful part is how differently the three files are weighted. One leans almost entirely on positioning, because the work is mostly judgment. One leans on the current plan, because it is in a defined push and most decisions trace back to it. One leans on voice, because most of its output is people-facing and tone is the first thing to go wrong.
Same shell every time: one file, one folder. What changes is which part carries the weight, and that weighting is the judgment. It is why copying someone else’s file does not work, and why a hundred generic skills never will.
There is a smaller version that does work. When one skill in someone’s library matches a job you actually have, take that one, rewrite it in your own words, and point it at the context file you built. Copying a concept and personalizing it is real adoption. Installing thirty of them is a to-do list wearing a costume.
You do not need the stack. You need one honest file, and the judgment to keep it true.