Context management system for AI workflows
ContextObserver
My setup for AI projects: agents, rules and a tool that keeps sessions lean.
In my daily use, not published
How a feature gets built
Click a step to see which parts of the setup work on it.
Plan
Build
Close
Next slice, fresh session
Interview. The main session questions me: what's the goal, what can go wrong, what doesn't belong? Without a spec, nothing gets built.
The setup every new project gets
Who works
- Me
- Main session
- Researcher
- Plan critic
- Implementer
- Reviewer
What gets read and written
- Goals
- Decisions
- Standards
- Feature spec
- Plan
- Learnings
- Handoff
What watches automatically
- File name check
- Git guard
- Stop on red checks
- Context Observer
From my real project template, slightly shortened. Context Observer creates it with one command and then keeps the sessions lean.
Core skills
- Reliability
- LLMs and agents
- Backend and APIs
- Security and privacy
- Testing and verification
- AI-assisted engineering
Tech stack
- Node.js
- JavaScript
- Claude Code
- PowerShell
- git
The hardest part
Quiet doesn't mean finished
You have to know what a signal really measures.
The whole story
What it looked like
On its first armed day, the tool destroyed running work twice: it ended a session in the middle of a model load that took four minutes.
What was really going on
To the tool, “idle” only meant that nothing new had appeared in the log. A session working in the background looks exactly the same from outside. An exception for idle sessions then meant it didn't even ask.
The fix
The tool now reads the real background jobs and no longer takes child processes down with it. The exception is gone: it asks the session before every takeover.
- 502 / 502
- self-test checks passed
- 974k to 761k
- tokens in one measured takeover, one of four
- 0
- dependencies
- ~7.4k
- lines of code in 18 files, plus ~4.5k lines of tests
In plain words
AI coding tools have a short-term memory, and eventually it fills up. This tool asks the running session whether it's a good moment, backs everything up, removes what isn't needed and lets it continue with less baggage. It isn't from Anthropic. I built it for my own work.
I work in several long sessions every day. A running process holds its context in RAM and never re-reads its transcript, so a live session can't be edited, only replaced. The whole design follows from that one fact.
How it works
Step 1 of 5
Watch
Reads every transcript without writing to it, and separates dead history before a compaction from truly live context.
What was built
- A live watcher that tails every transcript and reads the real context size from the API's usage figures
- Consent through a hook: the session itself answers PRUNE-OK or PRUNE-WAIT
- A two-stage pruner: shrink deterministically first, then a Sonnet judge that may only keep what it can cite from the plan
- Structural invariants and atomic writes with compare-and-swap. The original is archived and flushed first
- Process identity from pid, name and creation time, so a recycled pid can't hit the wrong process
- A dashboard, a per-project setup check and a wrapper that resumes the session in the same terminal
How those skills were used
- Reliability
- Fail-closed gates, atomic writes, durability, compare-and-swap and three-valued liveness (alive, gone, unknown)
- LLMs and agents
- Context engineering and prompt cache economics, plus a judge whose verdict falls back to keep when malformed
- Backend and APIs
- Server, CLI and test harness in plain Node.js, with zero dependencies
- Security and privacy
- Token and origin checks, since any open web page can reach localhost, and untrusted content is fenced off as data
- Testing and verification
- Mutation checks, end-to-end rigs with real processes and proof runs on copies of real 87 MB transcripts
- AI-assisted engineering
- Five audit rounds by agents that found real bugs every time, some in the previous round's fixes
My role
The idea, the decisions, what gets armed, and reporting what breaks. Agents did most of the code and audits.