ECC Is Not a Prompt Pack
Everything Claude Code (ECC) is the subject of this series: an open-source operating layer that sits between a developer and the coding-agent harness they use. This opening asks a practical question: what changes when agent work is treated as a system of durable workflows, event checks, and evidence rather than a sequence of clever prompts? The answer matters to anyone using Claude Code, Codex, OpenCode, Cursor, or a terminal-based agent, because the hard problem is no longer getting a model to produce code once. It is making useful work repeatable, inspectable, and recoverable after the conversation changes or ends.
A coding model can write a function in seconds and still produce a fragile change. It may miss an importer, assume the wrong data format, forget a requirement several messages old, or declare success because a local example looks plausible. The model is not necessarily being careless. It is operating inside a shifting context: instructions compete with repository evidence, tool descriptions, previous attempts, and the limited attention available in a long session. A reminder to “use tests” can be sensible and still disappear when the next task takes over the conversation.
ECC's response is to move important behavior into things that can be inspected and reused. A plan becomes an artifact before implementation. A test is required to fail for the intended reason before the fix is trusted. Review is assigned to a fresh context instead of asking the same reasoning thread to certify itself. Hooks can check an event around a tool call. Memory can preserve a bounded handoff rather than an entire transcript. The common idea is simple: do not make the model carry every promise in working memory when a file, a check, or a state transition can carry it more reliably.
The problem is bigger than model quality
It is tempting to describe agent-assisted development as a contest between better and worse models. Model capability matters, but it does not settle the operational questions. A highly capable model still needs to know which files are relevant, which constraints are current, which action is authorized, and what counts as a completed change. Those are workflow questions. They concern state, ownership, sequencing, and feedback.
Consider a small authentication change. The code may touch a route, a data model, a session helper, tests, and deployment configuration. A prompt can ask for all of this, but the prompt does not by itself prove that the agent inspected the callers, reproduced the bug, preserved existing behavior, or checked the security boundary. If the same conversation both writes and reviews the change, it also carries the risk of overlooking an assumption it made earlier. The failure is not that the agent lacked an instruction; it is that the instruction had no durable place in the process where it could be checked.
ECC therefore treats development as a chain of evidence. The repository's documented path moves from planning to test-driven implementation, review, verification, memory, and improvement. A plan records intent. A failing test demonstrates that the test reaches the behavior at issue. A passing test records one form of evidence after implementation. A review asks whether the change has a concrete defect or regression, not whether an imagined list of concerns can be made longer. A session summary or handoff preserves what happened and what remains uncertain.
This does not turn the model into a deterministic compiler. It changes the conditions under which the model works. It makes an omission easier to see, a correction easier to resume, and a claim easier to challenge. The distinction is important: ECC's value is a design for recoverability and governance around agent work, not a guarantee that every generated change is correct.
ECC sits beside the harness, not inside the model
ECC is also easy to misunderstand because it spans several kinds of software. It is not a language model, and it is not a replacement for the host application that supplies the conversation, tools, permissions, and session runtime. Its current package identifies itself as version 2.2.1, while its repository serves as the source of shared workflows and the adapters that place them into different hosts.
The relationship is best understood as a boundary. Claude Code is the primary reference surface in the project, with native plugin assets and hook execution. Codex can consume shared skills and plugin metadata, but its hook and approval behavior is not identical. OpenCode uses its own plugin and event system. Cursor receives project-local rules, skills, and an adapter that translates event shapes. Other environments may receive instructions without runtime hooks or delegated agents. A terminal-only path remains useful because the underlying skills, rules, scripts, and checks can still be used explicitly.
That variation is not a footnote. It determines what a claim such as “ECC supports this harness” actually means. A workflow may travel unchanged as a SKILL.md document while its activation, permissions, lifecycle events, or memory paths change at the edge. The project's own compliance model distinguishes native, adapter-backed, instruction-backed, and reference-only surfaces for this reason. Portability means preserving the durable behavior where possible and naming the behavior that cannot travel, not pretending that every host has the same control plane.
The same boundary explains why the repository contains more than prompts. Skills describe reusable knowledge and workflows. Agents define scoped workers with particular responsibilities and tool access. Commands offer convenient entry points, while the project increasingly treats skills as the canonical workflow surface. Rules hold standards that a harness may load continuously, so they need to be chosen carefully. Hooks operate around tool and session events, allowing selected checks to happen outside the model's prose. Scripts and manifests connect these pieces to installation, state, and verification.
The layers are not interchangeable. Putting every rule into a skill would make an important standard depend on whether the model notices the skill. Putting every workflow into a rule would load too much context into every task. Asking an agent to perform every role in one conversation would erase the separation that makes review and recovery useful. ECC's architecture begins with assigning each concern to the narrowest layer that can carry it.
The real unit of value is a recoverable workflow
This is why the catalog's size is a weaker measure of ECC than its boundaries. A large inventory can be useful, but it can also create noise, context pressure, duplicated behavior, and a larger surface to secure. The project increasingly emphasizes selective installation and on-demand skills so a developer can choose a baseline rather than load every possible capability. The aim is not minimalism for its own sake. It is to keep the active system proportionate to the work.
The same principle governs continuity. A useful memory entry does not need to preserve every message. It needs the objective, the evidence gathered, the files or external work involved, the unresolved risks, and the next action. A useful review does not need to enumerate every hypothetical defect. It needs a concrete failure mode and a line of evidence. A useful adapter does not need to duplicate the core workflow. It needs to translate the host's paths and events without concealing the loss of enforcement.
The result is a different way to judge an agent tool. Ask what survives a context reset. Ask where intent is recorded, who can alter it, and how a later session knows whether it is current. Ask which checks run before an action, which can only warn afterward, and which still require a person. Ask whether a “successful” evaluation tested a real behavior or merely verified that a receipt, hash, or static scan was internally consistent. Ask what happens when installation drifts, a memory is malformed, a harness lacks a hook, or a proposed autonomous execution has no safe containment backend.
ECC's own documentation is strongest when it refuses to blur those distinctions. Its offline evaluation framework records capsules, fixtures, and receipts but keeps candidate execution disabled until an independently reviewed operating-system boundary exists. Its cross-harness documents describe parity as partial. Its memory design keeps new entries unreviewed and provides no automatic promotion into policy. Its installation design records ownership so repair and uninstall can be safer, while acknowledging that richer merge and removal semantics are still maturing. These are not signs that the system has no value. They show that a control layer is trustworthy only when its limits are visible.
The central idea for the rest of this series is therefore not “add more agent features.” It is “make the workflow legible.” We will examine how ECC divides responsibilities, manages context as a finite budget, turns coding into an evidence trail, preserves memory without granting it authority, adapts across harnesses, and constrains security and autonomy. The practical judgment is conditional: use the parts whose contracts and boundaries fit your environment, verify the parts that depend on an adapter, and do not expand autonomy faster than the evidence and isolation beneath it.
That is the useful starting point for ECC. It is a way to place durable structure around an agent that is powerful, fallible, and operating under changing conditions. The question is not whether a prompt can tell the agent what to do. The question is which layer owns that instruction, how the action will be checked, and what remains when the chat is gone.