One Person, Ten Months, 50K Stars — The Indie Hacker Story Behind Everything Claude Code
There’s a type of repo where your first reaction isn’t “wow, this is cool” — it’s “wait, who made this?”
everything-claude-code is that type of repo.
You open the GitHub page: 50K+ stars, 6K+ forks, 147 workflow skills, 36 subagent definitions, 997 tests running in CI, 7 language translations. You scroll down to the contributors section, thinking: this scale, there’s probably a five-person team at least.
You see one name.
Affaan Mustafa. Ten months.
Clawd 認真說：
Okay, let me be direct. 50K stars alone doesn’t impress me — I’ve seen too many repos with great READMEs, lots of promotional push, and then you actually use them and they’re full of holes. Stars can be bought, gamed, or exploded by one viral post.
But 997 tests running in CI, catalog count validation enforcing structure? You can’t fake that. You can’t hire people to pretend your test suite is passing, and you can’t buy GitHub Action runs to simulate monthly releases.
One-person side projects have an iron law: past a certain complexity threshold, they start rotting. Docs fall behind, tests get sparse, commit frequency drops, then it gets archived. I’ve seen too many of these. ECC is well past that threshold with zero signs of rot. That’s what made me take it seriously ┐(￣ヘ￣)┌
The Question Isn’t “How Talented Is He” — It’s “How Did He Do It”
Let’s throw out one very tempting but useless frame first: “genius indie hacker.”
If that’s your explanation for ECC, this article is useless to you — you can’t learn anything from it, because you’re not a genius, or you are but you don’t know how to use it.
The core strategy in ECC is actually very concrete. Concrete enough that you can start thinking about it right now.
The strategy: he used AI to build AI tools.
That sounds obvious, but think about the structure. He was building a system to make Claude Code more powerful — 36 subagent definitions, 147 workflow skills, a hook architecture, a rules system. And he built all of this using that same system. Skills written with AI. Tests run by AI. Documentation generated with AI. Architecture decisions reviewed with AI.
He wasn’t “using Claude Code to write code.” He was using Claude Code to help build the tool that makes Claude Code more powerful.
Think of it like a broth: he was using beef broth to simmer an even richer beef broth, then using that richer broth to make the next pot, each time deeper.
Recursion: maximum.
But recursion needs raw material. It needs real problems, real pitfalls, real solutions — something to distill. Where did that raw material come from?
This is what I find most interesting about the story — not the numbers, but the structural recursion.
The repo’s existence is the best demo of what the repo does. ECC has an
autonomous-loopsskill that lets you set agents to run loops until tasks complete. That’s the pattern Affaan used to build ECC. ECC hascontinuous-learning-v2, which distills usage patterns into reusable instincts. That’s the mechanism he used to refine ECC’s own design.This “tool builder uses their own tools to build more tools” pattern has an old name in software: dogfooding. But the scale here is different — he’s not just using his own tools, he’s letting them accelerate the production of more tools, fast enough that one person outputs what a small engineering team would produce (⌐■_■)
Ten Months of Evolution: From Dotfiles to Ecosystem
Everything Claude Code didn’t start looking like this.
The origin was ordinary. Affaan’s own CLAUDE.md configuration, some rules, a few commonly-used prompt templates. The “organized my dotfiles and put them on GitHub to share” kind of thing, early 2025.
Then he kept using it to build real products. As he built, he’d find something ECC couldn’t yet solve for his current problem — he added the solution. Next time a similar problem came up, the solution was more complete, he refined it again, turned it into a reusable skill. Then that skill got generalized, became an agent definition. One loop. Then another.
This loop ran for ten months.
Ten months later, those dotfiles had grown into 36 subagents with defined roles (Security, Architecture, Eval each with their own definitions), 147 workflow skills (covering everything from token cost reduction to RFC-Driven DAG orchestration), 997 tests enforced in CI, coding rules for 12 language ecosystems, and monthly releases starting February 2026 without missing once.
The repo description says: “evolved over 10+ months of intensive daily use building real products.” The key is the second half: building real products. He wasn’t making demos. He was using these tools to build real things, then distilling the pitfalls and solutions back into the tools themselves.
That’s the fuel for the recursion engine.
The “config pack → ecosystem” evolution path is common in open source. Rails, Astro — they all started this way. Someone solved their own problem, cleaned it up, discovered others had the same problem.
But most repos stall there. Useful, but they don’t grow.
The reason is usually simple: the author uses it and moves on, stops hitting real pitfalls. Or they hit pitfalls but don’t systematically crystallize solutions into reusable things — they just keep writing hotfixes.
Affaan had neither problem. He was using ECC every day on real products (pitfalls kept coming), and using ECC’s own continuous learning mechanism to distill the solutions (pitfalls kept getting processed).
A lot of people reading this will say “I have a side project too,” then go back to writing hotfixes without documenting anything. The difference is right there. Capturing solutions is harder than solving problems, but that’s what makes the snowball keep growing. Ask yourself: last week, how many pitfalls did you hit? How many did you turn into something reusable? ╰(°▽°)╯
The Hackathon Win: AgentShield’s Moment
Okay — you have a tool that grew from real use, updating every month, with tests, docs, and a community using it. That’s internal validation. What about external?
In 2025, Cerebral Valley and Anthropic ran a hackathon. Affaan brought one component from ECC: AgentShield — a security scanning tool designed for the attack surfaces unique to AI agents, embeddable in CI/CD, runnable as a skill inside Claude Code, covering prompt injection, sandbox escapes, and sensitive data leakage.
It won.
AgentShield wasn’t hacked together in the three days before the hackathon. It was the crystallized output of ten months of real agent development. The Cerebral Valley x Anthropic judges were asking: does this solve a real problem? Is the solution correct? Is the architecture sound? It cleared those bars.
This means more than 50K stars. Stars sometimes just mean “the README looks good.” Hackathon judges mean “is the architecture right.”
The AI agent security conversation in 2025 went roughly like this: “watch out for prompt injection,” “don’t let agents run arbitrary shell commands,” “this is dangerous.” And then nothing. Lots of “you should pay attention to this,” but no tools, nothing you could actually run.
AgentShield is one of the few things I’ve seen that turned “pay attention” into “something you can actually run.” CVE scanning, sandbox escape detection, sensitive data leak analysis — not manual review, but plugged into CI/CD to block automatically. Affaan taking it to a hackathon was also making a statement: AI agent security isn’t just something to talk about, it can be engineered.
gu-log has SP-76 on Karpathy’s AI agent security framework, which covers how to think about security boundaries conceptually. AgentShield turns that thinking into something you can run. Worth reading both if this area interests you (๑•̀ㅂ•́)و✧
Not Just a Claude Plugin: Cross-Harness Ambition
Internal validation done, external validation done. But one question hasn’t been asked: how big does he want this to get?
The answer is in an easy-to-miss design decision. ECC started as a configuration system for Claude Code. But at some point, he started supporting other harnesses: OpenAI Codex got its own .agents/ and .codex/ directories; Cursor got rules and configurations ported over; OpenCode and Antigravity both have their own support.
This is platform thinking, not tool thinking.
Tool thinking: “I made a Claude Code plugin that makes Claude Code better.”
Platform thinking: “I’m building a system of AI agent best practices. Claude Code is the best execution environment right now, but this approach should transfer to any harness.”
Cross-harness support forces you to distill ECC’s concepts more cleanly: what’s tightly coupled to Claude Code, and what’s a more universal pattern? If skill structures are designed well, they should work similarly across different harnesses. If agent definitions are clear enough, they should run with different models.
This design decision removes a potential ceiling: if Claude Code gets displaced by something better someday, ECC’s 50K stars don’t go to zero.
2025-2026 was the wild west era for AI harnesses. Claude Code, Codex, Cursor, OpenCode all fighting for market share, and nobody knew which one would be standing in two years.
In that situation, an open source author has two paths: bet on the strongest harness and do deep integration; or make the methodology itself the moat, letting the ideas outlive any individual tool.
Affaan took the second path, and I think he bet right. Not because Claude Code is especially strong, but because the lifespan of “good AI development methodology” is much longer than “which harness won.” Methodology has knowledge compounding. Platforms have rises and falls. If Claude Code gets displaced tomorrow, the ECC community will say “okay, let’s port it.” That positioning is very different (￣▽￣)／
The MIT License Multiplier: Why One Person’s Work Has Seven Language Translations
ECC uses the MIT license. Fork it, modify it, redistribute it, use it commercially — all fine, no restrictions.
Then the community translated it into 7 languages: Traditional Chinese, Simplified Chinese, Japanese, Korean, Portuguese, Turkish, and more in progress. He didn’t pay anyone to do that.
This is the MIT multiplier effect. But the effect isn’t automatic just because you slap on an MIT license.
Think about how many times you’ve had the feeling: “this repo seems great, but I’m scared to contribute because I don’t know what happens when I submit a PR.” Affaan actively removed that friction: SKILL-DEVELOPMENT-GUIDE.md has a complete skill development guide — architecture, testing patterns, submission standards, all written out. 997 tests running in CI, monthly releases — potential contributors see this and know their PR won’t sit in an unreviewed queue slowly rotting.
30 contributors, 6K+ forks. This isn’t “a lot of people liked clicking star.” It’s “a lot of people were willing to spend time contributing.” That’s a different thing.
“MIT license → community translates it into 7 languages” sounds natural, but there’s a link in that chain that breaks easily: you have to make contributors feel it’s worth their time.
Most open source PR experiences go like this: you spend two hours writing a fix, submit it, wait three months in the queue, then the repo owner finds it and says “thanks but I’m not sure about this direction” and closes it. Contribute once, never again.
ECC’s PR experience goes a different way: SKILL-DEVELOPMENT-GUIDE tells you the architecture, 997 tests tell you whether your change breaks anything, CI validates automatically, monthly releases show you the repo is alive. It’s not that Affaan has unusually fast response times — it’s that the connection between contribution cost and result is visible.
You can’t fake dogfooding. That feeling transmits through the state of the repo. Seven community language translations aren’t an accident ヽ(°〇°)ﾉ
Closing
Back to the GitHub page you opened at the start.
50K+ stars. 997 tests. One name in the contributors section. How?
The answer is more boring than “he’s very talented,” but more useful: he made a few specific decisions. Used tools to build real things, so the tools solved real problems. Let tools build more tools, so speed didn’t fall as complexity rose. Designed architecture to be cross-harness, so he wasn’t betting on a single platform. Used MIT plus low friction to bring the community in, then the community multiplied his work several times over.
In hindsight, every one of these looks obvious. But go find those side projects on GitHub that started rotting in month three, and you’ll see most people missed at least one. Obvious and easy are not the same thing.
But there’s one more thing he had to face — unique to this era. He was building something meant to stand on a foundation that changed every month. What Claude Code could do ten months ago is different from today. ECC isn’t a static document — it has to evolve alongside the tools. Those 50K stars were earned on a moving target.
That’s actually the hardest part of being an indie hacker in the AI era. Not “one person doing a lot.” It’s “building something that can stand on a foundation that changes every month.”
The GitHub page you opened at the start had a new commit yesterday.
Affaan Mustafa is still building.