mrkeyoor.com_
Wed 30 Sept 14:03 UTC
Open Source7 min read

ECC Adds 650 Stars for a 293-Skill Agent Workflow

ECC is drawing developers to a reusable process layer for coding agents, but its broad catalog, executable hooks, and uneven host support demand a selective install.

ECC added 650 GitHub stars on September 30 while offering no new model at all. The project wraps existing coding agents in 68 specialist roles, 293 skills and 94 compatibility commands. Its pitch addresses a less glamorous problem: a model may write code, yet the surrounding session can still forget how a team plans, tests and reviews. GitHub's current repository record puts ECC at 269,959 stars, so today's gain is activity on an already large project rather than a launch-day spike.

That attention is landing on the process around coding models. ECC was created in January and received another push on September 30, according to the same GitHub metadata. Its files try to make engineering habits portable across sessions and, with limits, across agent products. The repository's own support table is candid that Claude Code is the reference host while Codex, Cursor, OpenCode and Copilot receive different subsets.

ECC packages an engineering procedure

Every feature hangs from a repeatable loop. An agent plans a change, writes or runs tests, implements it, reviews the result, verifies the repository and stores useful context for later work. The README describes this as an installed engineering system, built from Markdown skills and agent definitions plus JavaScript hooks, installers, rules and memory tools. The value proposition is consistency, especially when a developer would otherwise paste the same instructions into each new chat.

The catalog is much broader than a coding checklist. The current tree includes workflows for test-driven development, security review, build repair, documentation, data work and several application frameworks. Skills are the primary interface, while the 94 commands remain as compatibility entries during a move toward skill-first use. ECC's documentation lists the 293 skills and 68 agents separately, an important distinction because an agent role and an invoked workflow do different jobs.

This also explains why star velocity is more interesting here than the raw total. Developers are responding to an attempt to standardize agent behavior above the model layer. A team can change its model or endpoint while keeping the same review sequence and repository instructions. ECC says its workflows use each host's existing model configuration, including compatible gateways and self-hosted endpoints, instead of choosing transport settings itself. The provider section documents that boundary.

The catalog does not have to fill the context window

A 293-skill bundle sounds like a prompt-budget problem. ECC partly avoids that by installing discoverable files and loading selected material when needed. The project also offers minimal and core profiles, optional language rule packs and a path with no hook runtime. Its installation guide says rules are always-loaded context, so it recommends starting with the common rules and one pack for the language or framework in use.

The runtime has explicit caps too. Session-start context defaults to 8,000 characters, and learned "instincts" default to six entries with a confidence threshold of 0.7. Project and stack relevance affect which memories surface first. These are implementation details, not proof that the selected advice is correct, but they show that the project treats context as a limited resource. The environment controls expose each limit.

MCP tools create a second source of context cost. ECC cut its default connector set from seven to one in version 2.2.0, leaving GitHub, Context7, Exa, memory, Playwright and sequential-thinking integrations as opt-ins. The changelog says native features or CLI-backed skills cover those jobs. That decision is more revealing than another addition to the catalog: the maintainers removed defaults after finding that a larger tool surface was not automatically a better one.

Claude Code remains the reference host

ECC's portability has a firm ceiling. Claude Code gets native agents, installed skills and plugin hooks. Codex gets a native skill set and a reviewed subset of hooks, but Claude agent files do not become Codex roles. Cursor uses project rules and an adapter for hook events. GitHub Copilot receives instruction and prompt files, with no ECC hooks or delegation. The cross-tool capability map labels every host except Claude Code as partial or outside the parity target.

The distinction changes how a team should evaluate the package. Testing a planning skill inside Claude Code does not establish that a Cursor hook blocks the same action, or that Copilot can delegate a review to a specialist role. ECC's Cursor notes even warn that project-agent loading varies by Cursor build. For Codex, the project supplies native marketplace commands and a cache check because registration alone does not prove that referenced skills and assets resolved correctly. The troubleshooting section separates those two checks.

Install paths can collide as well. The repository supports native plugins, a package installer and older copied-configuration flows, but it repeatedly tells users to choose one route per harness. Stacking the Claude plugin with a full manual installation can duplicate skills and hooks. Mixing Codex's marketplace plugin with the legacy sync path can create a similar ownership problem. ECC provides dry-run uninstall and repair commands, which are worth using before treating an odd agent response as a model failure.

Review the hook path before enabling it

The same hooks that enforce process can run shell commands, inspect tool calls and modify what reaches an agent's context. ECC requires an explicit choice before its installer enables the hook runtime. A low-context profile excludes hooks entirely, while other profiles stop before writing if the user has not selected an enable or disable option. The install documentation spells out that consent step.

That is the right level of caution because repository instructions now sit close to execution. ECC's own security section tells users to treat hooks, MCP servers and project instructions as executable configuration. Its separate security guide recommends isolating untrusted repositories in a container, virtual machine or remote sandbox, with network access constrained to the destinations a task needs. Installing a security workflow does not replace that host boundary.

AgentShield, ECC's optional scanner, examines secrets, permissions, hooks, MCP configuration and agent files. The README reports 102 static rules and 1,282 tests, but it also says the scanner must come from a separately installed and reviewed ecc-agentshield package. ECC does not provide an audited version pin for it. The AgentShield section makes that limitation explicit, which is more useful than treating an included scanner as a certificate for the rest of the system.

Main is ahead of the published package

There is a timely packaging wrinkle behind today's activity. ECC's current README and package.json use version 2.2.2, and the top commit on September 30 calls itself a 2.2.2 release sync. The changelog dates 2.2.2 to September 15 and describes a curated Pi profile, memory fixes, Windows work and two dependency security updates.

The published channels have not caught up. On September 30, the official npm registry record still marked 2.2.1 as latest, published on September 8, while GitHub Releases also stopped at v2.2.1. That means the README's pinned npx ecc-universal@2.2.2 examples describe a package the registry does not currently serve. Developers should check the registry version before copying the command and use a reviewed source checkout only when they intentionally want unreleased changes.

The lag does not erase the project's test and release work. Version 2.2.0 added manifest-based ownership, doctor and repair flows, cross-platform package checks and registry-byte verification before promotion. Its release audit covered 108 commits across 530 files. Those figures come from ECC's own release record, so they establish what the project says it tested rather than an independent certification.

Start with one host

ECC fits a heavy Claude Code user who wants one maintained opinion about planning, verification, memory and specialist roles. It can also help a team moving between agent products, provided that team writes down which behaviors must survive the move and tests each host separately. Our review of ECC covers the setup reality, including a fresh Debian install, the full repository test command and the cost of carrying thousands of files.

A smaller installation is the sensible first trial. Pick one harness, keep the hook runtime off until its scripts have been reviewed, then add the few skills that replace repeated work. The project's selective profiles and install-state ledger support that approach. ECC's README warns that full parity and stacked installs should not be assumed.

Watch the next published package rather than the next star milestone. The useful signals will be whether 2.2.2 reaches npm and GitHub Releases with the promised artifact checks, and whether broader host support closes documented gaps without making the catalog indiscriminate at install time. Until then, ECC's 650-star day says developers want a durable process around their agents. The repository still has to prove that the process remains inspectable as it expands.

We reviewed this

  1. ECC — our honest review

Sources

  1. ECC repository and README
  2. ECC GitHub repository metadata
  3. ECC changelog
  4. ECC security guide
  5. ecc-universal npm registry record
  6. ECC GitHub releases