ECC Review: What to Borrow and What to Review First

ECC Review: What to Borrow and What to Review First

ECC is a useful source of agent-harness patterns, but it should not be installed as a trusted default. Review the exact version, select the smallest relevant components, inspect every executable or connected surface, and test the result in an isolated project before giving it access to real code or credentials.

The project appeared in Venture Step episode 111A under its former name, Everything Claude Code. It now lives at affaan-m/ECC and has expanded beyond Claude Code. The current repository describes support for Codex, OpenCode, Cursor, Gemini, and other harnesses alongside its original Claude-oriented assets.

This review covers ECC 2.0.0 at commit 6a9f075, committed July 26, 2026. The repository changed again after that commit. Readers should expect counts, behavior, and installation paths to move.

The short assessment

ECC is not an Anthropic product, an OpenAI product, or an official standard. It is a large, MIT-licensed community project maintained in public.

Its strongest value is architectural. It demonstrates how a team can separate persistent instructions, scoped rules, repeatable skills, explicit commands, specialized agents, lifecycle hooks, memory, security checks, and orchestration. The repository also contains documentation and validators that make those surfaces inspectable.

Its primary weakness is the other side of that breadth. ECC is no longer a collection a user can understand by skimming a few prompt files. It includes installers, executable scripts, hooks, optional MCP connections, cross-harness adapters, session persistence, and worktree tooling. Adopting the whole system creates a meaningful trust and maintenance commitment.

What was actually reviewed

The pinned checkout identifies itself as package ecc-universal version 2.0.0 under the MIT license. Its own release material describes 261 skills in the 2.0 release. The checked-out tree contained 67 agent files, 94 command files, 122 rule files, 281 validated skill directories, 21 hook matchers, 34 install modules, 81 install components, and seven profiles.

Those numbers are not a quality score. They describe surface area.

The repository's structural validators passed in the review environment. They checked Unicode safety, agent files, command files, rule files, skill directories, hooks, install manifests, and personal absolute paths. The built-in harness audit reported 31 checks with none failing. A focused installer test suite passed 32 of 32 cases, including dry-run behavior, preservation of existing Claude settings, conflict reporting, profile installation, and Cursor and Antigravity targets.

The complete npm test command was started, but the editorial review process did not capture a clean final exit before its outer timeout. The focused results above should not be inflated into a claim that every repository test passed.

No test result establishes that ECC is safe for every environment. The review did not connect production accounts, install optional MCP servers, run every agent, or assess every external dependency.

The capability surface

flowchart TD
    A["Pinned ECC checkout"] --> B["Read instructions and manifests"]
    B --> C["Inventory scripts, hooks, MCP, and write targets"]
    C --> D["Select one minimal component"]
    D --> E["Dry run in an isolated repository"]
    E --> F["Inspect diff and runtime output"]
    F --> G{"Acceptable authority and evidence?"}
    G -->|No| H["Remove or revise"]
    G -->|Yes| I["Adopt with owner and version pin"]

This is a better adoption path than copying the whole repository into an active project.

What is worth borrowing

The first useful pattern is separation of concerns. ECC does not ask one instruction file to be an architecture guide, release procedure, security policy, and task tracker at the same time. That matches current official guidance from Anthropic and OpenAI, even though each harness loads configuration differently.

The second is explicit validation. The project includes scripts that validate its agents, commands, rules, skills, hooks, and install manifests. A configuration pack should be able to check its own structure before asking a user to trust it.

The third is an install dry run. The reviewed installer tests cover plans that show intended operations without applying them. A dry run is valuable when an installer may write to project or user configuration, but it is only useful if the user reads the plan and independently checks the resulting diff.

The fourth is cross-harness honesty. ECC's own compatibility documentation distinguishes native Claude Code hooks from instruction-backed behavior in Codex and adapter-backed behavior elsewhere. A shared concept does not imply identical enforcement.

The fifth is treating verification as part of the workflow. Review agents, test commands, pre-commit checks, and stop-phase audits reinforce the point Dalton makes in the episode: output becomes easier to trust when evidence appears with the work.

What requires the most scrutiny

Hooks deserve the first review because they can run without a new natural-language request. At the pinned version, the hook graph covers events such as PreToolUse, PostToolUse, SessionStart, PreCompact, Stop, and SessionEnd. The documented behaviors include preflight checks, formatting, test suggestions, context persistence, session summaries, cost tracking, and notifications.

Some of those behaviors are helpful. They also execute Node scripts, read event payloads, influence context, and in some cases can block a tool action. Anthropic's hooks guide notes that hooks have different lifecycle semantics and that PostToolUse cannot undo an action that already happened. A hook needs review at both the configuration and script level.

MCP configurations deserve similar attention. A server definition can expose an external service, local process, credential, or data path to the agent. ECC's current repository makes many connectors optional, which is preferable to enabling a large default set. Users still need to review the package source, endpoint, environment variables, permissions, and data handling for every server they activate.

Installers come next. The focused tests show care around preserving some existing files and reporting conflicts. That is evidence for the tested scenarios, not a promise about an unusual repository. Run a dry plan, back up or commit existing configuration, and inspect every changed path.

Finally, review update behavior. A pinned configuration can be evaluated. A moving branch that updates itself can change instructions and executable code after the review. Decide who approves upgrades and how changes are tested.

The security boundary

Google's research on agent-facing files explains why plain text belongs inside the software supply-chain boundary. Instructions can steer tools and priorities. Runtime files can redirect traffic or change permissions. Extensions can gain broad local access.

That research does not accuse ECC of malicious behavior. It establishes the standard any community agent pack should meet.

Read what instructs, what executes, what connects, and what extends. Search for external URLs, environment-variable access, shell execution, install paths, telemetry, persistence, and settings that suppress prompts or warnings. Run dependency and secret scans appropriate to the project. Keep production credentials out of the evaluation environment.

Who should use it

ECC is most useful to someone who already understands their coding harness and wants a broad reference implementation. That user can compare patterns, extract a focused rule or skill, and evaluate the implementation rather than treating popularity as proof.

It may also help a team designing an internal agent platform. The repository exposes many design questions in one place: scoping, packaging, compatibility, permissions, memory, review, and orchestration.

It is a poor first step for someone who has not yet established basic project instructions and tests. Adding hundreds of configurable surfaces can make a simple repository harder to understand. Start with the official harness documentation and one concrete failure in your own workflow.

It is also a poor fit where the organization cannot review third-party scripts, plugins, and connectors. In that environment, copying a large community pack creates an ownership problem rather than solving one.

A selective adoption sequence

1. Pin a commit or release and record the date reviewed.

2. Read the license, root instructions, install manifest, changelog, and compatibility documentation.

3. Inventory every file that instructs, executes, connects, persists, or installs.

4. Choose one problem from your own repository. Select only the rule, skill, validator, or workflow that addresses it.

5. Run the supported dry plan in a clean test repository without production credentials.

6. Inspect the planned and applied diff. Confirm what was preserved, merged, skipped, and created.

7. Run the project's validators and your own build, test, security, and runtime checks.

8. Assign an owner and refresh trigger. Record the source commit beside the adopted component.

9. Expand only when a new need appears and the prior component has proved useful.

This sequence turns ECC into a source library rather than a source of inherited authority.

Final assessment

ECC 2.0.0 is ambitious, unusually broad, and more disciplined than the phrase “prompt collection” suggests. Its organization, validators, dry-run paths, and compatibility notes are worth studying.

The same breadth prevents a blanket recommendation. There is too much executable and connected surface to treat the repository as harmless configuration. Borrow the architecture. Review the implementation. Keep the authority narrow.

For the information architecture behind that advice, read [[How to Structure Repository Instructions for Coding Agents]]. For the individual component roles, continue to [[Rules Commands Skills Hooks and Agents Explained|Rules, Commands, Skills, Hooks, and Agents Explained]].

Verification and disclosure

This review was performed on July 27, 2026 against ECC 2.0.0 at commit 6a9f075cd97c139a5f7e84e1e3f2c9ab095adf64, the repository's source and documentation, current GitHub metadata, focused local validators and installer tests, current Anthropic and OpenAI documentation, Google's security analysis, and the E111A transcript.

Repository contents, ownership, dependencies, commercial offerings, popularity, and compatibility can change. The review is not a security certification. AI assisted with research organization and drafting; evidence boundaries and final editorial decisions remain Dalton Anderson's.