ECC installs a 293-skill engineering workflow
ECC bundles 68 specialist agents, 293 skills, 94 legacy command shims, rules, hooks, memory, and security tooling. The idea is straightforward: give a coding assistant a repeatable route through planning, tests, implementation, review, and handoff. That can save real setup work for a team that already knows how it wants agents to behave. It can also put far more machinery into a session than a developer expected to install.
The repository makes Claude Code its primary host. Codex has a supported native plugin, while Cursor and OpenCode are beta adapters. GitHub Copilot gets instructions and prompt files without ECC hooks, runtime agents, delegation, or native skill discovery. A final group of assistants receives experimental or minimal adapters. Those labels matter because copying the same Markdown into several tools does not give each tool the same controls.
One installation path prevents duplicated hooks
The shortest Claude Code route is the guided ecc-universal setup or the native ecc@ecc plugin. The README tells you to choose one. Combining the plugin with a full manual install can duplicate skills, commands, hooks, or configuration across scopes. Codex has the same boundary between its native plugin and the older copied-configuration sync path.
ECC does provide ways to reduce the surface. A minimal profile leaves out the hook runtime, and dry-run commands show planned writes for several targets. Claude Code users can start with common rules plus one language pack rather than loading the catalog. That is the sensible trial: install one profile in one harness, run its doctor command, and verify the workflows your team will actually call.
The security section gives the right warning. Hooks can execute shell commands, MCP servers can hold credentials, and project instructions enter the assistant's context. ECC includes checks for destructive commands and an AgentShield scanner, but those features do not remove the need to inspect what will run. Host sandboxing and least privilege still carry the security boundary.
What happened when we ran it
Our sandbox checkout at commit c70874f contained 4,211 files, about 331,765 lines of source, and occupied 57.7 MB. Yarn installed 264 packages in 17 seconds, taking 159 MB on disk. The repository exposed no build script or build target, so our harness skipped that step rather than inventing one.
The test command did not finish within our 900-second limit. The last log lines showed environment-variable and Git configuration cases continuing to pass, including checks around appended GIT_CONFIG_PARAMETERS values, and the output ended with a check mark. The tail did not show an exception, a failed assertion, or a final count. We cannot tell from that evidence whether the suite was stuck or simply still running.
Npm audit reported 4 known vulnerabilities: 1 high and 3 moderate, with none critical or low. The repository has a tests directory and 12 CI workflow files, but no Dockerfile. That combination gives maintainers plenty of automation surface while leaving a new evaluator without a project-supplied container recipe. More important, commit c70874f did not clear a fresh-container test gate in the allotted 15 minutes.
Claude Code gets more ECC than the other hosts
Claude Code's stable plugin can load skills, agents, commands, and plugin-managed hooks. It requires Claude Code 2.1 or newer because of how that version discovers plugin hook files. Codex supports the native marketplace lifecycle and explicit hook trust, but it does not use Claude's four hook profiles. Cursor's adapter still has an open issue about exposing only a fraction of ECC's hook-driven behavior.
The differences continue on the edges. OpenCode ships a subset of the catalog and needs its own provider and model choice. Copilot remains instruction-only. Some optional paths need Bash or Python, and native Windows support has limits for shell-backed features. If cross-assistant consistency is your goal, write down the few behaviors that must match and test those on every host. The ECC name alone is not proof of parity.
Memory is one reason to accept the extra machinery. ECC's vault stores explicit handoffs under project, team, or user scopes, and its MCP server limits itself to save, search, read, and doctor operations. The README calls recalled entries unreviewed and tells agents to verify important claims before promoting them into project documentation. That is a sound boundary for teams that want continuity without treating yesterday's generated note as policy.
September 30 activity shows speed and a crowded queue
GitHub recorded the last push on September 30, 2026, and v2.2.2 was released the same day. On October 1, the repository showed 270,420 stars. GitHub search separated its 224-item open count into 83 issues and 141 pull requests, so it would be wrong to describe all 224 as bugs. The dates show active maintenance, while the queue shows how much change is moving through the project.
Release v2.2.2 added a Pi-focused package containing 123 selected skills and 24 prompt commands without hooks or runtime downloads. It also included packaging, memory, Windows, and dependency fixes. That narrower profile points to ECC's best use: take a reviewed slice that solves repeated work. Installing all 293 skills because the catalog exists turns choice into maintenance.
Choose ECC when the system earns its upkeep
Superpowers is easier to reason about when planning, test discipline, and review are the main jobs. Wshobson's Agents offers another broad multi-assistant catalog, while Awesome Claude Code is useful when you prefer to pick independent parts. ECC is the better fit when its hooks, memory, repair tools, and selective installers replace a workflow your team already repeats. Our 900-second timeout means that adoption should begin as a controlled trial, with the 4 audit findings and host-specific checks resolved before a wider rollout.