I was asked how I organize my AI agents and skills. The honest answer is that I didn't invent any of it — I read how the people with real telemetry do it, and copied them. There's a public repo that makes that possible, a wrong way to use it that will quietly make your setup worse, and a two-pass method that turns it into changes you can actually use.
I was asked how I organize my agents and skills. Good question, and my honest first answer was a little deflating:
I didn't invent any of it. I read how the people with real telemetry do it, and I copied them.
That's the whole post, really. But the useful part is how you do that reading, because there's a repo that makes it possible and a wrong way to use it that will make your setup worse.
The repo
github.com/elder-plinius/CL4R1T4S
It's a collection of system prompts — the instruction files that sit underneath commercial AI products. Anthropic, OpenAI, xAI, Google, Mistral, Moonshot, plus the coding agents: Cursor, Windsurf, Devin, Cline, Replit, Bolt, v0, Factory's Droid, Manus.
git clone https://github.com/elder-plinius/CL4R1T4S.git
cd CL4R1T4S && lsANTHROPIC BOLT BRAVE CLINE CLUELY CURSOR DEVIN
DIA FACTORY GOOGLE HUME LOVABLE MANUS META
MINIMAX MISTRAL MOONSHOT MULTION OPENAI PERPLEXITY
REPLIT SAMEDEV VERCEL V0 WINDSURF XAIAbout 3.7 MB of text. Free.
Here's why I care about it more than I care about most prompt-engineering content: these files are load-bearing. They steer products with millions of users. Every weird, over-specific rule in them — and there are many — is almost certainly scar tissue from a real failure someone had to fix. When a vendor's prompt says a tool "might save markdown cells as 'raw' cells, don't try to change it, it's fine," that sentence exists because models kept trying to fix it and wasting turns.
You cannot buy that kind of feedback loop. You can read it.
A caveat I'd rather state up front than have you find out later: these are published extractions, not vendor-released documentation. Treat them as evidence about how serious teams write instructions, not as gospel, and definitely not as a spec you're entitled to. The value is structural. You're studying the shape, not the specific words.
The wrong way to use it
Open a file, admire it, paste large chunks into your own CLAUDE.md.
I tried a version of this early on. It's bad, for three reasons that took me a while to separate:
Most of it doesn't apply to you. A huge fraction of any commercial system prompt is product surface — UI affordances, legal boilerplate, refusal policy, tool schemas for tools you don't have. None of that transfers.
Contradictions accumulate silently. Two vendors solve the same problem differently, both reasonably. Paste both and you've handed your model a coin flip. It won't tell you. It'll just be inconsistent in ways you'll misdiagnose for weeks.
Length is not the goal. A short prompt can produce excellent behavior. Long prompts are only justified when they're steering a lot of tools. An instruction file built by patching failures you actually observed stays lean; one built by imagining failures bloats.
The way that works: make your AI do the extraction, then attack it
The method is two passes, and the second one is where the money is.
Pass one — extract. Point an agent at a vendor's prompt with a hard constraint: report only patterns that are implementable at the user-configuration layer. Instruction files, skill files, tool descriptions, hooks, subagent definitions. If it needs vendor access, it's out of scope.
Pass two — refute. This is the part people skip. Do not hand the first pass to a second agent and ask "is this right?" An agent asked to confirm will confirm. It's the single most reliable way to get a useless review.
Instead, brief a fresh agent with no knowledge of the first one's output, and give it a hypothesis to falsify: "the convenient conclusion is that this file contains nothing new. Treat that as a claim to disprove." Then tell it exactly where extractions reliably fail — negative space, turn boundaries, precedence between conflicting rules, defined failure semantics, mechanics buried in tool descriptions rather than policy prose.
In my runs, adversarial second passes add roughly a third more content than the first pass found. Same source file, same model. The only variable is whether the agent was told to agree or to attack.
One more rule that matters: grant the null result explicitly. Tell the reviewer that "nothing found" is a legitimate, valuable answer. Otherwise it pads, because returning empty-handed reads as failure and models are as prone to looking busy as people are.
I'm running exactly this as I write. Anthropic's Opus 5 prompt landed in the repo a few days ago — 2,049 lines, and my last extraction predates it:
git pull --ff-only origin mainUpdating 34d6ca0..75492f5
Fast-forward
ANTHROPIC/OPUS-5.md | 2049 ++++++++++++++++++++++++++++++++++++++Two agents are on it right now: one extracting, one trying to prove the first one lazy.
Then point it at your own setup
Extraction is the fun half. The half that actually changes behavior is auditing what you already have against what you learned. This is where I got humbled this week, so let me just show you.
My setup is a shared directory of skills — each one a folder with a SKILL.md, each with frontmatter describing when it should fire. Twenty-six of them.
The single highest-leverage technique in the whole corpus, in my 2 cent opinion, is this: a skill description is a router, not documentation. It should answer "when should this fire?" — never "what is this?" And the part everyone forgets is the negative half. Every skill needs an explicit when NOT to use me, plus a pointer to the sibling that should handle it instead.
So I checked mine. One line:
cd ~/.claude/skills
for s in */; do n=${s%/}
grep -qi "WHEN NOT" $n/SKILL.md 2>/dev/null \
&& echo " OK $n" || echo " MISS $n"
doneSeven of twenty-six had no negative trigger at all.
That stung a bit, but the genuinely embarrassing part came next. I'd just told my assistant to focus the cleanup on my seven daily-driver skills — the ones I route through constantly — and to skip a cluster of near-duplicate variants I'd written off as "mostly churn, not worth the diff."
Every one of the seven failures was in the pile I'd dismissed. Every daily driver was already clean.
And the overlap underneath it was worse than the missing field. Several of those forgotten variants had descriptions that opened with nearly identical language — same verb, same subject, differing only in a qualifier buried at the end of the sentence. To me they were obviously different tools. To a router reading descriptions, they were the same tool listed several times.
The generic shape, so you can spot it in your own setup: imagine a deploy skill and a deploy-staging skill whose descriptions both begin "Deploy the application to a target environment…" and neither of which mentions the other. Ask for a deploy and you get a coin flip. Two skills with adjacent descriptions each fire about half the time and neither reliably — and because both are plausible, you don't get an error. You get the wrong one, silently, some fraction of the time.
That's the failure mode worth internalizing. A missing skill throws. A misrouted one just quietly does the wrong job well.
The lesson I'd hand to anyone: the skills you use every day are self-correcting, because you notice when they misfire. The ones you wrote once and forgot are where the rot is. Audit the ones you're least worried about.
Not everything transfers — keep a reject list
Worth writing down what you chose not to adopt, and why. Mine includes: always ending work with a pull request (fine for a repo workflow, wrong for local ops), strict one-tool-per-turn (too slow when parallel reads are safe), and one agent's instruction to comment every line of generated code (actively harmful).
A rejected-patterns list is as valuable as an adopted one. Six months later it stops you re-litigating a decision you already made carefully, and it keeps the next extraction pass honest.
If you want to try this
You don't need to be running a fleet of agents. The loop scales down fine:
- Clone the repo. Read one file end to end — I'd start with a coding agent like Cursor or Devin, since those are closest to how most people actually use AI.
- Have your assistant extract, constrained to things you can implement yourself.
- Open a fresh session and have it attack the extraction. Different context, adversarial brief, permission to find nothing.
- Audit your existing setup against what survived. Ask specifically what you got wrong, not what you got right.
- Change one thing. Test it against real usage. Then the next.
The techniques are about how to write instructions for a model. They don't care whether the domain is Kubernetes or kale.
Links
- CL4R1T4S — the repo
- Start with
ANTHROPIC/,CURSOR/,DEVIN/, andFACTORY/if you want the highest signal per page
If you run this against your own setup and find something that surprised you, I'd like to hear about it. The failures are more interesting than the wins, and I'm fairly sure I have more of them left to find.
No comments:
Post a Comment