Steal the idea, not the config

Don’t blindly copy-paste anything I say or show you. Don’t do that with stuff from anyone. Don’t blindly install skills, paste things into your CLAUDE.md or complete prompts.

See all of that stuff as ideas or inspiration. It’s like anything else in your setup: you start somehow vanilla, and if you find something not working for you, address that. You see optimization potential? Try it.

That’s the disclaimer I put in front of everything I share… and here is why I think it’s more than just being polite.

TL;DR

• A shared config is someone else’s answer to a problem you maybe don’t have
• Copying is not neutral-if-unused → a wrong instruction overrides what the agent would have found out by itself
• Start vanilla → hit real friction → fix that specific thing → keep it only as long as it earns its place
• What’s worth sharing is the observation, not the artifact
• Nobody ever deletes anything from these files. Do that too.

A config is an answer to a question you never asked

When somebody publishes their CLAUDE.md, a skill or a prompt library, what you see is basically a list of things that went wrong for them. In their repo, with their conventions, on the model they used at that time.

“Always run the type-check before committing” is in there because their CI kept breaking. “Never use barrel files” is in there because some import cycle cost them a day. “Prefer the repository pattern” describes an architecture you don’t even have. Take the context away and what’s left looks like universal best practice, but is really just a list of things that hurt them once.

Which is fine, that’s exactly what makes it interesting to read. It’s just not what makes it good to install.

Copying is not free, even when the instruction is wrong

This is the part people underestimate. The intuition is that a borrowed instruction either helps or does nothing. Both halves of that are wrong.

It’s not free, because everything in that file goes into every single session, relevant or not. A big context file is a tax on every session you will ever run, and the numbers we have say these files are really easy to overuse: developer-written ones helped a little, generated ones made things slightly worse and more expensive.

And it’s not harmless when it’s wrong, because agents follow instructions quite literally. A modern agent dropped into your repo without any guidance goes and looks: searches, reads the actual code, figures out the actual pattern. Now give it a confident instruction that doesn’t match your repo → you just replaced something it would have gotten right by looking with something it now gets wrong by obeying.

You didn’t add context there, you overrode it.

And nobody really calculates that trade: the upside is a bit of guidance you maybe don’t need, the downside is your agent being confidently wrong about your own codebase.

Start vanilla, then earn every addition

So the loop I would argue for is boring and it works:

• start vanilla → no skills, no context file, defaults. Yes really, you need a baseline before you can say if anything you add is an improvement
• work, and notice real friction → not theoretical friction, the thing that annoyed you for the third time this week
• fix that specific thing → the narrowest fix for the friction you actually felt
• keep it only while it earns its place → if you can’t remember why a line is in there, that’s information

Why the order matters: additions triggered by inspiration grow forever, because nothing in that process ever removes something. Additions triggered by pain limit themselves, because you only have so much pain.

And this is also why I’m suspicious about my own setup, not only about other people’s. To be honest… I really can’t tell you which of my customizations are load-bearing and which are just superstition I added once and never tested again. Being bad at evaluating that is a real problem, and stacking somebody else’s untested choices on top of my own untested choices doesn’t make it better.

So what is worth sharing?

If configs don’t transfer, why write about this stuff at all?

Because the part that transfers was never the file. It’s the observation behind it: this failed for me, here is what I think happened, here is what I changed. That survives the move to your repo, your model, your team. The artifact doesn’t.

So when you read somebody’s setup, mine included, the useful question is not “what do I copy?” It’s “what problem was this person solving, and do I even have it?” Usually the answer is no… and you still learned something, because now you know that problem exists and what it looks like when it shows up.

The habit nobody has: deleting

Last thing, because it’s the cheapest improvement available and basically nobody does it.

These files only grow. Every one I ever saw, mine too, has instructions for a framework that got replaced, a convention that changed, a model weakness that got fixed two generations ago. And all of it still loads, every session, describing a project that doesn’t exist anymore.

Open yours and read it like the agent would: as a factual description of the codebase you are about to work in. Delete everything that is not true anymore.

It’s usually more than you think, and it’s the one edit that makes the file better in every direction at once → smaller, cheaper, and not lying anymore.