pro-workflow: The Memory Layer That Keeps Claude Code from Forgetting How You Work
A hook-driven, SQLite-backed system for AI coding agents that captures corrections, preserves context, and turns repeated mistakes into reusable rules.
Self-correcting memory that compounds over 50+ sessions. You correct Claude once — it never makes the same mistake again.
- pro-workflow is less a coding assistant than a memory system for coding assistants.
- Its core move is to turn corrections into structured learnings that survive session resets.
- Hooks and compacting guards keep context from evaporating at the exact moments agents usually lose the thread.
- SQLite and FTS5 give the project retrieval, persistence, and discipline instead of another layer of prompt folklore.
The Goldfish Problem
The basic failure mode of AI coding tools is not that they are dumb. It is that they are inconsistent. You correct the same mistake twice, then again next week, because the agent has no durable memory of the project’s rules, conventions, or rough edges.
That is the bet behind pro-workflow. It does not try to make Claude Code smarter in the abstract. It tries to make it less forgetful in practice, by turning the terminal session into a system that remembers what the user already taught it.
How a Correction Becomes a Rule
The most important path in the repo is the correction loop. A user notices a mistake, the assistant response is scanned for a structured learning marker, and the correction is converted into a record that can be stored, searched, and reused later.
That sounds small, but it changes the relationship between session and project. Instead of a one-off chat log, the agent gets a memory pipeline. The lesson survives the session, then comes back at the next start.
The Hook System Is the Nervous System
The repo’s hook layer is where the memory idea becomes operational. The project maps lifecycle events in hooks/hooks.json to scripts, so the agent can react before a write, after a compact, or at session start without relying on the model to remember what to do.
{
"hooks": {
"PreToolUse": "scripts/secret-scan.js",
"PreCompact": "scripts/pre-compact.js",
"PostCompact": "scripts/post-compact.js",
"SessionStart": "scripts/load-learnings.js"
}
}That split matters. Some hooks are deterministic. Others use LLM help for softer judgments, like whether a message or change looks suspicious. The repo is not betting everything on a single model call. It is mixing small machine judgments with hard guards.
SQLite Is Doing More Than Storage
The database is not just a place to keep notes. In this repo, SQLite acts like memory, retrieval, and synchronization all at once. Learnings are written into tables, indexed with FTS5, and kept in sync with triggers so the application does not have to stitch everything together manually.
That design is why the project feels sturdier than a prompt template. A rule can be queried later with ranking, not just pasted into context as a lump of text. The result is a system that can surface the right correction at the right moment instead of stuffing every past lesson into the prompt forever.
CREATE VIRTUAL TABLE learnings_fts USING fts5(
rule,
mistake,
correction,
content='learnings'
);
CREATE TRIGGER learnings_ai AFTER INSERT ON learnings BEGIN
INSERT INTO learnings_fts(rowid, rule, mistake, correction)
VALUES (new.rowid, new.rule, new.mistake, new.correction);
END;Why Compacting Usually Breaks Agent Memory
Context compaction is where many agent workflows lose coherence. The thread gets trimmed, the reasoning vanishes, and the next turn starts with amnesia. pro-workflow attacks that with PreCompact and PostCompact hooks that preserve the important state before truncation and restore it afterward.
That is one of the repo’s most practical ideas. It treats continuity as something you can engineer, not something you hope the model magically retains. In a long project, that difference is everything.
Parallel Worktrees, Multiple Agents, Less Context Pollution
Once memory is persistent, the next bottleneck is isolation. pro-workflow uses worktrees and specialized agent roles so different tasks can move in parallel without contaminating one another’s context. The pattern reads less like a prompt pack and more like a workflow operating system.
| Capability | pro-workflow | Claude Code alone | Cursor alone | Aider / Continue class tools |
|---|---|---|---|---|
| Persistent project memory | Stores corrections as learnings and reloads them later | Mostly session-bound | Mostly session-bound | Varies by setup, usually lighter on durable memory |
| Hook-driven automation | Yes, lifecycle hooks gate writes, compaction, and learning | Limited or manual | Limited or manual | Usually scriptable, less integrated |
| Context compaction handling | Explicit pre and post compact continuity guards | Not the focus | Not the focus | Depends on user discipline |
| Multi-agent support | Dedicated agents and worktree orchestration | Not central | Not central | Possible, but not the core product |
| Retrieval of prior corrections | FTS5 search surfaces relevant learnings | No built-in learning store | No built-in learning store | Usually external or manual |
The key distinction is simple. Native tools help you talk to a model. pro-workflow tries to make the model operate inside a remembered project environment.
What It Beats, and What It Still Depends On
This repo is strongest where repetition hurts most. It reduces re-explaining, captures corrections as rules, and makes the agent feel less like a temporary contractor. That is a real advantage over prompt-only workflows and over assistants that treat each session as fresh.
But the dependency is still obvious. It assumes disciplined hooks, reliable local scripts, and a user willing to codify corrections. The memory layer helps, but it does not remove the need for clear judgment or good project hygiene.
