ctx: Continual Learning for Agents, Token-Efficient Skill Synthesis

ctx takes knowledge that would otherwise be ephemeral, scattered, or siloed... and makes it persistent, searchable, and connected. It captures your own sessions automatically. It ingests external sources & synthesizes them into reusable skills calibrated to your context.

The output of this system is context bundles & skills. The goal is time to value: starting a new PR with the relevant patterns already surfaced, carrying forward what you learned on one project into the next, not re-diagnosing failure modes you've already seen & fixed. An agent session that starts from your accumulated knowledge about a problem domain is materially different from one that starts from zero.

---

The Foundation

David Cramer at Sentry describes the core insight in Skill Synthesis. Building a security vulnerability detector in a single workday, they fed their own commit history, real patches, and real failures into a skill creator prompt and iterated until it was reliable. Generic security guidance couldn't match it because it lacked what mattered: context for their codebase, their abstractions, their patterns. Skills are just files in a repo. Synthesized from real material. Iterated like software.

ctx applies this to the continuous work of an individual engineer.

---

Architecture

CAPTURE
  Cursor sessions      →  ctx-hook.py       →  raw/
  Claude Code sessions →  ctx-watcher.py    →  raw/

PIPELINE
  raw/                 →  ctx-ingest.py     →  learnings/ + SQLite traces
  learnings/           →  ctx-summarize.py  →  summaries (portable + domain)
  summaries            →  ctx-embed.py      →  embeddings + chunks

KNOWLEDGE CREATION
  traces               →  ctx-detect.py     →  candidates/ → skills/internal/
  docs + external      →  ctx-synthesize.py →  patterns/ or skills/external/

RETRIEVAL
  any query            →  ctx-compile.py    →  grounded briefing + sources

The pipeline has two distinct operations that never overlap.

Compile is retrieval. You paste a task description: a problem statement, a spec excerpt, an error message, anything relevant. ctx searches the knowledge base, ranks results across patterns, skills, docs, and past sessions, then calls Sonnet to produce a unified approach paragraph grounded in what you actually know. Sources are cited below as @-taggable file references. Paste the bundle into Cursor or Claude Code before starting. Nothing new is created.

Synthesize is creation. You point it at source material: a URL, a local doc, a past session, an existing skill, multiple sources at once. ctx checks for redundancy against existing knowledge, calls Sonnet to extract a reusable skill or pattern, writes it to the namespace, chunks and embeds it immediately. Nothing is retrieved.

Compile reads. Synthesize writes. They feed each other but never conflict.

---

Namespace

~/.context/
├── learnings/          # AUTO ~ one .md per agent session
├── candidates/         # AUTO ~ pending approval in ctx serve
├── patterns/           # synthesized from docs only, never from traces
├── debugging/          # manual ~ failure modes + fixes
├── skills/
│   ├── internal/       # promoted from traces via ctx detect
│   │   └── {slug}/
│   │       ├── skill.md
│   │       └── references/   (optional, on-demand context)
│   └── external/       # synthesized from external sources
│       └── {slug}/
│           ├── skill.md
│           └── references/
├── primitives/         # atomic, MCP-exposable units
├── docs/               # architecture notes, reference material
└── plans/              # implementation plans (status in frontmatter)

The promotion rules are strict by design:

• Traces promote to skills/internal/ via detection (never directly)
• Docs synthesize to patterns/ or skills/external/ (never from traces)
• plans/ is manual only -> the system never writes here
• patterns/ comes exclusively from docs, never from raw traces

This matters because the knowledge base is only as useful as the signal in it. Mixing auto-generated trace summaries into patterns would degrade compile output immediately. The separation keeps each namespace's signal clean.

---

Insights

One instinct I resisted: creating a GitHub slurper and capturing code context. Orchestrating headless Cursor agents sounds like a ridiculously fun project, but to make this operational in my day-to-day, building something complementary to existing real-world workflows is ideal. The value in an agent session comes from the context and steering that shaped the code. The highest-signal inputs are the things that never make it into the repo.

Detection surfaces candidates. It doesn't auto-promote. Every skill that enters skills/internal/ went through a yes/no decision in the web UI.

The obvious question: why not ask Claude to synthesize a skill from source material in a conversation? Or even better, do it inside the Cursor IDE? The output is good. It works. The problem is it lives in that conversation and nowhere else. Zero friction between creation and retrieval. Everything written into the knowledge base is immediately chunked, embedded, and searchable. A skill synthesized today surfaces automatically in tomorrow's compile.