The Complete ECC Configuration Suite: All 8 Modules

Episode 3 covered ECC’s 8 modules at a high level. This is the deep cut. I’ll walk through every module with current numbers, show the directory structure of a production config, and explain the architecture split that keeps your context window from exploding.

ECC (Everything Claude Code) is a configuration framework that sits on top of Claude Code. One install command:

claude /plugin install everything-claude-code@everything-claude-code

It ships 8 modules. Together they contain over 400 individual components. But the design is opinionated about what loads automatically and what waits until you ask for it. That distinction is the single most important thing to understand.

The Architecture Split

Two categories. Get this right and everything else makes sense.

Auto-loaded (consumes tokens on every session):

CLAUDE.md
Rules
Hooks
MCP

On-demand (zero cost until invoked):

Agents
Skills
Commands
Memory

Auto-loaded modules eat context tokens whether you use them or not. A bloated CLAUDE.md with 50 imported rules burns thousands of tokens before you type your first prompt. On-demand modules sit dormant. An agent with 200 lines of instructions costs nothing until you call it. Then it spins up in its own isolated context window.

This matters because Sonnet 4.6’s 100M context window is generous but not free. Every token you spend on configuration is a token you can’t spend on your actual work.

Module 1: CLAUDE.md (2 Layers)

Your AI’s operating manual. Two layers, each with a clear job:

System layer — ~/.claude/CLAUDE.md Global instructions that apply to every project on your machine. Who you are, how you work, tools you’ve installed, personal preferences. Keep it under 200 lines.

Project layer — ./CLAUDE.md (at project root) Project-specific context: tech stack, architecture decisions, deployment flow, team conventions. This layer takes priority when it conflicts with the system layer.

~/.claude/CLAUDE.md          # "I'm a Python dev, I use pytest, I hate semicolons"
~/my-project/CLAUDE.md       # "This is an Astro site on Cloudflare Pages, deploy via git push"

Write three things in each: identity (who you are and what you’re building), constraints (what’s forbidden), and workflow (how you want the AI to operate). Skip everything else until you feel the pain.

Module 2: Rules (34 Rules, 9 Categories)

Rules are markdown files in ~/.claude/rules/ and .claude/rules/. They load automatically at session start. Nine categories ship by default:

Coding style — immutability, KISS, DRY, YAGNI, naming conventions
Testing — TDD workflow, 80% minimum coverage, AAA pattern
Git workflow — conventional commits, PR format, branch strategy
Security — no hardcoded secrets, input validation, SQL injection prevention
Code review — severity levels, checklist, mandatory review triggers
Performance — model selection, context window management, build troubleshooting
Patterns — repository pattern, API response format, skeleton projects
Hooks — hook types, auto-accept permissions, TodoWrite practices
Agents — orchestration strategy, parallel execution, multi-perspective analysis

Then there are language-specific rulesets: 4 rules each across 11 ecosystems (TypeScript, Python, Go, Rust, Java, and more). That’s 44 additional rules available.

The optimization: in your CLAUDE.md, only @import the language rules you actually use. A Python-only project doesn’t need TypeScript, Go, and Rust rules consuming tokens every session. This single change can cut 60% of wasted rule overhead.

Module 3: Agents (48 Specialized Agents)

Each agent runs in its own isolated context window — roughly 50K tokens per agent. The main conversation doesn’t pay for an agent’s context until you invoke it.

Six categories:

Category	Count	Key agents
Code review	10	code-reviewer, typescript-reviewer, python-reviewer, security-reviewer
Build errors	7	build-error-resolver, test-failure-debugger, dependency-resolver
Planning	3	planner, architect, tdd-guide
Testing & refactoring	4	e2e-runner, refactor-cleaner, doc-updater
Ops & coordination	3	chief-of-staff, loop-runner, config-tuner
Specialized	21	brand review, customer ops, cost auditing, UI/UX review

My daily rotation: code-reviewer, security-reviewer, planner, build-error-resolver, and chief-of-staff. Five agents. The other 43 sit on the bench until I need them.

Invoke any agent by name in your prompt. Claude Code handles the dispatch:

Review this PR for security issues using the security-reviewer agent.

Module 4: Skills (183 Capability Packs)

Skills are the lightest-weight extension. They execute inside the main conversation — no separate context window, no spawn overhead. If a skill can handle the job, don’t reach for an agent.

Seven categories:

Core workflows (7): plan, code-review, tdd, security-review
Language patterns (14): Python, TypeScript, Go, Rust idioms
Framework patterns (20+): Next.js, Astro, Django, FastAPI, Rails
Database & infra (7): PostgreSQL, Redis, Supabase, Docker
Content operations (20+): article-writing, SEO, humanizer, brand-voice
Security & quality (10+): OWASP checks, dependency audits, license scanning
Advanced specializations (100+): browser automation, PDF generation, image generation, video editing

Skills auto-invoke based on trigger conditions. You don’t explicitly call gemini-image-gen — you say “generate an image of a mountain landscape” and the skill activates because the trigger matches. The skill file format is straightforward:

---
name: my-custom-skill
description: What this skill does (Claude reads this to decide when to trigger)
---

## Trigger Conditions
When the user asks for X or Y...

## Workflow
1. First step
2. Second step

## Constraints
- Always do A
- Never do B

Module 5: Commands (79 Slash Commands)

Type / in Claude Code and you see the full list. Commands are user-triggered — you decide when to invoke them.

Most-used in my workflow:

Command	What it does
`/plan`	Generate implementation plan before coding
`/code-review`	Run code review on uncommitted changes
`/tdd`	Start test-driven development cycle
`/security-review`	Scan for vulnerabilities
`/simplify`	Review changed code for reuse and efficiency
`/feature-dev`	Guided feature development with all stages

Zero token cost until you type the slash.

Module 6: Hooks (20+ Automation Scripts)

Hooks are code, not prompts. That’s the line that separates them from everything else. A CLAUDE.md instruction can be ignored. A hook cannot. It runs as a real script before or after tool execution.

Six event types:

Event	When it fires	Example
PreToolUse	Before tool execution	Block `rm -rf /`, prevent writes to protected files
PostToolUse	After tool execution	Auto-format saved files, strip console.log
SessionStart	Session initializes	Load project context, check dependencies
Stop	Session ends	Save session summary, log token usage
UserPromptSubmit	User submits input	Inject reminders, validate input format
PreCompact	Before context compaction	Preserve critical information

Three strictness profiles:

export ECC_HOOK_PROFILE=minimal    # Only block dangerous operations
export ECC_HOOK_PROFILE=standard   # Balanced (default)
export ECC_HOOK_PROFILE=strict     # Confirm every change

Start with minimal. Move to standard after a week. strict is for production codebases where a wrong file write costs real money.

Module 7: MCP (14 External Connectors)

MCP (Model Context Protocol) connections to external services. Each one takes 0.5-2 seconds to initialize at startup.

Code collaboration: GitHub, Supabase, Vercel
Search & research: Exa, Context7, Brave
Browser automation: Playwright, Browser Harness
Local tools: Filesystem, SQLite
AI enhancement: Sequential Thinking, Memory

All 14 active means 7-28 seconds of startup latency. I run 6 daily and toggle the rest on when I need them. Edit ~/.claude/settings.json to add or remove connections.

Module 8: Memory (4 Types)

Cross-session persistence. Stored in ~/.claude/projects/<hash>/memory/ with a MEMORY.md index file that auto-loads.

Type	What it stores	Example
User	Personal preferences	”Simon prefers Baskerville for serif fonts”
Feedback	Corrections you’ve made	”Don’t use Claude in Chrome, use browser-harness”
Project	Architectural decisions	”BossDown uses Astro + Cloudflare Pages”
Reference	External resource pointers	”Deploy server SSH: see password manager”

Memory compounds. After 50 sessions, your Claude Code instance knows your preferences, your past mistakes, your project history. Session 51 starts dramatically smarter than session 1.

The Directory Structure

A well-configured ECC setup looks like this:

~/.claude/
├── CLAUDE.md                  # Global operating manual
├── settings.json              # MCP connections, permissions, model preferences
├── rules/
│   ├── common/                # 9 universal rule files
│   │   ├── coding-style.md
│   │   ├── testing.md
│   │   ├── git-workflow.md
│   │   └── ...
│   └── servers.md             # Custom rules
├── agents/                    # 48 agent definitions
├── skills/                    # 183 skill packs
├── commands/                  # 79 slash command definitions
└── projects/
    └── <hash>/
        └── memory/
            ├── MEMORY.md      # Index file (auto-loaded)
            ├── project_*.md   # Project memories
            └── feedback_*.md  # Correction memories

Where to Start

Don’t configure all 8 modules on day one. That’s a trap. Start with three:

CLAUDE.md — write 50 lines about who you are and how you work
3 rules — coding-style, git-workflow, and testing are the highest-value defaults
1 MCP — GitHub, if you write code. Notion, if you manage projects.

Use that setup for a week. You’ll feel friction points — “I wish it would auto-format after saves” (add a hook), “I need it to review my PRs” (invoke the code-reviewer agent), “I want a quick way to start TDD” (use the /tdd command).

Each friction point tells you which module to add next. That’s how you build a config that works instead of one that looks impressive in a screenshot.