Teardownspublic

ECC

I took apart the upstream of my own configuration. What was worth taking wasn't a feature but a measurement — and that measuring tool wouldn't run here.

Out of a repository with 285 skills, exactly one thing got adopted. The QA and loop techniques it advertises I already had, arrived at independently and mostly in stronger form. The one axis I genuinely lacked was a tool that measures whether an agent actually followed the rules I wrote — and that tool wouldn’t run in my environment. The leading hypothesis for why is a failure mode this repository itself warns about.

on every tool call — Bash, Edit, Write, all of them agent event PreToolUse · Stop … obfuscated one-liner scans home for the install bootstrap → dispatcher 5 entry points · 50 scripts run decided by strength tag standard · strict you pick one profile, not individual hooks minimal standard strict Hooks aren't switched on and off — they're managed by strength tier. That idea came home Mine are all binary, so a hook I mute during exploratory work stays muted into the next session
The most distinctive design. Every hook goes through one bootstrap, and whether it runs is decided by matching its tag against the active profile.

What the repository is

Everything Claude Code — it presents itself as an “operating system” for agent harnesses. The pitch: stop rebuilding your development process on every prompt, and install it once so that it becomes how the agent works.

The loop it hardcodes:

plan → test → implement → review → verify → remember → improve

Its slogan is “Optimize the context window. Persist everything else.” — put as little as possible in context and push state down into files, hooks and memory. That slogan comes back to bite it later on this page.

Measured
Skills 285
Agents 68 — review, build repair, architecture
Rule files 122 — 24 language groups × 5 fixed types
Total 3,458 files · 88 MB (73% markdown, 492 JS, 63 Python)
Licence MIT

It matters to me for a specific reason: this repository is the upstream of my own ~/.claude. I copied it out as files six months ago, and there is no auto-update. So this wasn’t browsing someone else’s repo — it was opening the original of something I already run, and measuring the drift for the first time.

Six named techniques — and the single most valuable page in the repo

Technique What Executable code
Santa Method “Make a list, check it twice.” Two independent reviewers, and both must pass to ship. On failure, fix and re-review with a fresh agent that has no memory (to break anchoring); after three rounds, escalate to a human none
loop-design-check A judgement-only skill you run before building a loop. A step-zero veto gate, plus five collapse modes none
skill-comply Measures whether skills and rules are actually followed. Derives expected behaviour from the docs, runs it under three pressure levels, and traces the tool calls yes
click-path-audit For bugs where each function works and the combination breaks. Traces call order and state reads/writes none
delivery-gate A stop hook that blocks session end using deterministic checks only yes
agent-sort Sorts skills and rules per repo into daily and library buckets none

The reasoning behind Santa Method is good — “an issue only one of them caught is still a real issue. The other one’s blind spot is the whole reason this method exists.”

But the most valuable thing here isn’t a skill. It’s the five collapse modes that loop-design-check tabulates.

# How it breaks Antibody
1 The goal is a correct-sounding slogan (“manage it well”) → nothing can adjudicate it → it runs forever burning money Replace it with an outcome a machine can judge
2 Verification is “look at whether it seems fine” → the agent confidently says it’s fine and stops Separate the judge from the defendant. External comparison plus exit codes
3 (worst) Gate only on “all tests pass” → the agent deletes the tests Set the completion condition and the boundary condition together
4 Expecting to be asked mid-run → it never asks and drives a wrong answer to the end Finish every clarification before departure
5 Bloated instructions plus stale memory → the faster the loop, the more wrong it gets Layered memory plus periodic linting

Numbers 3 and 5 come back later on this page.

What broke — “285 skills” is a document count, not a tool count

Opening the advertised techniques file by file: Santa Method, agent-sort, click-path-audit and loop-design-check are each one document with zero executable code. The Python inside Santa Method is pseudocodefix_agent.execute(...) and the like. The fact that 73% of all files are markdown supports this.

So it’s a collection of prompt patterns, not a framework. The parts with real code are skill-comply and delivery-gate.

The hook bootstrap is a supply-chain surface. Install the plugin and every Bash, Edit and Write call runs an obfuscated one-liner that loads code from a path discovered by scanning your home directory. It works — but one bad hook blocks tool use itself.

And the repository violates its own rule. All 285 skill descriptions sit resident in context, which is precisely what collapse mode 5 above warns against: bloated instructions mean the faster the loop, the more wrong it gets. Which is why ECC also ships tools for trimming itself.

What held up, on the record. Every health claim was true — MIT, 11 CI workflows, 248 test files, supply-chain monitoring, a commit on the day I looked. “285 skills” matched a directory count exactly, with no inflation.

Held against mine, one by one — one of seven

285 upstream skills 60 overlap 102 mine upstream — I copied from here six months ago my setup today From the non-overlapping side: 7 shortlisted → 1 adopted → and that one wouldn't run
Compared technique by technique, not by skill count. Most of the advertised techniques I already had, independently, in a stronger form.
  • Santa Method → rejected. The adversarial review in my own pipeline is the superset. Not two reviewers but three lenses in parallel with an adjudicator that rebuts them, and the final gate is deterministic code, not an LLM verdict. The rubber-stamping failure Santa worries about is structurally impossible there
  • loop-design-check → checklist only. I already had its three core ideas: a free oracle (a build that passes on product criteria is the answer key, so every failure is an automation defect), a negative trial (evaluate the rule against the wrong screen too, and reject it if it matches anywhere), and a record / judge / diff split that makes re-adjudication cost nothing
  • click-path-audit → procedure only. The patterns assume the web and don’t fit, but the procedure — trace call order, trace which call reverts which state — ports to a game engine
  • delivery-gate → rejected. It duplicates a weekly human-approval gate and collides with my fail-closed principle
  • agent-sort → rejected. Two tools already do this job and I’ve run neither. A third isn’t a solution, it’s a deferral

Which leaves the one real gap — skill-comply. Everything I have checks artifacts: whether the docs match reality, whether the canonical copy has drifted, whether cases meet the format. There is nothing that measures whether an agent followed the rules, and I have never once measured compliance across my eighteen rule files.

So I ran it — and it failed

Being the one real gap, I ran it rather than trusting the docs. Every prerequisite was already in place.

First, four Windows blockers, found and fixed.

Symptom Root cause
Decode failure on Korean documents File reads specify no encoding → Windows uses the legacy code page
Executable not found claude is actually a .CMD, and process creation doesn’t do extension resolution
Output written to the wrong path A Unix temp path hardcoded
Decode failure on the write side Temp-file writes also specify no encoding

All four are still present upstream. On Windows with non-ASCII content it dies on the first line. After the fix, all 33 unit tests still pass.

Then the actual measurement failed on all four combinations. The diagnosis:

prompt_len = 2396   ← template substitution fine. Nothing to do with argument limits
stdout_len = 34     ← the response is abnormally short
actual      = "How can I help you? (current working directory: …"

A 2.4 KB instruction gets ignored wholesale and a conversational greeting comes back. Parsing that greeting as YAML yields a string, and pulling a field out of a string is where it dies.

Established: the failure is in the contract layer, not encoding. The prompt assembles intact, the exit code is clean, and the promised format simply doesn’t arrive.

Not established: why it’s ignored. The leading hypothesis is that the subprocess inherits the global instructions and hooks wholesale, burying the embedded instruction. An isolated-environment test was invalidated by an authentication problem, so this stays an estimate.

Verdict — not taking anything is the result

The strength-tier idea for hooks Adopted — it names exactly what’s wrong with binary on/off
skill-comply On hold — the tool is repaired; what remains is one confirmation of the hypothesis
The five collapse modes Adopted as a checklist — run against the next loop I design
Santa · delivery-gate · agent-sort · full install Rejected — each with its resume condition written down

That there was almost nothing to take is itself the finding. My review chain and my unattended-loop conventions had independently reinvented the upstream’s headline techniques, in stronger form.

And the last layer is the one that stung. The one real gap was a measurement, not a feature — and the tool that measures it probably tripped over my own context bloat. Which is the thing this repository puts on its banner (“optimize the context window”), the thing it can’t obey itself, and the thing it names as collapse mode 5. The same disease, three layers deep.

The prescription is already in my hands: two tools for trimming context, installed six months ago and never once run. Running them is what this investigation left as first priority.