Everything Claude Code Repo Audit: 286 Skills, a 21K-Token Index

A short video turns up late in the evening, saying a hackathon winner has given away his complete Claude Code setup. Next comes a thread with the same claim, then another, then several more. They all look alike: a few big numbers, a screenshot of the star counter and a link. One says 163K stars, another 214K, another 228K.

The figures don't even agree with each other, which is the first hint that nobody posting them opened the repo.

So here's what happens when somebody does open it. Not the README, the repo itself. Cloning it, running wc and a short Python script over it, and reading the parts that would matter to an iOS engineer gives a clear picture of what's inside, what's worth keeping, and one measurement that changes how it should be installed.

What ECC is

ECC stands for Everything Claude Code, a project by Affaan Mustafa under the MIT license. At the time of the check, the repo had roughly 247,000 stars, 37,200 forks, 2,631 commits and sat at version 2.2.1.

The pitch: Claude Code out of the box is a single assistant, and ECC turns it into a workflow of plan, test, implement, review, verify, remember and improve. Around that sits a memory vault, "instincts" (patterns kept across sessions) and a security scanner named AgentShield.

Installation takes one command:

npx ecc-universal setup

It needs Node 18+, Git and Claude Code 2.1+. Adapters exist for Codex, Cursor, OpenCode, Gemini, Zed and about a dozen others.

That's the marketing. Now for the contents.

Counting what's actually there

Skipping the numbers from the threads and counting directly gives this:

ls -1 skills | wc -l     # 286
ls -1 agents | wc -l     # 68
du -sh --exclude=.git .  # 94M

• 286 skills, one SKILL.md per folder
• 68 agents, markdown files whose frontmatter names the model and the tools they may use
• 94 legacy command shims, part of 426 command files overall
• 23 hook entries covering seven lifecycle events. Eight sit on PreToolUse and seven on Stop. PostToolUse, PostToolUseFailure and SessionStart get two each, while PreCompact and SessionEnd get one each
• 94 MB on disk, of which 23 MB is assets and 18 MB is docs

One detail is unexpected. The CLAUDE.md at the root of this 94 MB monument to configuration is 82 lines long, 531 words. The person who shipped 286 skills kept his own instruction file shorter than many private repos manage. That's no accident, and it matters again at the end.

The figure the threads skip

Before a skill can run, Claude Code has to know it exists. At startup it ingests each skill's name and short description as a catalog, and a skill's full body gets pulled in only at the moment it triggers. This lazy loading is called progressive disclosure, and the design is good.

The announcements still cost something, so they're worth measuring:

# name + description from every SKILL.md frontmatter
skills: 286  name+desc chars: 86,311  ~tokens: 21,577

That's about 21,500 tokens of skill index, spent before a single word of the actual problem has been typed.

For contrast, here's what sits behind the index:

• all 286 skill bodies: about 641,000 tokens
• all 68 agent definitions: about 110,000 tokens

Nobody will ever load 641K tokens, which is exactly what progressive disclosure is for, and it works. But the ~21.5K index is the entry fee for a full install, paid in every session. On a 200K window, more than 10% goes to a menu.

None of that is a criticism of ECC. It makes the case for the minimal profile that the repo itself offers:

./install.sh --profile minimal --target claude

The README even states it plainly: begin with rules/common plus one language pack that you really use. The loudest sharers of this repo skipped that line.

Six items an iOS engineer would keep

A search for anything Swift-shaped turns up cisco-ios-patterns first. That's a networking skill, and a fine reminder that "ios" makes a poor search term. After it, six real entries show up.

Type	Name
Agent	swift-reviewer.md
Agent	swift-build-resolver.md
Skill	swiftui-patterns
Skill	swift-concurrency-6-2
Skill	swift-actor-persistence
Skill	swift-protocol-di-testing

For anyone living in a mixed UIKit and SwiftUI MVVM codebase, that last group is worth reading even if the installer never runs.

Inside swift-reviewer

The expectation is a generic prompt along the lines of "you are a helpful Swift reviewer". It's nothing like that. The frontmatter pins the agent to sonnet and limits its tools to Read, Grep, Glob, Bash. Nothing in that set can modify files, which suits a reviewer perfectly.

Then comes the procedure:

1. Build and test first, using swift build, swiftlint lint --quiet (if installed) and swift test. A failure in any of them means the agent halts and reports instead of continuing.
2. Collect the change set with git diff HEAD~1 -- '*.swift', or git diff main...HEAD when reviewing a PR.
3. Look at modified .swift files and nothing else.
4. Begin the actual review.

The "if any fail, stop and report" rule is the part worth borrowing. Most review prompts cheerfully critique code that doesn't compile. This one refuses to burn tokens on a broken tree.

The CRITICAL tier reads like a list of things that experienced developers have shipped and regretted:

• force unwrapping in production paths
• try! without justification, and as! without a prior type check
• hardcoded secrets, including secrets kept in UserDefaults and not in the Keychain
• ATS exceptions with no justification
• empty catch {} blocks, and try? that swallows meaningful errors
• fatalError() for conditions the caller could recover from
• assert guarding an invariant that has to hold in release builds. Release builds strip it, so precondition is the right tool

That last assert versus precondition note is a genuinely senior observation. It gets missed in real pull requests, and in a securities company, "stripped in release" isn't an academic worry.

The swiftui-patterns skill follows the same pattern. It has a table for choosing property wrappers (@State, @Binding, @Observable, @Bindable, @Environment), and a clear argument for @Observable over ObservableObject: because changes are tracked property by property, SwiftUI redraws just the views that actually read whatever changed. The same knowledge exists in WWDC sessions. Having it in a file that can be handed to an agent is a different thing.

Where it stops being useful

The same ls that found the Swift skills also found entries like these:

customs-trade-compliance
energy-procurement
production-scheduling
quality-nonconformance
healthcare-cdss-patterns
healthcare-emr-patterns
healthcare-phi-compliance

Unless an energy procurement pipeline is under construction, none of that applies. These skills are somebody's real work, and it's decent of the author to ship them, but each one is a line in an index that gets paid for and never used.

Three other issues deserve an honest mention.

The plugin doesn't ship the rules. Installing ECC as a Claude Code plugin delivers agents, skills, hooks and commands automatically, but the rules have to be copied into .claude/rules/ by hand. So the promise of a single command comes with a chore tucked inside.

Installers don't stack. The README says again and again to use one method per harness. The duplicate-hook bug reports tend to come from people who combined the plugin with ./install.sh --profile full.

Twenty-three hooks widen the attack surface. Eight of them fire on PreToolUse, so each is code running locally before Claude edits any file. ECC doesn't hide this: the installer wants explicit consent before turning on hook execution, and AgentShield is included to scan prompts, hooks and MCP configs. That's the right attitude. It still leaves 23 items to read before agreeing.

Verdict

The star count isn't the story. Nobody clicks a 247,000-star repo after evaluating 286 skills. They click because a short video said to.

What actually matters is that the repo is excellent study material on organizing agent work, and a so-so package to install in full. A sensible plan looks like this.

Clone it, but don't install yet.

git clone --depth 1 https://github.com/affaan-m/ECC.git

Four files are worth opening afterwards: the reviewer agent at agents/swift-reviewer.md, the skill at skills/swiftui-patterns/SKILL.md, the hook config in hooks/hooks.json, and that short 82-line CLAUDE.md. Twenty minutes of reading there beats any thread about the repo for learning how agent definitions should be written.

Go minimal, not full. Keep the two Swift agents, the four Swift skills and rules/common. The index shrinks to a handful of entries that fit in your head, and the context cost is close to nothing.

Add one piece at a time, and only when a real problem calls for it.

The hint was in the repo from the start. The author who shipped 286 skills kept his own instruction file to 82 lines, and he doesn't load everything either. Nobody needs everything. What's needed is the handful that match the code actually being written.