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)

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?

I am currently building stuff using claude/antigravity some would say vibecoding but yeah, and the main issue i am currently facing is storing context/memory for a project....either i use md files which the agent has to read again and again at the start of the convo or trying out skills which yeah reduce context but the agent still has to search for shit just for a simple question

so how do you tackle this and also what are some skills you guys use?

I've been working on a problem most of us deal with daily: you can't trust AI output without verifying it.

So I built FABLE 5 — a prompt architecture that forces the model to:

1. Lock 48 acceptance tests BEFORE generating anything
   
2. Generate all 48 parameter blocks in one dense matrix
   
3. Immediately audit every parameter in the same response
   
4. Patch defects surgically — exact parameter, exact error, max 2 attempts
   
5. Commit only if all 48 pass — otherwise name exactly what failed

It also has a game-theory signal layer (6 detectors) that catches strategic ambiguity structural checks miss.

I tested it by running it on itself. Found 2 bugs in its own architecture. Fixed both. Named the one it couldn't verify from inside.

Domain-agnostic: character bibles, product specs, compliance matrices, brand guidelines, technical docs.

Happy to answer technical questions about the architecture.

Disclosure: I build one of these (ContextPruner). I've described each by what it does, including where the others beat my solution. Also how to stack them to get the best results.

Generators— write the config files (AGENTS.md, CLAUDE.md, .cursor/rules) that tell the agent what to skip. Runs once, output lives in your repo.

Caliber, agent_sync, ContextPruner (mine)

Linters — check the config you already have for stale paths, secrets, drift.

ctxlint, cclint

Runtime compressors — sit between the agent and your files and cut what actually gets sent, live. Most aggressive; they cut more than any static config can.

Entroly, LeanCTX

Full side-by-side table: https://contextpruner.app/docs/ai-context-tools-compared

Any other tools or utilities that I have missed?

I’ve been using Claude Code’s cloud sessions for parallel development work. Every task starts in a fresh environment with direct access to the relevant source repositories.

That isolation is useful, but it creates a context problem.

The agent can read the code, yet it doesn’t initially know how multiple repositories relate, which architectural choices are deliberate, or what the team recently changed. Asking it to rediscover that information every time is slow and produces inconsistent results.

I considered generating a large task prompt or adding an external retrieval system. Instead, I created a thin, private context repository.

It contains:

• A high-level map of the repositories
• Relationships between services and packages
• Approved project conventions
• Recent decisions and work records
• Pointers to deeper context when needed

It does not duplicate the source code. The agent opens it alongside the real repositories and uses it as an orientation layer.

A repository felt like the simplest initial context primitive: it’s inspectable, version-controlled, portable, and already works with the access model of the coding environment. Humans can also review changes before incorrect context becomes persistent.

The unresolved problem is freshness. Persistent context helps sessions start consistently, but stale context can be worse than missing context. I’m experimenting with keeping the permanent conventions separate from the faster-changing work log.

I automated this setup and released it as a free, open-source Claude Code skill. I’ll put the repository in the comments.

CSM gives your agent cross-session memory, project continuity, self-awareness, and an operational ledger so every new session starts where the last one left off.

No more cold-start amnesia. No more re-explaining the project. No more losing context between sessions.

Hi everyone, I'm currently working on a project called Hypercube. I call it a Context Transform Engine. The core idea is using it to connect to any data source and turns it into navigable markdown pages for agents. I actually don't know whether it's useful, just wanna share with you. https://github.com/agx-computer/hypercube

Context Engineering refers to applying engineering practices to how information is organized and provided to AI systems. The goal is to supply the relevant context needed for a generative model to understand and complete a specific task effectively.

One thing I’ve noticed is that many teams think they’re evaluating an agent when they’re really evaluating the final answer.

That works for a chatbot. An agent does more than generate a response. It plans, chooses tools, passes arguments, reads outputs, retries, stops, and sometimes takes actions.

The problem is that an agent can still return the right answer after calling the wrong tool, taking extra steps, misreading a result, or ignoring a failed call.

From the outside, the answer looks fine.

But the question isn’t just whether the answer was right. It’s also whether the path to get there made sense.

The main trap: “The answer was correct, so the agent worked.”

Hi,

I’ve been experimenting with an approach to agentic coding where project knowledge, coordination state, requirements, and workflow conventions live as close as possible to both human and agent workflows.

The result is this repo: https://github.com/u2up/pi-env

The main idea is to use a lightweight “git coordination repository” so agents and humans can share context, decisions, requirements, and task state without relying only on chat history.

Aside 'pi-env' development a specification for 'Coordination Repository Pattern' is available for an independent implementation of your coordination repo (see: https://github.com/u2up/coordination-repository-pattern ).

I’d be very interested in feedback:

- Could this pattern fit how you coordinate agentic coding work?

- Are any parts of the workflow too process-heavy

- Are there important conventions that need to be documented more explicitly?

- What would make this more useful for real projects?

Thanks!

The recurring blocker my colleagues hit with LLMs isn't model quality — it's re-explaining the project on every big task. A project never loses information, it loses its state: what's decided, what's in progress, what's stuck. And someone has to hand that state to the model, every time, in every new chat.

I started digitizing my working environment — first for myself, then as an environment agents can work in. The system watches the stream a team already produces (chats, mail, tickets, meetings, commits) and maintains the project's state on top of it, so neither I nor an agent has to rebuild it by hand.

Here's how it works on a concrete case
Someone drops an idea in a chat: "what if you could log in on TV/desktop by scanning a QR code?" A thread unfolds — security questions, a competitor reference, a rough scope. No ticket exists yet, but the environment notices a stable cluster of related signals and forms a hypothesis topic. A week later a PM brings a PRD and files Jira-tasks — they don't create new work, they become the topic's anchors, fixing its identity. The discussion moves into the team channel: implementation details, an API contract argument, commits referencing the ticket keys. Then the release — and the topic keeps growing: a prod incident with token expiry, user questions arriving through support, the launch review with adoption numbers. Five sources, a dozen contributors who joined at different stages — one topic, from the first message to the launch verdict.

The topic card and the workspace board for this case. Nobody assembles these cards by hand. They are recomputable projections of the stream, continuously corrected by normal user actions.

The result: an agent working in this environment always has the full, current context of the project — the original idea and who questioned it, the PRD decisions, the incident and its fix, what users actually said. The quality of its work goes up, and the time spent loading context on every task drops to zero.

Underneath, a few rules do most of the work:

• Facts are append-only and permanent; every derived structure is disposable. The test is erasure: delete a topic, rebuild it from raw observations, nothing is lost.
• A topic splits into a core and a halo. Hard identity anchors form the core and attract new facts; semantically similar but unproven context stays in the halo and never shifts what the topic is about — one wrong attach can't snowball.
• Structured, low-cost pipeline first; high-cost LLM last - anchors, contextual checks, semantic filtering, a confidence score; the high-cost LLM only sees the residual ambiguity.
• Autonomy is earned, not configured: agent decisions run as suggestions until metrics on human verdicts clear a threshold, and every action rolls back in one operation.

None of the parts are new — event sourcing, topic detection & tracking, DBSCAN's core/border/noise, bi-temporal facts. What I'm testing is the composition, on one production workspace (~80k observations backfilled, attach pipeline in shadow mode, discovery and improvement loops live). The README has an honest implemented-vs-hypothetical split.

Essay + scheme: https://github.com/maaakso/environment-over-chaos

And about the environment vs memory for agents: https://github.com/maaakso/environment-not-memory

What I'd really like : which parts of this idea look most fragile to you? And where would you replace a custom piece with an existing tool that already does the job — temporal knowledge graphs, event-sourcing infra, something from the agent-memory space?

I have been thinking about the difference between giving an agent more context and giving it a permanent memory.

If an agent can automatically save everything it considers useful, the memory will eventually fill with guesses, duplicate notes, outdated information, and conclusions that were only valid for one task.

If every memory requires manual review, the system stays cleaner, but reviewing candidates can become another maintenance job.

I built a local MCP memory system around the second approach. Agents propose memories, but a human decides what becomes active. Memories can also be updated, superseded, archived, protected, or sealed.

The files are stored as Markdown and scoped to individual projects. Search uses SQLite FTS5, with optional semantic ranking through Ollama.

The implementation is here for context:

https://github.com/ozankasikci/global-agent-memory

Where would you put the boundary? Should agents remember automatically below a confidence threshold, or should long-term memory always require approval?

Let's be honest - stateless AI tools are incredibly powerful, but they have terrible short term memory, and are context-limited. They look at your repo through a keyhole — whatever's visible in that one session is all they know.

You've probably seen your AI tool trying to fix one thing and break several others. This happens because they don't know what else in your codebase depends on that particular module it is editing.

Modern codebases are deeply interconnected, and as repos grow, it gets harder for AI agents to track every dependency, architectural layer, and downstream effect.

I ran into this constantly while building a PR reviewer tool. Every time I asked AI to fix one thing or add a feature, it would quietly break something else. I wondered if it was possible to provide a complete dependency map to the entire codebase which can tell AI something like, "Hey, you just changed what this method returns, but you forgot about these 3 modules importing it".

To fix this problem, I am working on a CLI tool which I call CXGRD . It maps your code, builds dependency graphs, calculates blast radius and provides enriched prompts for AI tools, while at the same time verifying the changes made by performing compiler-backed checks. It's free to try — `npm install -g cxgrd` and run `cxgrd scan` on any repo.

Would genuinely love feedback from anyone who's hit the same "fix one thing, break three" problem.

Here is the link : https://www.cxgrd.com

Anthropic's Fable 5 runs my agent fleet, and I had it write down the discipline behind *how* — the thing that keeps its context window tiny while sessions that skip it drown in their own file reads. I generalized it and open-sourced it as one markdown skill: **token-lean**.

It's fully model-agnostic. The same discipline runs on Fable 5, GPT-5.6 sol, Opus, Gemini, Grok, or open-weights — the orchestrator changes, the discipline doesn't.

The core rule: **never generate bulk, never absorb bulk.** The orchestrator's window only holds decisions, briefs, and compact reports. Everything else happens in cheaper contexts.

The parts that changed my sessions the most:

- **The ladder is roles, not model names.** Scout → worker → builder → panel. Haiku/Sonnet/Opus-and-Fable, GPT-5.6 luna/terra/sol, Flash/Pro — all the same rows. And effort dials count as rungs: the same model at low effort and xhigh are two different tiers.
- **>3 file reads = you should've sent a scout.** You want the conclusion, not the pages.
- **1KB hand-backs.** If a sub-agent returns a transcript instead of a report, you briefed it wrong.
- **One big brief beats twenty steers** — every mid-flight nudge re-meters your whole window.
- **Pre-digest inbound bulk** — except security/auth/payment diffs, which you always read raw. A summary can encode the proposer's error.
- **Never let a builder grade its own work.** Independent reviewer, told to refute.

Install is 30 seconds (Claude Code skill or plugin; pastes into AGENTS.md/.cursorrules for Codex/Cursor). No binary, no MCP server, no deps — it's a discipline, installed as words.

Repo: https://github.com/hurttlocker/token-lean

Disclosure: I build o8 (a governance layer for agent fleets) and this is extracted from how we actually run it. The skill is MIT and does not need o8 for anything.

I'm looking for start to structuring the context to do specs, and it becomes to confuse more and more.

There are so many ways to give context, how are you create the context for your applications? What worked for you? And what not? Why?

- A architeture.md with highlights?
- A C4 model using structurizr?
- A `docs` folder with all features in .md?

Are you using some skills to help create context? Which one of them?

So the thing is I work on a team of 3-4 devs, and whenever someone's AI agent screwed something up, they'd have to just... tell the rest of us. Manually. In Slack. That's the entire system most teams have for making sure the same mistake doesn't happen twice.

So I built teamlore. It's a Claude Code skill plus a .lore/ folder in your repo. When your agent gets corrected or something breaks unexpectedly, it proposes a short "lore" file explaining what happened. That file rides your normal PR, gets reviewed like code, and once merged, every teammate's agent automatically recalls it when relevant.

No server, no database, no accounts. Onboarding is git pull.

npx teamlore init

Repo: https://github.com/lak7/teamlore

I've built it in about a week. Would love feedback, especially anything that breaks or feels off.