Post

My suspicion (from a call for the with Michael Cohen at the “Build with Opus 4.7” hackathon this weekend) is that this is what is “solved“ by Managed Agents.

Forgive the ignorance, but what are managed agents?

www.anthropic.com/engineering/... And apologies for my tardy typing; copy pasting text and moving bus on a browser is not easy :-)

I've got a personal repo where I manage user-scoped skills, mcp.json. I use github.com/vercel-labs/... for "install skill", either from local filepath or from git URL. I have a package.json-like file listing each skill I install. I have a script that parses that file and syncs them all.

Working on adding (npm i / npm ci)-like semantics to the script. And a global flag, so yeah, (user/repo) skills. The thing I'm most concerned with is a lockfile and exact resolved version, not just syncing latest.

I was struggling with this recently, had Claude walk me through a new strategy which (absurdly?) includes a skill for skills. Without getting into either of our specifics, a generic meta-skill pattern for this looks something like attached image. Interested in other replies here!

it is just chaos. pure, unfiltered chaos.

I’ve got a repo of project-agnostic skills that I’ve exposed via MCP using a tool I built called MyContextProtocol which helps with exposing the skills as reasonably usable MCP endpoints with metrics and all kinds of fun stuff The code is at github.com/Stygian-Tech... if you want to spin it up

I use four layers: 1. Account-level CLAUDE.md for behavioural changes I always want from the LLM 2. Project-level CLAUDE.md 3. LLM-maintained documentation within every folder in the repo itself to document code and memorialise decisions 4. Skills only for narrow, repeated tasks, eg. reviews

the main skill is /improve which writes and refactors the skills. I have knowledge directory for background context, and skills are for for small development workflows. These all live in a "developer" repo, and the real code repos are submoduled in, and worktree'd out.

So effectively you have a shell with all of your LLM workflow setup and your actual repo stays unaware. Do you also keep any repo specific skills?

i don’t use skills, mcps, or anything, just raw doggin the LLM chat interface and avoiding new shiny objects like the plague

I know what you mean, but taking a step back it's kind of funny to say you're avoiding new shiny objects while wielding the strangest non-deterministic technology we've ever seen in our lifetimes (I'm on the same page as you, though — I like the dumbest version of the magic possible)

it’s pretty incredible that even in this uncharted futuristic seeming era the KISS principle is more relevant than ever

We’re looking into this now for our AI SRE where we want to index people’s skills and either run them in an investigation ourselves or delegate to their infrastructure to run them. Sadly there is no real convention. Teams seem to do whatever works best for them, and can vary even in orgs.

Some teams are centralising and creating really large flat directories with a bunch of skills that correspond to very specific tasks, mostly because it’s simple and they can write skills to help them manage those skills easily (quite meta)

Other people have collections of run books and docs that predate AI and they’re gradually creating skills that point at those docs, much like a script might import other libraries to do work

“Global” and “project” are fine. My problem is with “iff typescript project” or “iff using excel” situations where I don’t want them globally or per project I want them by category. I (Claude) wrote a wrapper script for me that detects files like tsconfig or *.xls and loads in other directories.

So, for a social app like Moob, would this category-based wrapper script make sharing collaborative projects more universally intuitive?

Depends on what you want to do; no idea what Moob is. What the wrapper script does is give you the ability to say "If this type of file exists in the directory that we're working in, treat it as project type X" and then "If working with project type X, load these Claude Code plugins".

I think there is a fundamental UX issue with skills.md. skills.md are documentation for AIs and they have all the failure modes of documentation. The fundamental issue is that skills.md try to anticipate the future 'What will some unknown user need to know to accomplish some unknown task".

This is an ill posed problem. A well posed problem is "Tell me what you did to accomplish some task". Every time we turn the crank we should be logging what we did and why. Then we should AI figure out how to generalize from these past examples

But how do you tell the agent which parts to log? That's the skill. Encoding tacit knowledge in skills while the explicit knowledge is just spec files in the repo

Sorry to send a 8k word long post. But I recently wrote this essay about lessons from interactive fiction engine design and agent harnesses, and give a concrete example of how to author better skill files thejaymo.net/2026/03/19/h...