ECC: How a Claude Code Config Became a Top GitHub Repository

In January, a developer uploaded his Claude Code config folder to GitHub. It now has more stars than React. The repo is called ECC, which started life as everything Claude Code, and its first commit is honest about what it was: a complete configuration collection. 9 agents and 9/ commands, backed by 8 rule files and 7 skills, pulled straight out of 10 months of Affaan Mustafa’s own daily use. He pushed it on January 18th, and 40,000 stars turned up over the next 20 days. It's now sitting at 255,000 of them, and 38,000 forks, MIT licensed, which makes it the 16th most starred repository on the entire platform, above the Linux kernel. Enjoying this so far? Subscribe to the YouTube channel and grab the free daily newsletter at indiehacker.news. New deep dive every weekday. The README is the pitch, and it's a long one, 2,200 lines before the license. The first thing on it is a warning telling you to install only from official sources, which is the kind of line you write after somebody clones your repo and ships malware under your name. Under the title is the line the whole project runs on: "Optimize the context window. Persist everything else." Then, a table counts them for you, 286 skills and 94 commands, next to a star chart that goes almost straight up. Further down, it keeps them apart properly, one rope per concept, spelling out what loads when. There's a map of what's inside. And near the bottom, there's one honest table where plenty of the cells just say "not supported." It isn't alone up there, and that's the part that should tell you something. One spot above it sits a repo literally called "skills" from Matt Pocock, whose tagline is "skills straight from my agents directory." A few spots further up sits "superpowers," an agent skills framework built the same way. So, three of the 20 most starred repositories anywhere are now folders of Markdown that tell a coding agent how to behave. The difference is scope. Those two stay close to skills, while this one tries to be the whole operating layer around them, which is a much bigger promise to keep. Here's the shape of it: 235 days old and already 2,670 commits deep. Inside, there are 570 separate instruction files an agent can load, and one person wrote 58% of the commits behind them. So, what does it actually do to your agent? The core loop is plan -> test -> implement -> review -> verify -> remember -> improve, and then a chain of stages that keeps going long after the code already works. And the whole argument is that you shouldn't be retyping any of that into every prompt. Plan mode turns a request into an editable artifact you approve before a line gets written. The TDD workflow gates you, so you have to capture a failing test as evidence before implementation is allowed to start at all. Review then runs in a fresh context, on the theory that the context which wrote the code is the worst possible reviewer of it. At the end, rather than dumping the transcript somewhere, it distills the session into summaries and into things it calls "instincts," patterns carrying a confidence score that get recalled when they look relevant. And when the same win keeps showing up, one command clusters those instincts into a brand new skill. Want to be featured? Pitch your open-source repo at indiehacker.news/apply and get in front of thousands of builders. The second half is what most config packs skip entirely. It ships its own security scanner called AgentShield, and the thing AgentShield scans is your own agent setup. Everything from your project instructions down to your MCP servers, treated as an attack surface instead of as trusted config. One flag points three Opus agents at it, an attacker and a defender with an auditor over the top, and the run exits with a build-breaking code the moment it finds something critical. Hooks arrive in profiles that go from minimal up to strict, so you get to decide how much of the runtime is allowed to fire at all. And then there's the catalog, which is where the old name earns itself. There's a skill in here for custom trade compliance, and five more for wiring up a home network, Pi-hole DNS included. Underneath, none of this is exotic. It's Markdown and Node scripts wired into the harness's own life cycle. The hooks file registers 24 commands across 7 life cycle events, and two of those matchers fire on every single tool call your agent makes. So on a normal install, there's code running before and after basically everything. Each hook bootstraps through an inline node -e 1-liner. The install lands in your home directory, rather than your project, which means it's live in every session on the machine. Rules load into context on every run, which is why you're told to install only the language packs you actually use, while skills sit on disk until something asks for them. And back in June, they cut the default MCP connectors from 6 down to 1, arguing that a skill wrapping a command-line tool does the same job for a fraction of the context. Installing it is one command, and to its credit, it's loud about what it's about to do. The guided setup walks you through the scope and the hook profile before it writes a single file. And if the profile you picked would switch the hook runtime on, it stops and makes you say "yes" out loud. The one thing the README repeats more than anything else is not to stack two install paths into the same harness because you end up with duplicated skills and every hook firing twice. Version 2.2.1 landed on September 8th, two days ago, and it reads like a security patch rather than a feature drop. The command guard now recognizes destructive PowerShell, including the native tool path, and it stops a later variable assignment from hiding a command it already failed to resolve. Exemption globs that could previously point outside the project root now stay inside it. The installer won't overwrite files it can't prove it owns, and uninstall finally respects the dry-run flag instead of deleting anyway. There are 12 fixes in those notes, and the bulk of them are about not damaging something that was already on your machine. The release before it audited 108 commits across 530 files. Two things to weigh before you run it: 53 of the 68 agents are handed Bash—a lot of shell for a folder you downloaded off the internet. There's also a file in the root called "Soul," which the agent reads as its own identity, and the numbers in it stopped being true months ago. Anything growing this fast outruns its own documentation, and you're the one who finds out where. If that trade sits fine with you, nothing else out there is anywhere near this thorough. The builders who get value out of it are going to be the ones who actually read what they just switched on, then keep what fits and throw the rest away.