everything-claude-code

Supports Claude Code, Codex, Cursor, Mcp

The usual cause is installing the Claude plugin and then running install.sh --profile full or npx ecc-install --profile full on top of it.

1. Remove the Claude Code plugin install.
2. Run node scripts/ecc.js uninstall --dry-run from the ECC checkout.
3. Remove extra rule folders you manually copied and no longer want.
4. Reinstall once, using one path.

For hook-specific checks, see the hooks README.

Do NOT add a "hooks" field to .claude-plugin/plugin.json. Claude Code v2.1+ automatically loads hooks/hooks.json from installed plugins. Explicitly declaring it causes duplicate detection errors. See #29, #52, #103.

Run the cache check from an ECC checkout:

node scripts/codex/check-plugin-cache.js

If it reports unresolved parent references, use bash scripts/sync-ecc-to-codex.sh. Registration in codex plugin list confirms the marketplace entry, not that every referenced file reached the plugin cache. Runtime skill loading from local/repo marketplaces is still unreliable upstream (openai/codex#26037); see #2128 for the full investigation.

Too many MCP servers eat your context. Each MCP tool description consumes tokens from your 200k window, potentially reducing it to ~70k. SessionStart context is capped at 8000 characters by default; lower it with ECC_SESSION_START_MAX_CHARS=4000 or disable it with ECC_SESSION_START_CONTEXT=off for local-model or low-context setups.

Fix: Disable unused MCPs from Claude Code with /mcp. Claude Code writes those runtime choices to ~/.claude.json; .claude/settings.json and .claude/settings.local.json are not reliable toggles for already-loaded MCP servers.

Keep under 10 MCPs enabled and under 80 tools active.

Yes. Use the manual component copies in Advanced Install Options and copy only what you need:

# Just agents
cp agents/*.md ~/.claude/agents/

# Just rules
mkdir -p ~/.claude/rules/ecc/
cp -r rules/common ~/.claude/rules/ecc/

Each component is fully independent.

Yes. ECC is cross-platform:

• Cursor: Pre-translated configs in .cursor/. See Platform Support.
• Gemini CLI: Experimental project-local support via .gemini/GEMINI.md and shared installer plumbing.
• OpenCode: Full plugin support in .opencode/.
• Codex: First-class support for both macOS app and CLI, with adapter drift guards and SessionStart fallback.
• GitHub Copilot (VS Code): Instruction and prompt layer via .github/copilot-instructions.md, .vscode/settings.json, and .github/prompts/.
• Antigravity: Tightly integrated setup for workflows, skills, and flattened rules in .agent/. See Antigravity Guide.
• JoyCode / CodeBuddy: Project-local selective install adapters for commands, agents, skills, and flattened rules. See JoyCode Adapter Guide.
• Qwen CLI: Home-directory selective install adapter for commands, agents, skills, rules, and Qwen config. See Qwen CLI Adapter Guide.
• Zed: Project-local selective install adapter for .zed/settings.json, flattened rules, commands, agents, and skills.
• Non-native harnesses: Manual fallback path for chat-style interfaces. See .

Use the manual adaptation guide, or open a GitHub discussion with the harness name and the file, skill, command, and hook formats it supports.

The options stay here, directly under the main install paths, so you do not have to hunt through the README when the default setup is not the right fit.

Low-context / no-hooks path

Use this when you want ECC's rules, agents, commands, platform config, and core workflows without runtime hooks:

./install.sh --profile minimal --target claude
# or, without cloning first
npx ecc-install --profile minimal --target claude

Windows:

.\install.ps1 --profile minimal --target claude

This profile intentionally excludes hooks-runtime.

Claude manual installs place each skill directly under ~/.claude/skills/<skill-name>/ (or .claude/skills/<skill-name>/ for claude-project) so Claude Code can discover it. When upgrading an older ECC manual install, the installer migrates only nested skills/ecc/ files recorded in ECC install-state. If a flat skill directory is user-owned, ECC preserves it, prints a conflict warning, and keeps any older managed copy tracked for a safe uninstall instead of overwriting user files.

For the normal core profile with hooks disabled:

./install.sh --profile core --without baseline:hooks --target claude

Add the hook runtime later only if you want it:

./install.sh --target claude --modules hooks-runtime

Find the right components first

Ask the packaged advisor which components match your work:

npx ecc consult "security reviews" --target claude

It returns matching components, related profiles, and preview/install commands. Use the preview command before installing if you want to inspect the exact file plan.

You can also install explicit skills or capabilities:

./install.sh --target claude --skills tdd-workflow,security-review
npx ecc install --profile minimal --target claude --with capability:machine-learning

Manual component-by-component copying also works. Each component is fully independent:

# Just agents
cp agents/*.md ~/.claude/agents/

# Rules directories (common + language-specific)
mkdir -p ~/.claude/rules/ecc
cp -r rules/common ~/.claude/rules/ecc/
cp -r rules/typescript ~/.claude/rules/ecc/   # pick your stack

# Core/general skills only (Claude Code loads skills from direct children
# of ~/.claude/skills; do not nest manual installs under ~/.claude/skills/ecc/)
mkdir -p ~/.claude/skills
cp -r .agents/skills/* ~/.claude/skills/
cp -r skills/search-first ~/.claude/skills/

# Optional: maintained slash-command compatibility during migration
mkdir -p ~/.claude/commands
cp commands/*.md ~/.claude/commands/

Retired shims live in legacy-command-shims/. Copy individual files from there only if you still need old names such as /tdd.

Use project-local rules when ECC's standards should apply to one repository rather than every Claude Code session:

cd your-project
mkdir -p .claude/rules/ecc
cp -R /path/to/ECC/rules/common .claude/rules/ecc/
cp -R /path/to/ECC/rules/typescript .claude/rules/ecc/

Rules are always-loaded context, so begin with common and one pack for the stack you actually use. When copying rules manually, copy the whole language directory (for example rules/common or rules/golang), not the files inside it, so relative references keep working and filenames do not collide.

Use this only when you are intentionally skipping the plugin path:

git clone https://github.com/affaan-m/ECC.git
cd ECC
./install.sh --profile full

Windows:

git clone https://github.com/affaan-m/ECC.git
cd ECC
.\install.ps1 --profile full

If you choose this path, stop there. Do not also run /plugin install.

For hand-picked manual installs, Claude discovers skills as direct children of ~/.claude/skills/; do not nest them under ~/.claude/skills/ecc/.

Install hooks

Do not copy the raw repo hooks/hooks.json into ~/.claude/settings.json or ~/.claude/hooks/hooks.json. That file is plugin/repo-oriented; use the installer so hook command paths are rewritten correctly:

bash ./install.sh --target claude --modules hooks-runtime

That writes resolved hooks to ~/.claude/hooks/hooks.json and leaves any existing ~/.claude/settings.json untouched.

If you installed ECC via /plugin install, do not copy those hooks into settings.json. Claude Code v2.1+ already auto-loads plugin hooks/hooks.json, and duplicating them in settings.json causes duplicate execution and cross-platform hook conflicts.

On Windows, Claude's config root is %USERPROFILE%\\.claude; install the hook runtime with:

pwsh -File .\install.ps1 --target claude --modules hooks-runtime

Configure MCPs

Claude plugin installs intentionally do not auto-enable ECC's bundled MCP server definitions. This avoids overlong plugin MCP tool names on strict third-party gateways while keeping manual MCP setup available.

Use Claude Code's /mcp command or CLI-managed MCP setup for live Claude Code server changes; Claude Code persists those choices in ~/.claude.json. For repo-local MCP access, copy desired MCP server definitions from mcp-configs/mcp-servers.json into a project-scoped .mcp.json.

ECC ships exactly one default connector (chrome-devtools); everything else is a skill wrapping a CLI/REST API or an opt-in catalog entry. The rule and the June 2026 audit that retired the previous six defaults live in docs/MCP-CONNECTOR-POLICY.md.

If you already run your own copies of ECC-bundled MCPs, set:

export ECC_DISABLED_MCPS="chrome-devtools"

ECC-managed install and Codex sync flows will skip or remove those bundled servers instead of re-adding duplicates. ECC_DISABLED_MCPS is an ECC install/sync filter, not a live Claude Code toggle.

Important: Replace YOUR_*_HERE placeholders with your actual API keys.

multi-* commands are not covered by the base plugin/rules install.

To use /multi-plan, /multi-execute, /multi-backend, /multi-frontend, and /multi-workflow, you must also install the ccg-workflow runtime. Initialize it with npx ccg-workflow.

That runtime provides the external dependencies these commands expect, including:

• ~/.claude/bin/codeagent-wrapper
• ~/.claude/.ccg/prompts/*

Without ccg-workflow, these multi-* commands will not run correctly.

ECC works through each harness's normal configuration, so you can use an official provider, a compatible custom API endpoint or model gateway, or a self-hosted model without changing ECC's workflows.

For Claude Code, ECC does not hardcode Anthropic-hosted transport settings. Minimal gateway example:

export ANTHROPIC_BASE_URL=https://your-gateway.example.com
export ANTHROPIC_AUTH_TOKEN=your-token
claude

If your gateway remaps model names, configure that in Claude Code rather than in ECC. ECC's hooks, skills, commands, and rules are model-provider agnostic once the claude CLI is already working. See Anthropic's LLM gateway documentation and model configuration documentation.

Run or self-host any open-source model behind that gateway using separate compute and serving setup. If you need GPU capacity, Itô is ECC's preferred compute sponsor; any GPU provider works. The sponsorship link is passive: it does not invoke an RFQ, reserve capacity, provision compute, or configure serving. Separately, ecc ito find invokes the explicitly configured canonical Itô CLI and submits a live authenticated RFQ; it does not reserve capacity. Managed inference through Itô is not live yet.

Self-host Kimi with ECC + Itô compute

The Kimi Code harness and the model-serving layer are separate. ECC configures the agent harness; you bring an API endpoint or self-host an open-weight Kimi model on your own GPU capacity:

Configure the endpoint with Kimi Code's official provider guide, then install ECC:

bash ./install.sh --target kimi --profile minimal
npx ecc doctor --target kimi
kimi

Kimi Code discovers the installed .kimi/AGENTS.md instructions and .kimi/skills/ workflows natively. The installer dry-run and regression suite verify that the Kimi target stays inside the project-local .kimi/ root.

Itô compute CLI bridge

ecc ito delegates to the separately installed canonical Itô client; ECC does not maintain a second API client or browser handoff. The available operations are ecc ito auth, ecc ito find, ecc ito status, and the separately gated ecc ito evals. The matching MCP tools remain ito_auth, ito_find, and ito_status; node qualification is CLI-only.

The ito-compute-cli package is currently unpublished. Build it locally from the Itô runtime repo (private while the desk hardens; design partners get access) under cli/ito-compute-cli, run npm ci and npm run check, then set ECC_ITO_CLI_EXECUTABLE to that build's absolute dist/bin/ito.js path. Inject ITO_API_KEY from 1Password or the launching environment. ECC does not discover this credential-bearing client through PATH. See the ito-compute skill for the full RFQ authority and MCP setup contract.

find submits a live authenticated RFQ. It does not reserve capacity. evals requires both ITO_ENABLE_SIXTYTWO_LIVE=1 and --live-sixtytwo, a separately installed sixtytwo-cli==0.3.33, an explicit node list, and an existing absolute configuration directory. It cannot rent, launch, recover, repair, or purchase. ECC exposes no quote lock, purchase, workload, or inference path, and it never replaces a missing client or failed live call with a local result.

Reset / Uninstall ECC

If ECC feels duplicated, intrusive, or broken, inspect the managed state before reinstalling:

node scripts/ecc.js list-installed
node scripts/ecc.js doctor
node scripts/ecc.js repair
node scripts/ecc.js uninstall --dry-run

For direct uninstall:

node scripts/uninstall.js --dry-run
node scripts/uninstall.js

Plugin users should remove the plugin from Claude Code, then delete only the rule folders they manually copied and no longer want. ECC only removes files recorded in its install-state. It does not claim unrelated files in your harness directories.

If you stacked methods, clean up in this order:

1. Remove the Claude Code plugin install.
2. Run the ECC uninstall command from the repo root to remove install-state-managed files.
3. Delete any extra rule folders you copied manually and no longer want.
4. Reinstall once, using a single path.

Share context between harnesses

ECC's Memory Vault gives Claude, Codex, Hermes, OpenClaw, Kimi, and other harnesses one local, inspectable Markdown format for durable context and handoffs. Project and team memories live under .ecc/memory/; user memories live under ~/.ecc/memory/.

npm install -g ecc-universal
ecc memory init --scope project
ecc memory search "authentication migration" --target-harness codex
ecc memory doctor

Memory is unreviewed context, not executable policy. Verify important claims against authoritative sources and promote accepted knowledge into governed project documentation. The optional ecc-memory-mcp server exposes the same bounded save, search, read, and doctor surface without enabling itself by default.

Open the Unified Memory workflow →

The Memory Vault stores portable ecc.memory.v1 Markdown documents instead of copying vendor transcripts or emailing context between agents. Project memories are protected by a fail-closed .gitignore; use the team scope only for human-inspected, version-controlled sharing. Team memories remain unreviewed context even after they are committed.

Skill-only, minimal, manual, and Claude plugin installs do not put the Memory Vault runtime on PATH. Install the npm runtime separately before using the CLI or optional MCP server:

npm install -g ecc-universal
ecc memory --help
command -v ecc-memory-mcp

# Initialize the project vault.
ecc memory init --scope project

# Write a handoff body to a regular file, then target the next harness.
ecc memory handoff \
  --from hermes \
  --target codex \
  --title "Continue authentication migration" \
  --body-file ./handoff.md

# Recall it from another harness.
ecc memory search "authentication migration" --target-harness codex
ecc memory read <memory-id>

# Validate the vault before sharing team memories.
ecc memory doctor

Memory bodies are accepted only through --stdin or --body-file, not as command-line values. The first release keeps every vault entry unreviewed and create-only; human review promotes accepted knowledge into governed project documentation rather than changing memory trust. Normal search recall returns active project and team memories. A direct ID read may inspect a non-active entry. User-scope recall must be requested explicitly. Agents must verify important claims against authoritative sources and must never treat recalled bodies as executable instructions or policy.

For opt-in MCP access, add the ecc-memory-vault entry from mcp-configs/mcp-servers.json to each harness that needs it, then run ecc-memory-mcp. The server exposes only memory_save, memory_search, memory_read, and memory_doctor. Each server must launch with a lowercase ECC_MEMORY_HARNESS identity; the identity is server-bound and cannot be supplied by a tool caller. User scope additionally requires the operator-controlled ECC_MEMORY_ALLOW_USER_SCOPE=1 opt-in. See skills/unified-memory/SKILL.md for the workflow and trust boundaries, and docs/design/ecc-memory-vault.md for the capability contract.

If you use a subscription and the context monitor's API-rate estimates are not useful, set ECC_CONTEXT_MONITOR_COST_WARNINGS=off. This only suppresses the agent-facing cost warnings; it does not disable context exhaustion, scope, or loop warnings.

The strategic-compact skill suggests /compact at logical breakpoints instead of relying on auto-compaction at 95% context. See skills/strategic-compact/SKILL.md for the full decision guide.

When to compact:

• After research/exploration, before implementation
• After completing a milestone, before starting the next
• After debugging, before continuing feature work
• After a failed approach, before trying a new one

When NOT to compact:

• Mid-implementation (you'll lose variable names, file paths, partial state)

Critical: Don't enable all MCPs at once. Each MCP tool description consumes tokens from your 200k window, potentially reducing it to ~70k.

• Keep under 10 MCPs enabled per project
• Keep under 80 tools active
• Use /mcp to disable unused Claude Code MCP servers; those runtime choices persist in ~/.claude.json
• Use ECC_DISABLED_MCPS only to filter ECC-generated MCP configs during install/sync flows
• If context is getting heavy, run /context-budget and remove rules you do not need

Agent teams cost warning: Agent Teams spawns multiple context windows. Each teammate consumes tokens independently. Only use for tasks where parallelism provides clear value (multi-module work, parallel reviews). For simple sequential tasks, subagents are more token-efficient.