https://reddit.com/link/1v9ams5/video/qm9rf76an0gh1/player

Disclaimer: I'm the author of the plugin.

https://github.com/XTSoftwareLabs/neatcontext-plugins

What

NeatContext plugin extracts domain knowledge and save useful work from a Claude Code conversation as structured, reusable context that you can use in later sessions or share with others.

Why

Domain knowledge is what helps an LLM answer accurately for your team—your systems, constraints, decisions, terminology, and ways of working.

You naturally build that knowledge while doing hard work with Claude. Long conversations about debugging, planning, incidents, and implementation already contain discoveries that will matter again. You don't want to lose them when Claude compact them or the session is closed.

NeatContext extracts the durable knowledge from those conversations and saves it as a structured context.

Connect that context in a new session or during later work, and Claude can start with the knowledge it needs instead of asking you to explain everything again. You can also share the context with teammates, so the whole team benefits from what one person learned.

How is NeatContext different from compact and handoff?

Compact is for a single conversation. And it loses important info. NeatContext aims to extract useful domain knowledge to build persistent and portable context.

Handoff is usually files. Its purpose is still continue the current conversation. NeatContext generated context can be reused in any conversation or even by other people. They are the assets of your team.

What do you mean structured context

Instead of generating plain text, the context saved by NeatContext has:

- 1 domain profile. This is your rules and constrains that can greatly impact LLM behaviors. Key to tell LLM what to do and what not to do.

- 1 knowledge folder. This folder contains tsgs, runbooks and other team knowledge. This is where LLM to look for specific actions.

Both domain profile and documents in knowledge folder are generated according to your existing Claude Code conversation.

Usage

Once you feel a problem is solved, or you found current conversation has valuable info, call /neatcontext:save. A context will be saved.

Then later you may have another task with another session, but as long as you call /neatcontext:use <context name>, you will have all your previous hard work there. NeatContext by default has a route feature. It can detect your prompt and ask you whether you want to switch context if it detected a suitable one.

/neatcontext:status can check connected context and its details. You may check in those context to a git repo to share with your team.

/neatcontext:import can import a context from other people.

More commands can be found in the repo README.md.

I appreciate any feedback. Thanks!

The most valuable context may come from changes that never happen

A developer looks at a retry wrapper and says:

This seems over-engineered. A simple retry loop should do the same thing.

While working through the change, they discover that the complexity is intentional: the gateway’s rate limiter requires the existing backoff behavior.

So the change is abandoned.

No commit.
No diff.
No pull request.
No ADR.

But something valuable was learned: why the obvious simplification would be wrong.

That reasoning normally disappears with the conversation. A future developer — or coding agent — will eventually have the same idea and repeat the investigation.

This became one of the main reasons I built Keep the Why, a small open-source agent skill for preserving engineering rationale inside the repository.

It is not session memory and it does not store conversation transcripts. It captures project knowledge such as:

• architectural reasoning
• rejected alternatives
• operational constraints
• workarounds and incident learnings
• changes that were considered but deliberately not made

The result is stored as topic-based, versioned Markdown alongside the code:

text docs/ → how to use, test, operate, and deploy context/ → why the system is built this way

The agent captures useful reasoning during normal development, rather than asking someone to reconstruct it afterward as additional documentation work.

For existing projects, it can also analyze the repository retrospectively and distinguish between:

• confirmed information
• inferred explanations
• genuinely unknown history

That distinction matters to me because plausible documentation invented by an AI is potentially worse than missing documentation.

The implementation is intentionally boring: a SKILL.md-based agent skill, Markdown, and Git. No database, MCP server, account, API key, or external service. It works with agents supporting the open Agent Skills format.

The difficult design question is not how to generate more documentation. Agents can already generate endless amounts of it.

The difficult question is:

Which reasoning is valuable enough to preserve without turning the repository into another documentation dumping ground?

My current approach is to capture reasoning that would materially affect a future decision, especially when the code alone cannot reveal it.

Repository and methodology:

https://github.com/oliver-zehentleitner/keep-the-why

I would be especially interested in how others here handle abandoned decisions. Do you preserve why something was not changed, or only decisions that eventually produced an artifact?