How to Install Everything Claude Code (ECC): Claude Code Setup and Best Practices

Sep 7, 2026 - Last update: Sep 8, 2026

Everything Claude Code ECC installation for Claude Code with plugin skills agents hooks memory and security

The most common question about Everything Claude Code (ECC) is also the one with the most contradictory answers online: what is the safest, most sensible way to install it for Claude Code without blindly enabling everything?

The direct answer: install ECC as a Claude Code plugin, choose a minimal or balanced set of components first — planning, testing, code review, and verification — run ECC’s AgentShield scan before relying on the setup, and expand later, one component at a time. More components do not automatically mean better results; context overhead and overlapping rules can make Claude Code noisier and more expensive.

One thing to internalize before reading further: ECC evolves quickly, and past tutorials have mixed commands from different generations of its tooling. This post separates each command into the layer it belongs to — in-chat plugin commands, npm-based CLI tools, and scripts that only run inside a clone of the repository. Treat the current ECC README as the source of truth for the exact command set, and re-check it before any major change.

Quick Install

Recommended for most Claude Code users.

Open Claude Code in a project directory and run these two in-chat commands in order:

Step 1  /plugin marketplace add https://github.com/affaan-m/ECC
Step 2  /plugin install ecc

Then verify that the plugin is listed and enabled:

/plugin

That is the entire path for most people — no clone, no Node.js, no manual file copying. One warning up front: do not install the same ECC components through two paths. If you use the plugin, do not also run a CLI or manual installer that copies the same skills and rules, or you will end up with duplicates. The rest of this post explains the alternatives, what ECC actually adds, and how to verify, update, and uninstall safely.

Before You Install

Claude Code installed and working — check it with claude --version.
Node.js and npm/npx — only if you plan to use ECC’s npm-based CLI tools or AgentShield. The plugin path itself does not require you to run Node.
Git — only if you clone the ECC repository, which is needed for repository-internal tooling or for following any documented manual rule-placement steps. Normal plugin users do not need to clone anything.
A scratch project directory where you can safely test the setup.

I deliberately do not list version minimums here: the ECC repository updates them often, so check the current README instead of trusting an old number. You also do not need to know where Claude Code stores plugin files — you verify through Claude Code itself, not by editing its internal directories.

Which ECC Install Method Should You Use?

ECC installation methods for Claude Code comparing plugin CLI repository tools and legacy setup

ECC is distributed several ways, and the safest install starts with a clear picture of what each path is and when it applies.

Method	Status	Best For	Notes
Claude Code plugin	Recommended	Most users	In-chat commands managed by Claude Code’s plugin system
CLI installer (npm/npx)	Alternative	Scripted or manual setups that avoid the plugin	Command syntax has changed across ECC releases; verify the current form in the README
Repository scripts (`doctor`, `repair`, `uninstall`, inside the repo)	Repository / contributor tooling	Developers who have cloned the ECC repo	Not part of the normal end-user install path
”Install everything” one-liners and older install scripts	Legacy	Evaluation environments or experienced users who want the fastest possible exploration	Highest risk of unnecessary components, overlapping rules, and context bloat; not a sensible daily setup

The governing principle is narrower than “only ever use one method”:

Avoid installing the same ECC component through multiple paths unless the documentation explicitly says those paths are designed to coexist.

Duplicates of the same skill, rule, or hook are the real problem — not the number of tools you happen to use. It is normal, for example, to use the plugin alongside your own project-local CLAUDE.md, because ECC does not own your CLAUDE.md. It is risky to install the plugin and then run a CLI install that copies the same components, or to stack two full harnesses that both manage skills and hooks. Distinguish “installing the same thing twice” from “using different tools that each own different things.”

Install ECC with the Claude Code Plugin

Inside Claude Code, run:

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

What happens:

The first command registers the ECC repository as a plugin marketplace.
The second command downloads and enables the ECC plugin from that marketplace.

Claude Code manages where plugin content is stored. Do not build workflows around an internal path such as ~/.claude/plugins/ or ~/.claude/plugins/cache/: that directory layout is an implementation detail of Claude Code and can change, so it is not a stable interface you should depend on. Instead, verify through the plugin manager (see “Verify ECC Is Installed” below).

After the plugin is enabled, Claude Code exposes its content to sessions automatically, and the plugin path does not require you to hand-edit settings.json or CLAUDE.md. If your Claude Code version asks you to restart or reload the session after enabling a plugin, it will tell you — follow that prompt.

One detail you should confirm per version is how rules are handled. Whether the ECC plugin distributes rules automatically — and whether your version needs you to place shared rules manually — depends on the current release, so check what the ECC docs say for your install method. If manual placement is documented, follow those exact steps from a repository clone, copy only the rule directories you need, and confirm the target directory in the current docs rather than assuming a path from an older post. Do not copy internal repository directories blindly, and do not manually copy rules if your version already bundles them through the plugin — that is how rules end up double-loaded.

Alternative: Install ECC with the CLI (npm/npx)

If you prefer a command-line install instead of the plugin manager, ECC has shipped npm-based installer tooling that runs through npx. The important caveat is that the package name and syntax have changed across releases — earlier versions documented a package along the lines of ecc-install, while other releases moved to an ecc install subcommand style with composable flags such as --with and --without. Both forms have appeared in ECC’s history, and both may not exist in the release you are using.

Because of that, do not copy a CLI one-liner from a blog post, including this one. Open the current README’s install section and use the exact command it shows. As an illustration of the general shape, an older documented form looked like this:

# Illustrative example from an earlier ECC release — verify the current syntax.
npx ecc-install --profile core --target claude

What the flags generally mean:

--profile <name> selects a documented component profile.
--target claude tells the installer which assistant to configure.
--with / --without add or remove capabilities, languages, and frameworks in releases that use the newer ecc install style.

If the README for your version points to the plugin instead, use the plugin. The plugin is the path this post recommends because it is managed by Claude Code itself, which makes install, update, and uninstall more predictable.

Repository-Only Tooling: Scripts Inside the ECC Repo

The ECC repository contains internal scripts such as node scripts/ecc.js doctor, node scripts/ecc.js repair, node scripts/ecc.js list-installed, and uninstall helpers. These are source-repository tooling: they only make sense after you have cloned the repository, and they are aimed at contributors, maintainers, and people debugging a local clone. They are not a normal verification step for an end-user installation and should not be presented as one. If you installed ECC through the plugin or an npm tool, use the verification and diagnostic methods described in this post instead of reaching for scripts that require a clone.

Choose What to Enable: Official Profiles vs This Article’s Tiers

The real decision is not “how do I run the command” but “how much do I enable.” To make that decision well, keep two separate things apart: ECC’s own documented profiles, and the editorial tiers used in this post.

Official ECC profiles are the names the repository’s tooling actually defines. Profiles documented in ECC around the time of writing include core, developer, security, research, and full — but profile names and flags change as the project evolves, so verify the current list in the README. If the installer your version ships with offers a guided profile picker or recommendation flow, prefer that over re-creating a configuration scheme from a blog post.

This article’s editorial tiers — Minimal, Balanced, and Power user — are a decision-making framework for thinking about how much to enable. They are an approximation, not an official mapping, so treat the table below as guidance rather than a one-to-one translation:

Editorial tier	Typical starting point	What it usually emphasizes
Minimal	A small profile such as `core`	Planning, testing, code review, verification
Balanced	A developer-oriented profile, or a minimal base plus a few added capabilities	Adds memory, security, continuous learning, and a handful of specialized skills
Power user	The broadest profile, or many composed capabilities	Orchestration, many agents, MCP integrations, language- and framework-specific skills, advanced hooks

My advice for a first install: pick a minimal or balanced scope, not the broadest one. Planning, testing, code review, and verification give you workflow discipline without turning every chat into a slow, token-hungry session. You can always add components later, and removing them is more work than adding them.

Use ECC’s Component Advisor If Your Version Ships It

Some ECC releases include a component advisor that answers, in plain language, which profiles and capabilities fit a workflow you describe — for example, asking about “security reviews” before expanding a setup. This is genuinely useful: you decide based on a recommendation instead of defaulting to “install everything.”

That said, the advisor has appeared under different names and invocation styles in different releases (in some periods as an npx-based command along the lines of npx ecc consult "security reviews"). Verify that the advisor exists in your release and use the exact invocation from the current README. If your version does not ship it, skip it — you can still discover what the plugin provides through the plugin manager and through normal conversation with Claude Code.

When it is available, the workflow I use is:

Describe the workflow I want, for example “mlops training model deployment.”
Read what it recommends.
Install only the recommended profile and capabilities.
Re-run the advisor a few days later before adding anything new.

What ECC Adds to Claude Code

ECC installs Claude Code artifacts you may want to inspect later:

Skills: reusable instructions for common tasks, usually triggered on demand.
Agents: specialized sub-agents for planning, review, security, and more.
Rules: project-behavior rules, typically kept in a rules location Claude Code loads.
Hooks: scripts that run on events; these change behavior, so treat them carefully.
Commands: only in versions that register them — discover the actual names in your install rather than assuming a fixed prefix.
Memory: learned patterns and session notes.
MCP configuration: mcp.json entries if any MCP servers are enabled.

You do not need to know every file. To manage the setup, you only need the plugin manager, an understanding of which components you enabled, and the ability to ask Claude Code what ECC content is available in the current session.

Verify ECC Is Installed

Verify through observable, supported interfaces rather than by poking at internal cache directories:

Check the plugin manager. Run /plugin and confirm Everything Claude Code appears as installed and enabled. Open its detail or help view to see what the plugin registers in your version.
Exercise one skill in a scratch directory. Ask Claude Code, in plain language, to use ECC’s planning skill on a small task, and confirm it actually runs a planning workflow instead of answering generically.
Run a scan if your version ships AgentShield (see below). A clean scan is a good post-install signal.

What “success” looks like: the plugin is listed in /plugin, a requested ECC skill runs without errors, and the setup behaves the way you asked it to. The repository-internal scripts mentioned earlier are only relevant if you are working from a clone; they are not the verification path for a plugin or npm install.

First Practical Workflow

To see the pieces work together, use a realistic task: add input validation to an existing REST API endpoint.

The ECC-enabled loop looks like this:

Plan -> Tests -> Implement -> Review -> Verify -> Save knowledge

In practice, and to avoid fabricating commands that may differ in your version, drive it with natural language plus skills:

Ask Claude Code to use the planning skill, and describe the endpoint.
Ask it to create or update tests using the TDD skill.
Implement the change, then ask for a code review pass covering quality and security.
Ask it to verify the result against the tests.
Finish by asking it to save what was learned to memory.

If your ECC build registers slash commands, you will see them listed in the plugin manager — this post deliberately does not list fixed command names, because they change between versions and a hard-coded list is exactly the kind of detail that goes stale. The point of the loop is to show how skills, agents, commands, and memory interact after installation.

Run AgentShield

ECC ships a security scanner called AgentShield. It reviews the .claude/ configuration surface used by your setup: prompts and CLAUDE.md files for secrets and injection patterns, hooks for command injection, MCP configuration for risky servers, permissions and allow lists in settings.json, and agent definitions for unrestricted tool access. Think of it as a config review and front-door check, not a runtime sandbox and not a guarantee — it cannot prove that a skill or hook is safe to execute.

Like the rest of the CLI tooling, AgentShield’s package name and commands have varied across releases, so use the invocation from the current README. Recent releases have provided a scan command that runs without an install, for example through npx:

# Verify the current package name and flags in the ECC README.
npx ecc-agentshield scan

Some versions offer an auto-fix mode. If you use it, treat it as a modifying operation:

Warning: run git status first and review every change after --fix. Prefer a clean git tree, back up or commit first, and read the diff before accepting changes, because auto-fix can edit config files and therefore change agent behavior.

I run a scan after any install or update, and again after adding new skills or MCP servers. Honest limitation: model-assisted scanning depends on the model doing a good job, so treat it as a useful check, not a warranty.

Avoid Context Bloat: Installed vs Actually Loaded

The most common reason a harness setup feels slow or expensive is too much context, not bad code. But it helps to be precise about the mechanism, because “installed” and “loaded” are not the same thing:

Installed components sit on disk and cost nothing until something pulls them into a session.
Enabled components are available to Claude Code, which is different from being injected into every prompt.
Always-loaded rules enter the prompt on every session and are the main fixed cost.
Dynamically loaded skills are read when a relevant task triggers them.
MCP tool descriptions are exposed to the model and add context whenever those servers are connected.
Active hooks add runtime overhead and behavior changes even though they do not consume prompt tokens.

So installing many skills does not, by itself, equal a bloated context window. What actually drives context growth is which rules are always in the prompt, which MCP servers are connected, which agents are always active, and how much duplicated instruction you have across packs.

Practical guidance that follows from this:

Enable only components relevant to the current project.
Keep always-on rules focused; remove rules you no longer use.
Use profiles intentionally instead of stacking capability flags.
Disconnect MCP servers you are not using.
Do not stack overlapping skill packs without testing.

I do not promise specific token savings, because the number depends on your project, model, and prompts. The direction is clear, though: less always-loaded content, fewer surprises.

Mixing ECC with Other Claude Code Skill Packs

A common question is whether ECC can run together with Superpowers, Anthropic’s skills, or Matt Pocock’s skills. They are not inherently incompatible, but stacking them is risky: the failure modes are overlapping instructions, duplicate workflows, conflicting review rules, naming conflicts, and extra context overhead.

What I recommend:

Add one system at a time.
Test behavior for a few days before adding another.
Cherry-pick specific components instead of installing multiple full harnesses.
If behavior turns noisy, remove the newest pack first.

I do not claim any two projects are incompatible, because that is not proven. Treat it as an integration risk to manage, not a hard rule.

Updating ECC

For the plugin path, use Claude Code’s plugin manager to update the ECC plugin from its marketplace — open /plugin and use the update action your version exposes. If you installed through the CLI, follow the update method documented for the exact release you are on, and note that re-running an installer does not always preserve customizations, so back up anything you changed first.

Do this after any update:

Confirm the new version in the plugin manager.
Read the release notes before a major update.
Run AgentShield again, because rules and hooks can change behavior.

Hooks and rules are behavior-changing by design, so treat major updates like a config migration, not a silent patch.

Uninstalling ECC Safely

Safe ECC uninstall paths for Claude Code plugin CLI and custom rules without deleting other configuration

Uninstalling is the place where bad advice does the most damage, so follow the path that matches how you installed. Never move or delete Claude Code’s entire plugin cache, and never delete your whole .claude directory — that would remove unrelated plugins and configuration. Back up only ECC-specific custom files, not Claude Code’s entire plugin cache.

Plugin users: use Claude Code’s own plugin manager (the /plugin view or its Extensions view), find Everything Claude Code, and choose Uninstall. That removes the plugin without touching other plugins.
CLI users: use the uninstall command documented for the exact release and install method you used, and check whether it supports a dry-run or preview first.
Copied rules and custom files: remove only the files you placed for ECC, such as rules you copied into a rules namespace or mcp.json entries ECC added. Keep a backup of anything you are unsure about before deleting.

A repository-internal uninstall.js script may exist for people working from a clone; it is not the right way for an end user to remove a plugin install. When in doubt, prefer the smallest removal that matches your install method.

Troubleshooting

Prefer observable checks over internal file paths. The plugin manager, the current release notes, and the ECC troubleshooting guide are the first places to look.

Problem	Likely Cause	What to Check
ECC skills not visible	Plugin not enabled, or wrong install path for the version	Run `/plugin` and confirm the plugin is enabled; check the plugin’s detail view
Hooks not running	Permission or config issue in the current release	Check the plugin’s documented hook settings and Claude Code’s own diagnostics
Behavior became noisy	Too many overlapping rules or packs	Reduce rules; remove the most recently added pack
Token and context usage increased	Always-on rules, many MCP servers, or duplicated instructions	Disconnect unused MCP servers; trim always-loaded rules
Mixed skill packs conflict	Duplicated workflows	Add one pack at a time; remove the newest pack
Update changed behavior	Version or config migration	Read the release notes; re-run AgentShield

For deeper diagnosis, the ECC docs and troubleshooting guide describe the current health-check flow for your install method. The repository’s doctor and repair scripts exist for people working from a clone, so use them only in that context.

Recommended Setup for Most Developers

A concise checklist for a first-time ECC install:

Start with the plugin path: /plugin marketplace add https://github.com/affaan-m/ECC, then /plugin install ecc.
Choose a minimal or balanced scope: planning, testing, code review, and verification first.
Verify through /plugin, and exercise one skill in a scratch project.
Run AgentShield before relying on the setup.
Add memory or specialized components later, one at a time.
Do not install everything on day one, and do not install the same components through two paths.

FAQ

How do I install Everything Claude Code?

Run /plugin marketplace add https://github.com/affaan-m/ECC then /plugin install ecc inside Claude Code. A CLI install is available as an alternative, but verify its current syntax in the README.

Is ECC installed globally or per project? Can I install it only for one project?

A plugin install applies at the Claude Code level you install into, which makes its content available across your projects. If you want ECC to stay limited to one project, keep that project’s CLAUDE.md and enabled components focused, and avoid enabling broad skills globally. Confirm the scoping behavior for your version in the current docs.

Does the ECC plugin modify CLAUDE.md?

No — the plugin keeps its content in Claude Code’s managed plugin area rather than rewriting your project’s CLAUDE.md. If you manually place ECC rules, you may add files under a rules location that Claude Code loads alongside your CLAUDE.md.

Does installing ECC overwrite existing Claude Code config?

It should add components rather than overwrite your settings, but ECC can register hooks and MCP configuration that change behavior. Review what the installer adds, back up anything you customized, and run AgentShield after installing.

How do I check which ECC components are active?

Use /plugin to confirm the plugin is enabled and open its detail view, then ask Claude Code what ECC skills are available in the current session. Do not count files in internal cache directories as a health check.

Can I install ECC without Node.js?

For the basic plugin path, yes — you do not need Node to install or enable the plugin. The npm-based CLI tools and AgentShield require Node.js because they run through npx.

Does ECC work with existing Claude Code hooks?

Claude Code hooks from different sources can coexist, but multiple hook sets can conflict or duplicate work. Add one system at a time, review the hooks ECC registers, and test before relying on them.

Do I need AgentShield?

It is not required to run ECC, but it is recommended after installs and updates, because rules and hooks change behavior. Treat it as a configuration review rather than a guarantee of safety.

Should I install every ECC skill? Does ECC increase token usage?

No. Install only what matches your workflow. Context grows with what is actually loaded per session — always-on rules, connected MCP servers, active hooks — not merely with how many skills are installed. Minimal or balanced profiles keep the increase small. I avoid exact token numbers because they depend on your setup.

How do I uninstall ECC?

Use the plugin manager to remove the plugin, use the documented uninstall for a CLI install, and delete only the ECC-specific rules or mcp.json entries you placed. Never move the entire plugin cache or delete your whole .claude directory.

Can I use ECC with Superpowers or other skill packs?

Possibly, but add one system at a time and test. Overlapping instructions and duplicate workflows are the main risks.

Is ECC safe to use?

ECC is an open-source harness you install intentionally. Run AgentShield, review the rules and hooks it adds, and do not enable everything at once.

Summary

In this post, I showed how to install Everything Claude Code for Claude Code the sensible way. The key point is to install selectively: use the plugin as the primary path, start with planning, testing, code review, and verification, keep official profiles separate from editorial tiers, verify through the plugin manager, run AgentShield, and expand only after testing. Avoid installing the same components twice, update and uninstall through the supported mechanisms, and never touch Claude Code’s entire plugin cache. More components do not mean better results.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 ECC Repository (GitHub)
👨‍💻 ECC Selective Install Design
👨‍💻 ECC Troubleshooting Guide
👨‍💻 What Is Everything Claude Code (ECC)? Skills, Agents, Hooks, Memory and Security Explained

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!