Everything Claude Code: the story of ECC and what is worth learning from it

The hackathon helps explain why ECC attracted attention. The more durable lesson, however, is the attempt to turn good habits into a small, explicit, and verifiable system for working with agents.

It started with a curious story

Over the last few days, I started seeing the same repository everywhere. GitHub, X, LinkedIn, videos, and developer discussions kept repeating the name Everything Claude Code, now also presented as ECC.

My first impression was simple: this must be another huge prompt repository. But when I started researching it for a video, I found a more interesting story.

It involved a hackathon organized by Forum Ventures with Anthropic, a product built under pressure, and a way of working with Claude Code that was later organized and expanded in public. That story became the first part of the video.

After recording it, another question stayed with me: what is truly worth learning from this repository once the initial curiosity fades?

What happened at the hackathon

In September 2025, Forum Ventures held an AI agents hackathon in New York with Anthropic. The organizers described a ten-hour event with more than 75 technical builders moving from an idea to a working demo.

Affaan Mustafa and David Rodriguez participated as a team. According to David’s published account, they placed first among 22 teams with a product called PMF Probe, now presented as Zenith.

The idea was to help founders with customer discovery: someone presented a product, talked with synthetic personas, and then compared those hypotheses with signals from real users. Zenith’s current page shows a full-stack platform using Next.js, FastAPI, Supabase, Claude, Google Cloud Run, and Gemini as a fallback.

The awarded product was PMF Probe, now Zenith. The current ECC repository came later and grew far beyond that environment. The hackathon provides context for the way of working; it does not make the entire current repository the competition-winning project.

From individual experience to a public system

What caught my attention was not only the win. It was learning that Affaan had organized and published much of the environment he had been building to work with Claude Code.

When you open the repository, you find specialized agents, skills, rules, hooks, commands, memory, MCP configurations, scripts, tests, documentation, and adapters for different tools.

That is where the comparison with an “operating system” for agents comes from. I understand the metaphor, but I prefer a more precise description: ECC works as an operational layer and a library of decisions for organizing how agents work.

1plan2  -> test3  -> implement4  -> review5  -> verify6  -> preserve context7  -> improve the process

The problem ECC tries to solve

If you use AI for development, you have probably opened a new conversation, explained the project, requested a feature, and only later remembered rules, tests, and validations that should have been there from the beginning.

• The plan disappears into chat history.
• The agent implements before understanding the context.
• Tests and security depend on a manual reminder.
• Review happens in the same context that wrote the code.
• The session ends and part of the reasoning disappears.

The problem is not only that the model forgets an instruction. Important practices still depend on the memory of the person writing the prompt. ECC tries to turn recurring lessons into artifacts that can be read, versioned, invoked, and verified.

The question shifts from “what is the best prompt?” to “what is the smallest system that helps the agent work with context, responsibility, and evidence?”.

The technical map of ECC

To understand the repository without touring hundreds of files, it helps to separate the layers by function and context behavior.

• Rules keep durable policies and standards in context.
• Skills load knowledge or workflows when the task needs them.
• Agents separate responsibility, context, and tools.
• Commands provide explicit entry points for workflows.
• Hooks react to events outside the model’s reasoning.
• Memory preserves decisions, evidence, and next steps.
• Tests, evals, and CI produce verifiable evidence.
• Adapters translate part of the system to other harnesses.

These pieces do not have the same cost or risk. A rule can remain in context, a skill can load on demand, an agent can receive its own tools, and a hook can run outside the prompt. Calling all of them “prompts” hides the differences that matter.

Four ideas worth studying

1. Rules and skills are not the same thing

Rules fit truly durable project policies: do not include secrets, validate inputs, follow error-handling conventions, and respect scope. Skills fit situational processes such as TDD, security review, bug investigation, or a verification loop.

Context is a budget. More instructions do not automatically mean more quality; sometimes they mean more conflict, noise, and less room for the real problem.

2. A specialized agent needs to change something real

A planner can explore the project and produce a plan without editing. An implementer receives the approved plan and changes only the necessary scope. A reviewer returns in read-only mode and looks for regressions, authorization flaws, and missing tests.

Changing only the persona name does not create architecture. A specialized agent starts making a difference when context, goal, responsibility, tools, permissions, or exit criteria change.

3. Hooks help, but CI decides

Hooks can remind the agent of a practice, block a dangerous pattern, run formatting, check types, or record state. This reduces dependence on the model remembering everything, but a local hook can be disabled, fail, or not exist in another harness.

A probabilistic model proposes and executes. Deterministic automation proves. The agent can say it tested; the pipeline needs to show the result.

4. Useful memory is not an infinite transcript

Saving everything also saves noise, wrong hypotheses, and instructions that perhaps should never cross sessions. ECC itself treats recalled memory as unreviewed context, not executable policy.

1Goal: add authentication to admin routes2Decision: reuse the existing middleware3Evidence: integration tests passed locally4Discarded attempt: in-memory-only session5Pending risk: review role-based authorization6Next step: validate routes in the test environment

Good memory is not remembering everything. It is keeping visible what was decided, what was verified, and what still needs to happen.

How these pieces can form a workflow

1short, project-specific AGENTS.md2  + common rules and rules for the real stack3  + planning or TDD skill on demand4  + planner, implementer, and reviewer5  + official verification command6  + small hook for a clear local risk7  + handoff when the task crosses sessions

For a bug fix, the planner records the hypothesis, scope, and acceptance criteria. The TDD skill guides a test that reproduces the problem. The implementer makes the smallest necessary change. A hook runs a quick check. The reviewer inspects the diff in a separate context, and the official command runs build, types, and tests.

The result is not only code. It is a trail of evidence: plan, failing test, passing test, review, validation, and final state. To me, that is the most interesting part of ECC.

Why I would not install everything

The name is Everything Claude Code, but the worst possible conclusion would be that the goal is to use everything. A large catalog can be useful as a library and still create problems when adopted as a monolithic package.

• Too many rules consume context and can conflict.
• Too many skills make discovery and maintenance harder.
• Duplicate agents create roles without real differences.
• Hooks expand the local execution surface.
• MCPs expand tools, permissions, and context usage.
• Memory can preserve incorrect or contaminated information.
• Overlapping installations can duplicate commands and automation.

I see ECC more as a library of decisions than a magic button. It is worth studying a rule, a reviewer contract, the relationship between a hook and CI, or a handoff model. That is different from handing your entire environment to hundreds of files you have not read.

Compatibility does not mean parity

ECC started closely associated with Claude Code and still has its most complete surface there. The project also provides paths for Codex, Cursor, OpenCode, Gemini, and other harnesses, but each environment loads instructions, discovers skills, runs hooks, configures agents, and requests approval differently.

Any tutorial therefore needs to confirm the ECC version, the target harness, and which capabilities actually work in that combination. During this research, the latest stable release found was v2.1.0, while main already documented parts of a guided flow associated with the 2.2 line.

For the second, more technical video, I will validate commands against the version shown before recording any installation or preview.

More capability also means more responsibility

Everything that makes an agent more capable also deserves to be treated as part of the security surface. Rules carry instructions, skills can bring scripts, hooks execute actions, MCPs connect tools, memory crosses sessions, and agents receive permissions.

ECC includes AgentShield to analyze agent configurations, hooks, MCPs, permissions, secrets, and possible injection risks. The scanner is a supporting layer, not a replacement for reading, isolation, and human review.

• Install only from official sources.
• Choose one installation method per harness.
• Preview the change plan when a dry run is available.
• Review files that execute code.
• Limit rules and skills to the real project and stack.
• Treat memory as untrusted context until reviewed.
• Keep mandatory validation in CI.
• Know how to remove or revert what was installed.

What I learned from studying ECC

• The model does not work alone: context, tools, permissions, tests, and workflow also shape quality.
• A repeatable process is worth more than a memorized prompt.
• Context needs to be treated as a budget.
• Specialization needs to change the contract, responsibility, or permission.
• Verification needs to produce evidence through builds, tests, diffs, and CI.

These lessons remain useful even for people who never install ECC. That is why the repository is worth studying as an architecture reference.

What is coming in part 2

The first part of the video told the story. In the second, I want to open the repository and show four ideas concretely, without trying to teach a complete installation in five minutes.

1. Common rules and stack-specific rules.
2. A TDD or verification skill loaded on demand.
3. A planner, implementer, and reviewer with different responsibilities.
4. A local hook paired with an equivalent CI check.

Conclusion

The hackathon story is a strong hook. It shows Affaan Mustafa and David Rodriguez turning an idea into a working product under pressure, with AI as part of the process. But ECC’s more durable lesson comes afterward.

It lies in the idea that an agent’s behavior can be designed with context, roles, automation, memory, and verification. This does not remove technical responsibility; the more capability we place around the model, the more we need to understand what stays in context, what executes code, who changes files, and where evidence exists.

It is not about installing everything. It is about turning good habits into a small, explicit, and verifiable system.