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.
Open the GitHub page: 50K+ stars, 6K+ forks, 147 workflow skills, 36 subagent definitions, 997 tests running in CI, 7 language translations. Scroll down to the contributors section, thinking: at this scale, there’s got to be a five-person team at least.
One name.
Affaan Mustafa. Ten months.
Clawd butts in:
Okay, let Clawd 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?
Clawd wants to add:
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.
Clawd PSA:
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: Ten Months of Side Project Beats an Anthropic Competition
Let’s start with the punchline: 2025, Cerebral Valley x Anthropic hackathon. Affaan brought one component from ECC — AgentShield, a security scanning tool designed for attack surfaces unique to AI agents.
It won.
But the interesting part isn’t “it won.” It’s where AgentShield came from.
Hackathons have a recognizable smell: three days of panic coding, an MVP that barely holds together for the demo, two architecture questions from judges and it falls apart. AgentShield wasn’t that. It could embed into CI/CD, run as a skill inside Claude Code, cover prompt injection, sandbox escapes, and sensitive data leakage — that’s not three-day scope. That’s crystallized output from 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? AgentShield cleared those bars because it was never built for a hackathon.
50K stars sometimes just means “the README looks good.” A hackathon win means “the architecture survives questioning.” Different weight class.
Clawd OS:
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
Here’s a design decision that’s easy to miss.
The project is called Everything Claude Code. But dig into the repo structure, and OpenAI Codex has its own .agents/ and .codex/ directories. Cursor has rules and configurations ported over. OpenCode and Antigravity both have their own support.
Wait — why does something called “Everything Claude Code” support Codex?
Because Affaan isn’t building a “Claude Code plugin.” He’s building a system of AI agent best practices. Claude Code just happens to be the best execution environment right now. Think of it this way: he’s not building a loyalty program for one convenience store chain — he’s building a franchise playbook that currently runs under one brand’s sign.
That distinction matters. Cross-harness support forces the whole system to distill its concepts more cleanly — what’s tightly coupled to Claude Code, what’s a universal pattern? Skill structures designed well should work similarly across harnesses. Agent definitions clear enough should run with different models.
2025-2026 is the wild west era for AI harnesses, and nobody knows who’s still standing in two years. This design decision removes a potential ceiling: if Claude Code gets displaced someday, ECC’s 50K stars don’t go to zero.
Clawd going off-topic:
An open source author in a platform war has two paths: bet on the strongest harness and do deep integration, or make the methodology itself the moat — let 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: Seven Language Translations, Zero Budget
Here’s a contrast worth sitting with.
ECC uses the MIT license — fork, modify, redistribute, use commercially, all fine. Then the community translated it into 7 languages: Traditional Chinese, Simplified Chinese, Japanese, Korean, Portuguese, Turkish, and more in progress. Affaan didn’t pay anyone to do that.
Sounds like a dream, right? But there are millions of MIT-licensed repos on GitHub, and most of them can’t even get a single PR. MIT isn’t magic — it’s a ticket. Once inside, people still need a reason to stay.
Affaan made “worth it” very concrete: SKILL-DEVELOPMENT-GUIDE.md spells out architecture, testing patterns, and submission standards. 997 tests running in CI, so contributors know before submitting whether their change breaks anything. Monthly releases, so PRs don’t rot in an unreviewed queue.
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” — a completely different level of endorsement.
Clawd 's hot take:
“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
📚 ECC Deep Dive Series: This post covers the indie hacker story; the tech inside ECC is worth unpacking too. SP-151 on Eval-Driven Development, SP-152 on Token Optimization, SP-153 on Iterative Retrieval — worth reading together.
Back to that GitHub page from 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 browse those side projects on GitHub that started rotting in month three — most people missed at least one. Obvious and easy are not the same thing.
But there’s one more thing Affaan 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.”
That GitHub page from the start? It had a new commit yesterday.
Affaan Mustafa is still building.