How knowledge compounds

It is easy to read Pathrule as a place to file memories, rules and skills by hand. That is the smallest part of it. The point is a loop that runs against real work and gets better the more the team uses it.

The loop has three moves: deliver, capture, score. They repeat every session.

Deliver before the work

Before the assistant starts acting, the path-scoped slice of your team's knowledge is already in context. You do not paste it, and the assistant does not have to go looking for it. Working in /apps/api/payments surfaces what is pinned there, plus what it inherits from the paths above. In Claude Code and Codex a prompt hook hands it over before the first tool call; Cursor, GitHub Copilot and Windsurf receive it through Pathrule's MCP tools when the agent asks. This is the delivery side most people see first, and it is covered in How hooks work.

Capture during the work

Knowledge does not have to be written in a separate sitting. Most of it accumulates from the work itself.

While the assistant works, it watches for things worth keeping: a decision you just made, a fix for a problem it kept hitting, a convention it had to be told, a gotcha that wasted time. When it finds one, it proposes saving it as a memory, a rule or a skill on the path it belongs to, and saves it through Pathrule's write tools. You can also ask it to save something directly.

Two properties matter here:

• You can see and undo every write. A write made by an assistant is marked as an assistant's, versioned and reversible. Pathrule does not edit or delete your knowledge on its own: stale or conflicting knowledge is raised as a refresh task for you or your agent to resolve.
• Upkeep stays close to zero. Because capture rides along with normal work, the knowledge base grows without a second job of writing docs. You can still author directly with the CLI, in the VS Code extension or through an MCP client whenever you want to.

What is written automatically, and what waits for a person

Some writes happen without a confirmation step, and they are named here so none of them is a surprise:

• An assistant's own writes. An assistant usually proposes first and saves once you agree. Pathrule does not add a confirmation step of its own in front of these writes; it makes each one visible and reversible instead.
• A decision you state. A sentence in your prompt that announces something lasting, such as "from now on", "we decided", "always" or "never", in any of the thirteen languages Pathrule knows the markers for, is saved at the workspace root exactly as you wrote it, unless a memory already says it. Pasted material, documents, code and lists are never read for this: what they contain is not your decision.
• A lesson a failing command taught. When a command fails and a variant of it with a flag or an environment variable added works later in the session, that variant is saved once at the root, so the next session does not rediscover it. Commands an agent runs only to look around are left out.
• The record of the work. What was delivered, what the assistant consulted and how the turn went are recorded as the work happens, because they feed ranking. See what Pathrule computes.
• A one-time seed, on a cloud workspace. The first time an agent asks for deep context, Pathrule saves the file path pairs it read from recent git history, the starting point of files that change together, and a few short technology memories at the workspace root, recognised from file names. File contents, diffs and commit messages are not read for this.
• Project learning. A finding an agent reached by reading your code is saved with the files it rests on and shared with every agent in the workspace, with no review step. It arrives as advice to verify, never as a rule, and only while its sources are unchanged in that checkout; a finding that turns out to be wrong can be retracted for everyone at once. See Project learning.

Everything else that was inferred rather than written by a person waits for one:

• The project scan your agent runs when you ask it to set up Pathrule for a project proposes memories, rules and skills, and only the ones you approve are written.
• Team Intelligence, on Pathrule Cloud, turns team evidence into suggested patterns. Only entries a person has verified reach agents.
• Fixes for stale, conflicting or duplicate knowledge change nothing until a refresh task is resolved, by you or by an agent you ask to resolve it.

Score, so the best surfaces first

Ranking decides which of the relevant candidates surface for a request and in what order. In Cloud mode, Pathrule also tracks which knowledge actually helped on similar work and uses it to order future results, so the most valuable surfaces first. Sessions stay sharp instead of noisy, and an entry an agent finds stale can be flagged as a refresh task for review. See Suggestions and self-audit for how that works.

Learning changes order, not eligibility. An entry still has to be relevant to the current request. A memory that helped several migrations cannot enter an unrelated design turn merely because it has a strong history.

How noise stays out of the prompt

The loop is deliberately selective. General documentation is offered for review instead of imported as live instruction by default. Inferred knowledge waits for a person, and every write is visible and reversible. Path scope limits where an entry can surface, and relevance to the request still applies inside that scope.

Delivery and use are measured after that. Knowledge an agent finds stale, contradicted by the code or duplicated is raised for review as a refresh task. Repairs are versioned and reversible, so the team can improve the set without losing its history.

The result is a small set of narrow, reviewable decisions and gotchas, not a repository-wide documentation dump. How Pathrule proves hard claims documents each gate.

Why the loop is the product

A static file or a single tool's built-in memory can do delivery. What compounds is the loop: every task can leave the team a little smarter, and the next session starts from that.

The compounding is not abstract. Each pass through the loop leaves behind something the next pass can use: a measured record of what was delivered and how the turn went, evidence about what helps for each kind of work, a relationship between two files that keep changing together, a failure attached to a path. What Pathrule computes lists each of those layers and what feeds it. Written entries alone do not compound, because nothing about them changes when the work goes well or badly.

Because the knowledge lives outside any single agent, it is portable. The same memories, rules and skills reach Claude Code, Codex, Cursor, GitHub Copilot and Windsurf through the CLI or the VS Code extension, and any MCP client through the local or Remote MCP. A native memory feature inside one tool does not replace this, because that memory stays inside that tool. The lasting value is the accumulated team knowledge, not any individual rule or prompt file.