CLEAR

Coding agents start every session cold. Whatever got decided last time, the patterns that were set, the dead ends already ruled out, none of it survives the context window closing. So the agent re-derives what it already knew, or worse, contradicts a decision made a week ago because nothing told it the decision existed. The usual patch is a memory file or a running notes doc, and it helps right up until it rots: the notes say one thing, the tracker says another, and the knowledge is stale because keeping it current is a separate chore nobody keeps up. The agent can reason fine. What it's missing is context that's bound to the work, kept current, and there the moment it matters.

Solo developers on multi-session projects who need real continuity instead of re-explaining context every morning. Knowledge-intensive builds where decisions, patterns, and lessons have to persist, stay fresh, and stay discoverable against the code they concern. And, practically, users on Claude Max and Enterprise plans, because capture runs on tool use and rewards a generous token budget.

The jobs they hire CLEAR to do:

Start with what actually breaks. Most attempts to give an agent memory store some notes and call it done. But storing notes is the easy part. Keeping them true as the code changes is the hard part, and it's the part everyone skips, because maintaining a knowledge base by hand is a second job on top of building the software. CLEAR's answer is a knowledge base that maintains itself.

It works like this. As you build, CLEAR captures the things worth remembering, the decisions made, the patterns that emerge, the lessons learned, the business rules, and writes each one as a typed markdown file bound to the code it concerns. It's diffable markdown living in your repo, with no database server and no Neo4j to run. Bound is the operative word. Touch that file again next week, or next month, and the decision attached to it surfaces on its own. You never went looking for it.

What makes it a living system rather than a folder of notes is what happens as the code moves on. Every piece of knowledge carries a lifecycle. A newer decision supersedes an older one, with the link recorded both ways so you can trace what replaced what. A rule that stops being true gets deprecated. When a superseded or deprecated concept would be served, CLEAR surfaces it as exactly that, so an agent is never handed stale guidance dressed up as current truth. And all of it happens as a byproduct of the work. You don't curate the knowledge base. Building the software curates it.

Driving that capture is an explicit development loop: plan → schedule → act → manage. A plan holds intent as phases and milestones. A workpackage is a trackable unit of work whose progress is computed from the real files that appear as you build. Act is ordinary building, where knowledge gets captured and bound as you go. Manage is the session handoff, a structured summary the next session reads on startup, so session N+1 continues from session N instead of starting cold. The loop is the engine. The self-maintaining knowledge base is what it produces.

Underneath, one decision holds the whole thing together: a single writer for every piece of state. The failure mode of naive memory systems is silent disagreement, the notes saying one thing and the tracker another, handing the agent a contradiction it can't see. CLEAR routes every state change through one authoritative writer, so the status view, the plan file, and the workpackage records can't drift apart. A shared context layer then assembles the right knowledge and state and hands it to the agent at the moments that matter, at session start, when a bound file comes into play, on each turn. The agent is served its context. It doesn't have to ask.

None of this is welded to Claude Code. The knowledge format, the state model, and the CLIs are harness-agnostic; Claude Code is the first adapter, not a requirement, and a port to Codex, Cursor, Aider, or Gemini CLI reimplements only the thin adapter shell.

There's one more thing, and it's where the story turns. That capture format has a name: CKS, the CLEAR Knowledge Spec. It's a standalone specification, seven first-class knowledge types, a status lifecycle, and a defined pattern for how knowledge is bound and served, hardened across eight schema revisions. CLEAR has been running it since 2025. Then, in June 2026, Google open-sourced the Open Knowledge Format, a v0.1 draft for markdown-native, typed, resource-bound knowledge. It described, as a draft, the model CLEAR had already been shipping as a working superset, lifecycle and all, for over a year. Two independent roads arriving at the same model is the kind of validation that says CLEAR was worth building, is worth using, and is worth taking further.

CLEAR v1.0 is public, open-sourced under Apache-2.0, chosen over MIT for its explicit patent grant, and live on npm as @qball-inc/clear with an interactive walkthrough deck. It's a stable, state-correct lifecycle surface: a persistent, code-bound knowledge base plus plan, workpackage, and session management, held together by the single-writer model so every surface agrees. The public repo is a mirror of a private development repo, with issues and PRs pulled in and synced back so the two don't diverge.

The next major release is a ground-up rewrite. Today's core is a mix of bash and TypeScript CLIs; the rewrite collapses both into a single Rust binary, which makes execution dramatically faster and the install a single artifact. Past that, the roadmap is public and honest about being direction, not commitments: knowledge beyond code (people, places, organizations, and events as first-class primitives), selective hardening from OKF, verification-method and confidence on concepts, and harness adapters past Claude Code.