# rohitg00/pro-workflow: self-correcting memory for Claude Code

> A Claude Code plugin and cross-agent skill bundle that turns corrections into SQLite rules and keeps research in FTS5-indexed wikis. The design is opinionated and the install path has real sharp edges.

**rohitg00/pro-workflow** — Claude Code learns from your corrections: self-correcting memory that compounds over 50+ sessions. Context engineering, parallel worktrees, agent teams, and 17 battle-tested skills.

- Repository: https://github.com/rohitg00/pro-workflow
- Website: https://rohitg00.github.io/pro-workflow/infographic.html
- Stars: 2,897 · Forks: 295
- Language: JavaScript
- License: not declared
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/rohitg00-pro-workflow

## The correction loop pro-workflow is built around

The README opens with a specific complaint: you correct Claude the same way 50 times, explain conventions at the start of every session, and lose the learnings when context compacts. That is the problem statement, and the project's answer is to put a single SQLite store underneath every session rather than relying on the conversation window.

The intended audience is narrow. This is for people already running Claude Code as their main coding agent, on a codebase they return to often, who notice that the same instruction has to be repeated. The README's own framing is that "every Claude Code user hits this wall", which is marketing, but the mechanism it proposes is concrete: a correction becomes a stored rule, and stored rules are loaded again at session start.

The second half of the pitch is a knowledge plane. Instead of researching a topic in three separate sessions, you create a wiki, and the wiki persists on disk with an FTS5 shadow index. The README claims that after a week of auto-research your wiki is denser than the curated lists you started from. That is an unverified claim about output quality and should be treated as a design goal, not a measurement.

## How the memory and wiki layers actually work

Two storage ideas sit side by side. Corrections become rules in SQLite, and rules are full-text searchable through FTS5. On session start, the SessionStart hook loads the learnings and lists your wikis. On prompt submission, the UserPromptSubmit hook auto-injects the top wiki hits when the prompt looks relevant. That is the data flow described in the README: hook reads the prompt, queries the index, injects matching content into context before the model answers.

Wikis are a second structure on the same store. The README describes them as persistent research wikis on disk plus an FTS5 shadow index, queryable from any session and optionally grown by an auto-research loop. The word shadow matters: the index is derived, the pages are the artifact. A wiki is created with a slug, a title and a flavor, and individual pages are addressed by path, as in the example that references wiki/concepts/episodic-mem.

The repository layout supports the description. There are top-level directories for hooks, skills, commands, agents, contexts, rules and templates, plus a src directory with a TypeScript build and a schema.sql copied into dist during the build. The package depends on better-sqlite3 at runtime, which is the only production dependency listed. The README counts 41 skills, 8 agents, 23 commands and 37 hook scripts across 24 events. Those are inventory numbers, not quality signals, and they also mean a large surface area to keep coherent across releases.

## Installing pro-workflow and running the first commands

There are two install routes. Inside Claude Code, the README uses the native plugin marketplace:

```bash
/plugin marketplace add rohitg00/pro-workflow
/plugin install pro-workflow@pro-workflow
```

For other agents, the README points at the cross-agent installer. It installs the skills and commands into each agent's native skill directory, and the README is explicit that you must use the GitHub owner/repo form, not the bare name.

```bash
npx skills add rohitg00/pro-workflow
```

After that, the README says to run skills sync to register the skills with the target agent's config. If neither path works, there is a manual route: clone, build, and copy the templates, skills, commands and hooks.json into the agent's directories, adjusting destinations per agent.

The first-run check is two commands. /doctor confirms the SQLite store, hooks and skills load. /wrap-up runs the end-of-session ritual and is described as a no-op on a fresh install.

```bash
/doctor
/wrap-up
```

If /doctor reports KB: missing, the README gives a recovery command: change into the installed plugin directory and run npm install followed by npm run build, because the SQLite components need a build step that some marketplaces skip. That failure mode is worth knowing before you file a bug.

```bash
cd ~/.claude/plugins/*/pro-workflow && npm install && npm run build
```

The five commands the README says cover most daily use are /learn-rule for capturing a correction, /wrap-up for ending a session, /wiki init for a new research wiki, /develop for a research-plan-implement cycle on a hard bug, and /smart-commit before a pull request.

## Where pro-workflow breaks down

The memory only works if the correction was captured. Nothing in the described flow guarantees that a rule is written; the README shows a proposal-and-approval step where Claude proposes a rule and you approve it. If you correct the model in passing and never run /learn-rule, the correction is not in the store, and the next session starts from the same blank slate. The compounding effect depends on a habit, not on an automatic capture.

Auto-injection has a context cost. The UserPromptSubmit hook injects wiki hits when it judges them relevant, and the README does not describe the matching threshold or a way to cap how much gets injected. On a large wiki, a wrong match spends tokens on irrelevant pages. The project tracks cost, per the README's mention of cost tracking, but the injection policy itself is not documented in the README.

The install is heavier than a plugin usually is. The SQLite layer is a native module through better-sqlite3, which needs a build step, and the README already documents marketplaces that skip it. The manual path requires Node 18 or later, npm install and npm run build before anything works. On a machine without a working native build toolchain, the memory layer is the part that fails.

There is also a licence discrepancy to resolve yourself. The README badge says MIT, and package.json declares "license": "MIT", but the repository metadata supplied for this project lists the licence as unknown. If licence terms matter to your organisation, read the LICENSE file in the repository rather than the badge.

## How it differs from plain CLAUDE.md files

The obvious alternative is the one most Claude Code users already have: a CLAUDE.md file, or a set of instruction files, checked into the repository. That approach is simpler and has no runtime. Instructions live in git, review like any other change, and travel with the repository. The difference is retrieval. A CLAUDE.md is loaded whole, and it grows until it is either too long to be useful or too trimmed to cover the cases you care about. There is no query step and no per-prompt selection.

pro-workflow replaces the flat file with a searchable store. Rules are rows, retrieval is an FTS5 query, and injection happens per prompt rather than once per session. That is a real architectural difference, not a packaging difference, and it is the reason the project needs a build step and a database at all.

A second alternative is the agent's own built-in memory or project rules, which vary by product and are outside what this repository documents. If your agent already persists instructions in a way you trust, the marginal value here is the wiki layer and the hooks, not the rule storage. The README's own roster notes are a reminder that the surrounding tooling moves: it states that windsurf relaunched as Devin Desktop and that gemini-cli was superseded by the Antigravity CLI for consumers, while the adapter names still resolve. An adapter list with that kind of churn needs maintenance.

## Maintenance, upgrades and what the repository leaves open

The last push to the repository was on 2026-08-31, which is recent, and the repository is not archived. The release history is uneven in cadence: v3.1.0 and v3.2.0 landed two days apart in late March 2026, v3.3.0 followed on 2026-05-09, and package.json already declares version 3.4.0 with no matching release entry in the list. That gap between the manifest version and the published releases is the kind of thing to check before pinning a version in a team setup.

The upgrade cost is not just npm. The project ships hooks, skills, commands, agents, contexts, rules and templates, and the counts in the README (41 skills, 8 agents, 23 commands, 37 hook scripts across 24 events) describe a lot of files that can drift between releases. If you fork or edit the skills locally, an upgrade path is not described in the README. Rollback is not documented either. There is no mention of a migration step for the SQLite schema, and schema.sql is copied into dist during the build, so a schema change across versions is a question the documentation does not answer.

On licensing, package.json and the README badge both say MIT, which for a plugin that runs inside your editor and writes a local database is the permissive end of the spectrum. That is the extent of what the repository states; anything about your obligations is a question for your own legal review, not for this article.

## Conclusion

Adopt pro-workflow if you run long Claude Code sessions on the same codebase and keep re-explaining the same conventions, and if you are willing to keep a Node toolchain plus better-sqlite3 building on your machine. Skip it if you want a managed service, if you need a documented data-retention or rollback story, or if your agent is not one of the adapters listed in the README. Before trusting it, run /doctor and confirm the SQLite store and hooks load, then open the LICENSE file in the repository, because the README badge says MIT while the repository metadata does not state a license.

## FAQ

### What is pro-workflow?

It is a Claude Code plugin, also distributed as a cross-agent skill bundle, that keeps corrections as SQLite rules and research as FTS5-indexed wikis. The README describes it as self-correcting memory plus a persistent knowledge plane on one SQLite store.

### How do I install pro-workflow in Claude Code?

The README uses the native plugin marketplace: run /plugin marketplace add rohitg00/pro-workflow, then /plugin install pro-workflow@pro-workflow. For other agents it gives npx skills add rohitg00/pro-workflow, followed by skills sync.

### What should I run after installing pro-workflow?

The README's first-run smoke test is /doctor, which confirms the SQLite store, hooks and skills load, then /wrap-up, which is a no-op on a fresh install. If /doctor reports KB: missing, the README says to run npm install and npm run build inside the installed plugin directory.

### Which agents does pro-workflow support besides Claude Code?

The README lists adapters including cursor, codex, gemini-cli, opencode, github-copilot, droid, windsurf and others, and states that MCP works across every agent in the list with the same setup. It also notes that some adapter names target products that have since been renamed.

### Is pro-workflow free?

The README badge and package.json both declare the MIT licence, while the repository metadata supplied for the project does not state a licence. The README does not describe any paid tier or pricing.

## Sources

- [Issues](https://github.com/rohitg00/pro-workflow/issues)
- [Project website](https://rohitg00.github.io/pro-workflow/infographic.html)
- [README](https://github.com/rohitg00/pro-workflow/blob/main/README.md)
- [Releases](https://github.com/rohitg00/pro-workflow/releases)
- [rohitg00/pro-workflow on GitHub](https://github.com/rohitg00/pro-workflow)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rohitg00-pro-workflow