Pro Workflow: a SQLite memory layer for Claude Code corrections

The repeated-correction problem Pro Workflow targets

The README opens with a specific complaint: you correct Claude the same way fifty times, explain conventions again at the start of every session, and lose the learnings when context compacts. The stated audience is anyone using Claude Code often enough to notice the pattern. That framing is narrower than the topic list suggests. The repository is tagged for agent-orchestration, context engineering and worktrees, but the problem statement is about instruction persistence, not about orchestrating many agents at once. The second half of the problem is research duplication: the README says users research the same topic across three sessions because there is nowhere durable for the answers to land. Pro Workflow answers both with one storage decision, which is the part worth examining.

One SQLite store under every session

The architecture is a single SQLite database that every session reads from and writes to. Two structures sit on top of it. The first is self-correction memory: each correction becomes a rule, indexed with FTS5 so it can be searched, and loaded automatically when a session starts. The second is a knowledge plane made of research wikis written to disk with an FTS5 shadow index, so any session can query them. The README describes the flow in a worked example. In session one you tell Claude not to mock the database in tests; Claude proposes a rule, you approve it, and it is saved. In session two, the SessionStart hook loads all learnings and lists your wikis, and a UserPromptSubmit hook injects the top wiki hits when they look relevant. By session fifty the README claims the correction rate approaches zero. That number is an illustration in the README, not a measured result, and the repository publishes no benchmark to support it. The mechanism is plausible; the figure is marketing.

Hooks are where the memory actually attaches

The interesting engineering is in the hook layer, not the storage. The README counts 37 hook scripts spread across 24 events, alongside 41 skills, 8 agents and 23 commands. Two hook points carry the memory behaviour: SessionStart loads rules and enumerates wikis, and UserPromptSubmit decides which wiki entries to inject into the current prompt. That second hook is the design decision with consequences. Injection is relevance-based, so a rule that exists in SQLite but never matches a prompt stays invisible. The README also mentions LLM-powered hooks for quality gates and deterministic git and secret guards, which means part of the pipeline calls a model rather than running a fixed check. That is a cost and latency surface the README does not quantify. There is also compaction-aware state, which matters because the original problem is that context compaction erases learnings; persisting them outside the context window is the only way that survives.

Installing it: two paths and a build step that bites

Claude Code gets a native plugin path. The README gives two commands: /plugin marketplace add rohitg00/pro-workflow followed by /plugin install pro-workflow@pro-workflow. Everything else goes through skills add, which installs the skill bundle into each agent's own skill directory: npx skills add rohitg00/pro-workflow. The README warns to use the GitHub owner/repo form rather than the bare name, because skills add resolves providers from owner/repo and not from marketplace slugs. After install you run skills sync to register the skills with the target agent. The smoke test is /doctor to confirm the SQLite store, hooks and skills load, then /wrap-up, which the README says is a no-op on a fresh install. The failure mode to know about is documented: if /doctor reports KB: missing, you go into the plugin directory and run npm install && npm run build, because the SQLite components need a build step that some marketplaces skip. A manual path exists as well, cloning to /tmp/pw, running npm install and npm run build, then copying templates/split-claude-md into ./.claude/ and the skills, commands and hooks.json into the agent's config directories.

Where the project's own documentation is thin

The licence is the clearest problem. The repository metadata supplied here lists the licence as unknown, while the README displays an MIT badge. Those two sources disagree, and a badge is not a licence file. Anyone who needs to know the terms should open the LICENSE file in the repository directly. The second gap is maintenance cost. The README describes counting hooks, skills, agents and commands, and it describes installing into more than thirty agent directories, but it does not describe an upgrade path, a migration story for the SQLite schema between v3.1.0, v3.2.0 and v3.3.0, or what happens to accumulated rules and wikis when the plugin updates. Given that the whole value proposition is memory that compounds over fifty sessions, schema drift on upgrade is the risk that matters most, and the material does not address it. The third gap is the auto-research loop, which the README says can grow a wiki overnight and claims it becomes denser than the curated lists you started from. No scheduling mechanism, rate limit or cost control is described for that loop.

Roster churn and what it means for the cross-agent path

The README lists more than thirty supported agents and then adds a note that the roster changed during 2026: windsurf relaunched as Devin Desktop and speaks the Agent Client Protocol, and gemini-cli was superseded by the Antigravity CLI for consumers. It says the adapter names still resolve but now target the current product. That is an honest disclosure and also a warning. If you are on the non-Claude path, your integration depends on adapter names that have already outlived the products they were named for, and the README points to references/modern-workflows-2026.md for the interop picture. The Claude Code path avoids this class of problem because it uses the native plugin marketplace. The cross-agent path trades that stability for breadth, and you should price that in before choosing it.

The alternative: CLAUDE.md and a project conventions file

The obvious alternative is the built-in mechanism most Claude Code users already have: a CLAUDE.md file in the project, plus whatever the agent loads automatically at session start. The difference in approach is not storage but timing and search. A CLAUDE.md file is static, hand-edited, and loaded in full every session; it grows monotonically and you prune it yourself. Pro Workflow stores rules in SQLite with an FTS5 index and injects only the entries that match the current prompt, which is what makes a large accumulated rule set usable rather than a wall of text. It also writes rules through an approval step during the session, so the capture happens at the moment of correction instead of in a later editing pass. If you have fewer than a few dozen conventions, a plain CLAUDE.md is simpler, has no build step, no SQLite dependency, and no plugin upgrade surface. The crossover point is roughly where you stop being able to keep the whole file in your head.

Who should run this, and what to check first

The five commands the README highlights map the intended daily loop: /learn-rule to capture a correction, /wrap-up at the end of a session to audit changes and write a handoff, /wiki init to start a persistent wiki on a topic, /develop for a research-plan-implement cycle with validation gates, and /smart-commit before a pull request. If that loop matches how you already work, the plugin is aimed at you. If you open Claude Code twice a week for small edits, the SQLite store and hook layer are overhead you will not amortise. The strongest case for adoption is a long-running project with stable conventions and a body of research you keep re-deriving. The weakest case is a short-lived repository where a CLAUDE.md file would fit on one screen. Verify /doctor before trusting any of it, and treat the licence question as unresolved until you read the file.

Editorial conclusion

Adopt Pro Workflow if you already run Claude Code daily and keep re-explaining the same conventions across sessions, and if you are willing to run npm install && npm run build inside the plugin directory when /doctor reports KB: missing. Do not adopt it if you want a dependency-free setup, since the memory layer requires a compiled SQLite component that some marketplaces skip, or if you only use an agent that has no first-class plugin support and you are unwilling to maintain the copied skill bundle by hand. Before committing, verify three things: read the LICENSE file in the repository rather than trusting the badge, confirm that /doctor passes on your machine, and check that your agent appears in the supported list at the version you have installed.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rohitg00/pro-workflow on GitHub