Everything Claude Code Deep Dive: Adding Rules, Verification, and Learning to Coding Agents

In one sentence

Everything Claude Code, now offered as ECC, is an open source toolkit for shaping a coding agent's work with reusable skills, development rules, lifecycle hooks, memory, and learning workflows.

Repository: affaan-m/ECC

Do you keep asking your coding agent to find existing implementations, run the tests, and explain why it changed something? Everything Claude Code is worth exploring when you want those repeated instructions to become part of your development environment. It includes task-specific skills, shared rules, and checks that can run at defined points during work.

Our earlier Superpowers deep dive focused on connecting requirements, implementation, and review. With ECC, look at which rules and tools you want to attach to that process. You can begin with one useful procedure, as with mattpocock/skills, then consider recurring research, verification, and memory. If you evaluate both systems, compare their instructions for overlapping stages before combining them.

We suggest starting with a small feature you maintain regularly. File upload validation is a useful candidate: there are existing implementations and libraries to investigate, and success and failure can be distinguished. Follow whether research informs the plan and verification appears in the completion report. That will tell you more about ECC's fit than installing a large catalog of rules.

What can you do with it?

ECC configures the working practices of an existing coding tool. The README describes a progression through planning, testing, implementation, review, verification, memory, and improvement. Available capabilities depend on the installation method and the host tool. Claude Code is a useful starting point for understanding the components because it is the project's primary supported path.

The skills/ directory contains guidance for research, test-driven development, frontend patterns, database changes, verification, and other tasks. Skills provide procedures to load when relevant. The agents/ directory defines specialized roles such as planning and code review, while commands/ supplies slash-command entry points. The README describes a move toward skills while maintaining existing command entry points.

The rules/ directory provides common standards and optional language-specific packs. A TypeScript project can begin by reviewing the common and TypeScript rules. A skill explains how to approach a particular task; rules provide continuing guidance for the environment where they apply. Compare them with your repository's contribution instructions before adding them.

Hooks connect executable behavior to events such as session startup or tool use. They can prepare context or attach checks during work. Read an instruction document and an executable hook as different additions to your environment. Knowing which hooks are enabled, their runtime requirements, and whether failures interrupt work makes changes after installation easier to explain.

Memory and learning features handle information worth retaining after a task. Session summaries, reusable procedures, and small learned behaviors serve different purposes. A learned instinct records a trigger, an action, supporting evidence, and confidence. Related instincts can be developed into reusable workflows. Decide what information should reach the next task before enabling the full learning setup.

When browsing the component catalog, start with a current bottleneck. Perhaps planning requires repeated explanation, completion reports omit verification, or the same troubleshooting steps keep being rediscovered. Choose the relevant component, establish that it is actually loaded or executed, then consider the next addition.

Installation and a first session

The repository formerly found under Everything Claude Code now uses affaan-m/ECC. Its Claude Code plugin identifier is ecc@ecc, and its npm package is ecc-universal. These identifiers serve different purposes. Begin with the current installation instructions so older, longer plugin identifiers do not get mixed into a new setup.

The universal package requires Node.js 18 or newer. Claude Code plugin setup also requires Git and Claude Code 2.1 or newer on PATH. The README provides the following guided setup command. Before running it, note any existing installation and decide where the new configuration should apply; the setup flow lets you choose scope and hook settings.

npx ecc-universal@2.2.3 setup

You can alternatively use Claude Code's native plugin commands. Run these inside Claude Code, rather than in your shell. Guided setup and native plugin installation are alternative ways to configure the same plugin. Choose one installation path for each host tool.

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

Start a new Claude Code session and use the following command to see whether ecc@ecc is enabled. If an existing installation or conflicting scope produces an error, resolve that scope first. Copying another layer of files into the environment can make the installation harder to understand.

/plugin list

Plugin installation and rule installation are separate. The README explains that Claude Code plugins cannot distribute rules and recommends adding only the packs you need. Its example for common and TypeScript rules is below. Read those files and compare them with your repository's instructions before copying them.

git clone https://github.com/affaan-m/ECC.git
cd ECC
mkdir -p ~/.claude/rules/ecc
cp -R rules/common ~/.claude/rules/ecc/
cp -R rules/typescript ~/.claude/rules/ecc/

These rules go into a user directory and may affect other projects. Start with the packs you actually use. The README also cautions against layering a full manual Claude installation on top of the plugin. Keeping a short record of installation method, scope, and selected rules helps teammates compare environments.

For the first conversation, ask the agent to inspect the project and narrow the task before editing. The following is an illustrative request for identifying relevant evidence, rather than an installation command. Compare the returned paths and test commands with the actual repository.

I want to work on file uploads in this project.
Find the existing input validation, error handling, and tests first.
Suggest only the ECC procedures relevant to this change.
Do not edit files yet. List the files you read and decisions still needed.

Scenario 1: Connect research to a plan before writing a utility

Suppose you need to validate upload extensions and file sizes. Even this short request leaves decisions about browser validation, server validation, and existing dependencies. ECC's search-first skill guides investigation of existing implementations and tools before choosing to adopt, extend, or build a solution.

Start inside the repository, then expand to the necessary official documentation and packages. The workflow also asks whether relevant search channels are available. If the environment can inspect local code but cannot query a package registry, that limitation belongs in the research result. Finding no candidate and being unable to search for candidates lead to different decisions.

We need extension and size validation for file uploads.
Find reusable validation and error responses in this repository first.
If another tool is needed, compare candidates using official docs and licenses.
Explain the choice between reuse, a small extension, and custom implementation.
Separate the sources you searched from the sources you could not access.

The useful output is a decision with reasons. If an existing dependency already supplies the capability, ask why another package is needed. Even a suitable external tool may bring unnecessary installation and maintenance costs for a small validation task. The skill explicitly addresses taking on dependencies that are too large for the need.

After research, connect the result to planning. ECC's plan command restates requirements, grounds the plan in repository patterns, outlines steps and risks, and waits for confirmation. This provides a place to agree on input conditions and failure responses before implementation, particularly when the change crosses several files.

Build an implementation plan from the research findings.
Use the product's existing file-type and size limits.
Connect server validation failures to the UI error feedback,
and map each file change to a way of verifying normal uploads still work.
Put unresolved decisions first and wait for approval before editing.

Read the plan for actual repository conventions. An invented service layer or an unused test framework is an early correction to make. The official command asks for file-backed examples of naming, error handling, logging, data access, and tests. Those references help a teammate assess whether the proposal fits the project.

Then follow both success and failure paths through the plan. What should the screen show when the server rejects a file? What happens when the user selects the same file again? These are review questions for the upload scenario. Keep only the behavior the product needs within scope, rather than accepting every suggested edge case as a new requirement.

The advantage is an opportunity to review the choice before code changes accumulate. Research can recommend reuse while a disconnected plan quietly introduces a new implementation. Reading the selected approach, affected files, and verification together helps reveal that mismatch early.

Scenario 2: Read completion as build, test, and change evidence

Once the upload feature is implemented, a completion message without evidence leaves important questions open. Did only the screen change? Does the server reject invalid input? ECC's verification-loop skill separates build verification, type checks, lint, tests, security checks, and diff review, then reports the results.

Connect those categories to commands the repository actually defines. The skill provides examples for different tools, but each project has its own setup. Running an example test command in a project without that script does not establish feature behavior. Completed checks need execution results, while missing checks need an explicit next step.

Organize the implementation results using verification-loop's review categories.
Use commands actually defined in this repository and read their exit results.
Separate build, type, and lint checks from upload success and failure behavior.
Include changed files, failed checks, and items that could not be performed.
Keep real customer files and authentication data out of the logs.

For each claim, follow the evidence that supports it. A build establishes that the application can be compiled, type checking examines declared type relationships, and tests exercise their written conditions. Their scopes differ. Connect upload error feedback to a test or reproduction of that behavior, even when the build passes.

When a check fails, narrow the cause. The next action differs depending on whether the change introduced the error, the error already existed, or the execution environment is missing a prerequisite. If repairing an existing issue would expand the task significantly, surface that separately. Failed checks should remain visible in the final report rather than disappearing into a long log.

Diff review also means reading files outside the plan. If upload validation changed authentication or payment configuration, the reviewer needs an explanation. The official workflow asks for unintended changes, missing error handling, and edge cases. Where a small refactor appears alongside the fix, establish its connection to the feature or consider reviewing it separately.

Look at how hooks and final verification interact. A hook runs at a particular point and catches issues within that scope; a final check covers the completed change. A quiet editor does not replace the final build result. Also watch for unnecessary repetition of the same expensive check. With existing CI, define who runs each check, when, and where the result is retained.

Set security-check reporting to fit the environment. If a search finds a sensitive value, retain the relevant path and masked information instead of reproducing it in a full log. An absence of scanner warnings and approval of a data transfer have different meanings. Manage code sent to models and access to connected services through the host tool as well.

Clear verification makes the next review more concrete. A reviewer can follow oversized-file responses, normal-upload regressions, and unplanned changes rather than asking whether everything works. For the first pilot, we suggest tracing one requirement all the way through implementation and evidence, instead of judging the length of the report.

Scenario 3: Turn repeated conventions into reusable procedures

During the upload work, perhaps you repeatedly explain that errors should use the shared module and that user-facing messages should be separated from internal diagnostics. ECC's continuous-learning-v2 workflow describes turning session observations into small learned behaviors, then grouping related behaviors into reusable forms.

An instinct captures an action for a particular trigger. It carries information about its observations, domain, and confidence. The design also separates project-specific and global scope, helping keep a React project's conventions from being applied indiscriminately to a Python project.

Begin by asking whether the resulting guidance can be inspected and corrected. A temporary workaround can become a recurring mistake if it is preserved as a general rule. Review whether a behavior is an approved team convention, specific to one bug, or subject to an exception. A confidence value does not replace that approval.

Summarize the error-handling conventions we repeatedly applied in this task.
Separate reusable behavior from conditions specific to uploads.
Attach source files and applicability conditions to each proposal.
Exclude temporary workarounds and customer data.
Show a draft for review before promoting it into team guidance.

This is an illustrative request for reviewing reusable knowledge. Whether observation hooks and learning are active needs to be established from the chosen installation and hook configuration. A feature appearing in the catalog does not establish that it runs in every session. Knowing where observations are stored and who can read them helps define an appropriate rollout.

The official workflow describes observations containing prompts, tool use, and outcomes. Teams handling sensitive material should review storage and retention before enabling that flow. Consider whether reusable procedures need complete customer data or whether anonymized examples and rules suffice. Read a personal environment's learning output before moving selected guidance into a shared repository.

Project separation helps organize data, but it does not establish operating system isolation. Process access and storage shared with other coding tools require separate decisions. The README also discusses distinct data roots when memory hooks are used across environments. Decide which conventions should be shared and which conversation records should remain separate.

Once a procedure has repeatedly proved useful, it can become a team document or skill. Include inputs, steps, success conditions, and reasons to stop so another person can apply it in the right context. A rule to inspect the shared error module and success/failure tests during upload changes must evolve when those files move. Reusable procedures need an owner for maintenance.

Compare this with Hermes Agent's memory and skills. Hermes offers a way to think about continuity across conversations and recurring work. ECC brings attention to observations and development guidance inside a coding environment. Deciding whether your immediate need is conversational continuity or reusable repository procedures helps narrow the starting point.

What to examine in a first pilot

Choose a small change and collect the outputs from research, planning, implementation, and verification. Does the selected candidate appear in the plan? Do failure conditions reach the tests? Can you locate their evidence in the completion report? Before making speed claims, establish whether the outputs help teammates decide what to do next.

Keep the installation configuration beside those results. Rules and hooks change the context an agent receives and the behavior executed during work. Comparing responses becomes difficult if one teammate has only the plugin while another has layered a full manual installation on top. Keep the installation path and chosen components narrow during the pilot.

Observe overlaps with existing instructions. Two skills may require different plan formats for the same stage or repeat the same review. Define which artifact the team will use for its decision before adding more instructions. Choosing useful procedures is part of adopting ECC.

The pilot should leave decisions you can use in the next task: a research procedure to retain, commands needed for verification, duplicate rules to remove, and learning features to defer. Understanding a small configuration makes expansion to another project or coding tool easier to assess.

Which teams should consider it?

Strengths: ECC is worth exploring for builders and teams repeatedly explaining the same development practices or improving the connection between research, planning, and verification. You can select skills and language rules, with a path for developing recurring work into reusable procedures. Understanding component responsibilities makes it possible to begin with a current bottleneck.

Operating effort: Someone needs to read rules and skills, resolve conflicts, and review updates. Hook runtime, additional model calls, and loaded instructions affect cost and workflow. Memory and learning introduce retained information and conventions to maintain. Start by limiting the features actually used and the outputs someone will review.

Host support: The README identifies Claude Code as its primary stable path and documents support levels and limitations for other tools. A shared catalog does not imply identical hooks, role invocation, or rule loading. Read the support matrix for the team's host and its missing capabilities.

License and cost: ECC is MIT licensed. Preserve the license conditions when modifying or redistributing it, and review terms for external tools and materials separately. Coding tools, model services, and optional connections have their own costs. Include those execution services in the budget alongside the effort of maintaining the open source configuration.

Sources and further reading

Wrapping up

The Hypemarc Builder Community will keep sharing the AI tools and open source projects we explore. We'll continue gathering useful resources to share with fellow builders.

Open chat: AI Builders
Adoption advice and inquiries: Contact form
Get the next post: Blog RSS · AI resource library