A dev team in a folder, and the question it doesn't answer

The feed's shape changed

Three things landed in the same save folder this week, and none of them are teaching a technique. One is a video about a developer who spent ten months privately tuning his own Claude Code setup, then open sourced the whole thing for free. By the video's count, 286 skills and 68 subagents, described as a dev team in a folder. Another reads any public GitHub repo and draws its architecture as a diagram you can click through. The third is a listicle promising ten plugins that will change how you work, and I won't pretend to know what's actually in it, because the caption only gave the title. Different formats, same shift. A year ago this feed taught you how to prompt. Now it hands you inventory.

What's actually in the folder

The project is called ECC, Everything Claude Code, built by one developer over ten months and pushed to GitHub for anyone to clone. The video's numbers, 286 skills and 68 subagents, are the author's count, not something I verified myself, so take them as claimed rather than confirmed. What I can confirm is what a few of the skills actually do. One scans code for security holes, another keeps the agent's memory from bloating with stale context, a third is built to learn from the agent's own past sessions and adjust. It isn't locked to Claude Code either. It runs on Cursor, Codex, and Gemini too, and the author won Anthropic's own hackathon with this exact setup, which is a better argument for cloning it than the skill count is.

What installing it actually changed

I installed it. It sits on my machine now, over 1,800 skill files on disk between it and everything that was already there. The first thing it did wasn't give me a new capability. It changed how I work with the ones I already have. ECC ships with guard hooks that interrupt a command mid-flight and ask me to state, in writing, what the command is actually for before it's allowed to run. Nobody asked me if I wanted that. It arrived along with ten months of someone else's opinions about how a careful developer should work, and I inherit that discipline whether I asked for it or not.

The one I'd already solved

The GitHub diagram tool, GitDiagram, is the cleanest idea of the three. Point it at any public repo, swap hub for diagram in the URL, and it reads the file tree, the README, and the source to draw an architecture map you can click through straight to a file on GitHub. No signup, no setup, four keystrokes. It's a genuinely good product, and I want to be honest about why it didn't feel like news to me. This repo already runs a tool called graphify that builds the same kind of knowledge graph over our own codebase. GitDiagram wasn't a discovery. It was recognition, the same job done for a public repo instead of a private one.

Installing is not the job

That doesn't make the week noise. ECC running across several tools is a real signal, this layer is starting to behave like infrastructure instead of a Claude Code party trick, and a tool that costs four keystrokes earns its place regardless of who built it first. But the honest version of the story is that the hard part moved. A year ago the question was whether you could get the tool at all. Now it's whether you know, out of 286 skills sitting on disk, which three you'll actually reach for on a Tuesday. Our own repo carries 43 hand-written skills, and most weeks most of them don't get touched either. A skill nobody calls isn't a dev team in a folder. It's a folder.