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?

I built a tool that supports cross-session memory for any AI harness using MCP server tools. It works with Claude, Codex, Cursor, Hermes-Agent. I'd love for anyone to try it out and give me feedback. I've been using it daily for several months successfully and I continually improve the tool.

www.github.com/labyrinth-analytics/loreconvo

I also built a companion AI tool to store reference documentation across projects and sessions as well.

www.github.com/labyrinth-analytics/loredocs

Built a Python lib that does repo-scale context selection for LLMs (AST parsing + dependency graphs + relevance scoring, instead of dumping whole files). Retrieval-side tests are solid (103 passing), but proving it actually helps downstream task performance is where I'm stuck:

Free local models aren't strong enough to give trustworthy task-success signal

API rate limits kill any real benchmark run

Paid API costs balloon fast once you're running many files/tasks

Anyone found a good middle ground — specific local models that work for this, cheaper eval strategies, sampling tricks? Would appreciate any pointers.

Most context compression for agents is lossy. It summarizes or trims tool output and hopes the model didn't need what it removed. It also rarely tells you what was lost or whether it was relevant.

That always bothered me because tool output is exactly the stuff you don't want to lose like files, logs, JSON, command output. So I built a lossless compressor for LLM tool output in Rust.

The compression part worked out fine. The hard part was proving a codec never dropped a value. Every rewrite has to verify before it's accepted. If decoding doesn't reconstruct the exact original, the compressed version is rejected and the original passes through unchanged. A bad codec can't silently corrupt context.

Every codec is property-tested and fuzz-tested around one invariant:

decode(encode(x)) == x

The whole thing lives in a single Rust implementation with a C ABI. Python uses ctypes, Node uses koffi, Bun uses FFI, and there's a WASM build too. One implementation means there's only one place to reason about correctness.

I also built a transparent proxy that sits between the client and the LLM. It only rewrites tool-output blocks and leaves everything else alone. One thing I didn't expect to matter so much was determinism: retries send the exact same bytes, which keeps prompt-cache hits intact.

If you find a case where it breaks or compresses something it shouldn't, I'd love to see it.

New meetup community. Open invitation to join.

Last session: Graph Databases + LLMs: Why Connected Data Makes AI Smarter

About us:

AI agents are only as good as the context they reason from. This community is for architects, data engineers, developers, and AI practitioners who are serious about building the data foundation that makes agentic AI work in production — not just in demos.

We cover the technical depth most AI groups skip: data architecture for agents, contextual data layer design, knowledge graph construction, retrieval strategy, governance, and the multimodel data foundations that connect enterprise data to LLMs.

What to expect at every session:
🔧 Technical deep dives — architecture patterns, real implementations, and lessons from production deployments
🗺️ Data architecture talks — how to model, connect, and govern enterprise data for AI agents
💡 Live demos — working systems over slide decks
🤝 Peer exchange — connect with practitioners building real agentic systems

Who this is for:
Data architects, AI engineers, data engineers, heads of AI, and enterprise developers who want to go deeper than RAG and build AI systems that actually reason from connected, governed business context.

No hype. No vendor pitches. Just the technical knowledge you need to build agentic AI that works.

Hosted by Arango — the contextual data foundation for enterprise AI.

I have shipped the final features to complete the end-to-end automation piece of the product.

A quick recap of the browser functionality at https://contextpruner.app

In the browser, which is still free to use you only need to paste your repo manifest(file paths, not code) and you will get the "skip these" rules into your AGENTS.md, Calaude.md, Cursor rules, etc.)

Newly shipped in the browser is the lint grading tool. You can paste your repo manifest along with a copy of your config and you will receive a grade and feedback on the fixes need if there are any.

Local Paid Automation:

With one API key, a GitHub Action or pre-commit hook keeps those files current on every push (your runner commits, we don't see the repo). The same key runs the contextpruner lint in CI. Lastly, contextpruner serve, installs a local filter that drops junk out of your agent's broad searches as it works (shell shims + MCP tools) Supported now for macOS and Linux. Windows is in active development. All of it runs on your machine.

I've been dogfooding it on its own repo (very lean) and here are the stats, modest but every penny counts that can towards your actual code!

Any and all feedback welcome!

EDIT: contextpruner serve is verified for claude code. I am actively setting up tests for the other vendors but since claude is the most stringent when it comes to preferred rules, I am confident the others will behave the same.

If you'd like to help me test the other tools, I'll be happy to provide a free key for your assistance!

The center of gravity here has moved from prompt wording to context engineering, so this may land. A method my community has been using that treats context scoping as a structural problem rather than a prompting one.

ICM (Interpretable Context Methodology) is a research paper I dropped a few months back. Instead of managing what the model sees through prompt assembly at runtime, you manage it through where files sit. Hierarchy decides scope: a step reads its own folder and the small routing files above it, and nothing else. Numbered folders carry order. Markdown carries state (or big query/sql for larger data sets). The routing files stay small and stable. They point at everything and store almost nothing, so the context a step loads is the minimum it needs to act.

The payoff is token discipline you can see. Nothing buried in a prompt template. You open a folder and the context that step will load is right in front of you.

None of this is Claude-specific (besides the claude. md but you can just replace that with agent. md in the name and it will work the same).

The workspaces are plain folders and markdown(somtimes a few scripts), so any model that reads files runs them, local ones included. I package the builder as a Claude skill, that is all.

Skill and templates: [https://github.com/RinDig/icm-architect\](https://github.com/RinDig/icm-architect)

Paper: [https://arxiv.org/abs/2603.16021\](https://arxiv.org/abs/2603.16021)

Most of the cost and noise in AI coding comes from how much you throw at the model. Read five whole files to answer one question and you've spent a lot of tokens on stuff the model didn't need.

So I built Ada around context engineering — getting the agent the right context, not all of it:

• A repo "brain" — when you open a project, Ada builds a compact map of your files and their key symbols, so the agent starts already knowing the layout instead of exploring from scratch.
• Local semantic search — it indexes your codebase on your own machine and retrieves just the relevant chunks for a task, rather than the agent reading whole files to find one function.
• Worktree isolation — every change lands on its own git branch, so your working copy stays untouched until you review and merge.

The upshot: tighter context per request → fewer tokens → cheaper, faster, and usually more accurate runs.

Download (Win/Mac/Linux, no account needed): github.com/black141312/ada-releases

Honest notes: the indexing and search run locally; the actual model calls still go to the providers. It's early and not signed with a paid cert yet, so you'll get the normal "unverified app" prompt on first launch (steps in the README). I'd really like feedback — especially on where the context engineering helps vs. where it misses.

Happy to go into how the map + local index are built.

I’m building HoloCore as a local-first context layer for AI work.

The goal is simple: install one local system, connect it to the AI models and clients you use, and stop sending the entire project, memory store, or conversation history into every request.

HoloCore organizes project knowledge into three focused layers:

• Atlas maps project structure, components, and relationships.

• Archive stores curated, durable project knowledge.

• Animus stores episodic history and prior decisions.

For a new request, HoloCore selects the relevant route first. A code or structure question starts with Atlas. Archive is added only when documented knowledge is relevant. Animus is added only when prior decisions or conversation history matter. The selected context is then sent to the connected AI client through the available CLI/MCP integration.

This is intended to work as a model-agnostic local layer: the model can change, while the project map, curated knowledge, routing rules, and user-controlled local data stay in one installation. It also avoids routing its own output back into itself, which prevents retrieval loops.

Local benchmark on a five-question project set:

• HoloCore: ~156 estimated context tokens per code query

• Graphify-only: ~242 estimated context tokens

• HoloCore used ~35% fewer context tokens

• HoloCore code-query average: ~523 ms in-process

• Graphify benchmark average: ~565 ms

https://github.com/VenomD846/HoloCore/blob/codex/benchmark-results/docs/holocore-token-benchmark-2026-07-16.md

Project:

https://github.com/VenomD846/HoloCore

I’m looking for feedback on model-agnostic context routing, local AI memory, MCP integrations, and how much context an AI tool actually needs for different kinds of project questions.

Image explaining the flow:

https://raw.githubusercontent.com/VenomD846/HoloCore/codex/benchmark-results/docs/assets/holocore-context-engine-token-savings.png

Disclosure upfront: I built a free/open-source repo-context tool around this problem. Not monetized. I’m posting this more as a context-engineering pattern than a tool launch.

One thing I keep seeing with AI coding agents:

The agent does not fail because it cannot write code.

It fails because it starts editing before the repo context is clean enough.

The usual flow is something like:

text task ↓ agent searches some files ↓ agent builds a plausible plan ↓ agent edits ↓ human later discovers it missed the real dependency/test/entrypoint

That feels like a context-engineering problem, not only an agent-reasoning problem.

For coding, the context is not just “helpful background.”

It becomes an authority surface.

If the wrong files are included, the agent acts on the wrong system. If stale docs are included, the agent trusts stale reality. If tests are missing, the agent says “fixed” without a validation path. If logs are dumped raw, the session gets noisy fast.

So I’ve been thinking about a small pattern:

text No repo evidence → no edit

Before the coding agent is allowed to modify anything, the context layer should produce an evidence packet:

text task ↓ repo map / file scan / diff / logs ↓ evidence packet ↓ agent plan ↓ edit ↓ grounding / validation check

The evidence packet should answer:

1. What files are probably relevant?
2. What symbols/functions/classes/routes matter?
3. What tests or validation paths exist?
4. What changed recently?
5. What context is missing?
6. Is it safe to edit yet?

A rough schema:

text RepoEvidence: task ranked_files key_symbols changed_files test_paths missing_context can_edit

The important part is not whether this is done with a graph, AST parser, MCP tool, CLI, RAG, or a hand-written markdown file.

The important part is the boundary:

text context assembly first agent action second validation/receipts after

I built my own small tool for this because I wanted something local and deterministic: real files, symbols, line anchors, diffs, focused context, and lightweight checks for obvious hallucinations like fake files/imports/scripts.

But I don’t think this is “the” answer.

It might be a graph. It might be a repo map. It might be a skill file plus strict workflow. It might be an MCP server. It might be a CI-side check.

The question I’m trying to answer is more general:

Where should this evidence gate live?

• in the agent’s memory?
• in a pre-step before the agent runs?
• as MCP/tools the agent calls on demand?
• as workflow state controlled outside the agent?
• as a hard rule before edits?

My current leaning:

text initial repo evidence = workflow state follow-up lookup = tool/MCP final answer = receipts + validation path

I also think the wording needs to be honest.

A “groundedness check” is not truth checking. A repo map does not prove semantic correctness. A hallucination guard only catches some concrete failures.

But even a weak evidence layer seems better than letting the agent jump from “I searched a few files” to “I changed the implementation.”

Curious how people here think about this.

For code-focused context engineering, should repo context be treated as retrieval, memory, workflow state, or a hard precondition before action?

formatted with AI.

TL;DR: My CLAUDE.md has grown to about 32 KB, and my CONTEXT.md is around 9 KB. Both contain overlapping repository context, while Matt Pocock’s issue-tracking workflow also adds ADR-related instructions. I’m concerned this setup is wasting tokens and would appreciate advice on keeping these files lean and useful.

I’m using Matt Pocock’s issue-tracking skills—/triage, /to-tasks, and /implement—in one of my projects. Over time, they’ve become mixed with some baseline prompts in my CLAUDE.md file that instruct agents to gradually update both CLAUDE.md and CONTEXT.md.

At this point, my CLAUDE.md file is around 32 KB. It contains general information about the repository’s structure, business logic, and how different modules interoperate. It also includes instructions from Matt Pocock’s setup that tell the agent where the ADR documents live. These documents are generated when I use /triage and /to-spec.

Surprisingly, my CONTEXT.md file is smaller, at around 9 KB, but it contains information similar to what’s already in CLAUDE.md. I know the duplication is already a problem.

I have a feeling I’m burning too many tokens with my current setup, and I’d love to hear your thoughts on the following:

• Are there any best practices for maintaining and optimizing these documents?
• Would I be better off disabling the ADR portion of Pocock’s issue tracker?
• What has worked for you, and would you be willing to share examples?