A 311-skill catalogue is a routing problem
In short: ECC bundles 311 skills, but catalogue size does not prove useful routing; start with a narrow profile, inspect hooks and verify harness parity.
On 28 October 2026, the current ECC repository documented 71 agents, 311 skills and 97 legacy command shims. The Instagram reel I watched says 64 agents, 261 skills and 84 commands because it is repeating ECC 2.0.0's June catalogue.
The counts say nothing about routing: which instruction reaches the task, which hook can act, and which parts of the bundle work in the harness you actually run? A 311-skill catalogue is still a routing problem.
ECC 2.0's counts describe inventory, not an AI team
The 35.73-second reel moves from the three catalogue counts to “one-command setup” and “complete AI development team”. I inspected the full caption and playback, including the opening claim, the count card and the closing comment prompt. It does not show one task being routed, built, reviewed or accepted.
The numbers are real release history. ECC 2.0.0, released on 10 June 2026, listed 64 agents, 261 public skills and 84 commands. The current README has grown past those counts. The catalogue is active, but installing more entries does not automatically improve a particular engineering workflow.
That is the same mistake teams make when they count deployed agents. Inventory is easy to report. Accepted work, intervention load and retirement criteria are harder, and much closer to production value.
The ECC skill catalogue needs a routing budget
ECC's own documentation is more careful than the reel. The harness-adapter matrix tells Claude Code users to avoid loading every skill by default and to keep hooks opt-in and inspectable. It also distinguishes native Claude Code surfaces from instruction-backed Codex support and other harness-specific adapters.
My rule: a large skill bundle needs a routing budget. Every loaded description competes for discovery, every enabled hook adds an execution boundary, and every copied adapter can drift from its source. The useful metric is not “skills installed”. It is routing misses per accepted task: how often the harness chose no relevant skill, chose the wrong one, or applied a workflow that the target runtime could not enforce.
My default would be one ECC workflow at a time
This is labelled editorial judgment, not a Trigent or client deployment result. I did not install or execute ECC.
I would begin with the smallest profile that covers one recurring workflow, such as test-driven implementation or security review. Before adding another profile, I would inspect the files written, skills exposed, hooks enabled and verification command for that harness. ECC's current README also warns against stacking its plugin and full manual install into the same Claude Code environment.
I would then give a fresh session ten representative tasks and record whether the intended skill was selected, whether its checks ran, and whether the resulting change passed independent review. Expand only when the next profile reduces a measured miss.
Where ECC fits and where the reel breaks
ECC is MIT-licensed, actively maintained and unusually explicit about selective setup, hook profiles and cross-harness differences. Those are good reasons to inspect it if you want reusable agent workflows.
The reel's “completely free” line describes the open-source repository, not every project surface; ECC also offers a paid hosted GitHub App for private repositories. More importantly, the reel supplies no executed comparison, routing result or accepted-change evidence. Treat it as a pointer to the repository, not as proof of a complete team.
What's in it for you
- Start with one workflow instead of importing a catalogue for its count.
- Audit hook authority and harness parity before trusting a copied setup.
- Measure routing misses and accepted changes before expanding the bundle.
A skill catalogue becomes an engineering system only when routing, authority and verification are measured.
