User Intelligence

Workspace Intelligence holds the project. User Intelligence holds the person behind the work.

Two engineers in the same repository do not want the same thing from an agent, and the difference is not cosmetic. It is how much the agent should decide on its own, when it should stop and offer options instead of implementing, how much verification counts as enough, and which way you go when two designs are both defensible.

That is a real body of knowledge, and without somewhere to keep it, it lives in the corrections you type again in every new session.

What it models

Execution preferences

Whether you want an incremental refactor or are open to a rewrite. Whether you expect to see options before an implementation, or would rather the agent just proceed on a class of change. How much abstraction you consider warranted. Which kinds of change you expect to be asked about before they happen.

Decision patterns

Which trade-offs you tend to take. Performance against maintainability. Building against adopting. How strictly you hold backward compatibility. What you weigh first when a product decision is in the way of a technical one.

Quality expectations

How much testing you expect. When you want a benchmark rather than an argument. When research is enough and when it has become a substitute for shipping. What you mean by done, and what level of validation goes with it.

Collaboration style

How autonomous the agent should be. When you expect a question. When you expect a choice. How you want work reported back, and at what density of explanation.

What it does not model

Not who you are. Not demographics, not personality, not anything inferred about you as a person. The unit is a working preference about how software work should be done, and every one of them is something you could have said out loud.

Three kinds of statement are refused outright rather than stored:

• Anything personal. Health, religion, politics, sexuality, ethnicity, finances and private relationships are outside what Pathrule keeps, whatever the sentence was about.
• A rule wearing a preference. A preference is advice to an agent. A statement phrased as a ban ("never", "must not", "forbidden") would read like a project requirement it has no authority to be, so it is not stored. If something truly must never happen in a project, it belongs there as a rule.
• A fact about a project. "In this repository we use the shared config helper" is true of one codebase, not of you. Stored as yours, it would follow you into a client's repository where it is wrong. That is workspace knowledge, and it stays with the workspace.

How it learns

You teach it. Run pathrule me teach with the sentence you would otherwise keep typing into new sessions:

pathrule me teach "Show me options before implementing anything that changes a public API"

The optional local model reads the sentence on your own machine and turns it into a structured working preference. Whatever it concludes has to be present in your own words: it may not paraphrase you into a preference you never expressed, and when it cannot point at what you wrote, nothing is stored and the CLI tells you why.

What you teach
      |
Checked against your own words
      |
Refused, or stored as a preference
      |
Active, and delivered where it applies

Concretely, if you keep saying some version of "don't turn every implementation into a research project", the useful representation is not a saved quote. It is a working preference:

Prefer implementation once the primary correctness
questions are resolved.

Source:     you told Pathrule
Applies:    across workspaces

Teaching needs an Apple Silicon Mac with the local model installed. Everything else on this page, including delivery, works without it.

Changing your mind

When you teach a new preference that contradicts an earlier one about the same kind of work, the new one replaces it. The old one is retired, not deleted, and keeps a pointer to what replaced it, so "why did this change" always has an answer. Two preferences about different kinds of work simply both hold.

Who "the user" is

Preferences are written about you, so when you talk about the people who use what you build, the wording could quietly turn them into you. "Solve things without showing errors to users" would read to an agent as "do not show me errors", which is the opposite of what you meant. When your own words were about your users, the preference keeps saying "end users".

Where a preference applies

User Intelligence belongs to you, not to a repository. Where each preference applies is a separate question.

• What you teach applies everywhere. It was not learned from a project, so it is not kept in one.
• You can keep one to a workspace. pathrule me scope <id>, run inside a repository, keeps that preference to the workspace you run it in. pathrule me scope <id> --everywhere lets it apply in every workspace again.

How a preference reaches an agent

Before a turn, Pathrule picks the preferences that apply to the work about to happen.

• Only active ones. A preference that is not in use yet is listed by pathrule me list and never reaches an agent. Retired and rejected ones are not used either.
• Only the ones in scope for the workspace, as above.
• Only the ones about this task. A preference about how to work with you applies to any task. A preference about a kind of work, such as architecture or migrations, reaches an agent only when the task is about that.
• A small number per turn, strongest first. If more apply, the weakest are the ones left out.
• Each one says where it came from, so an agent can weigh "you said so" for what it is.

They arrive through the prompt hook, each one once per session, under a heading that tells the agent the workspace's rules and required checks come first. Today that means Claude Code and Codex sessions. Cursor and GitHub Copilot have session and tool hooks but no prompt hook, and Windsurf has no hooks, so preferences do not reach them. See how hooks work.

Authority: what happens when you and the project disagree

A user preference does not override project truth.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
Rule: run migration verification before completion.

The rule applies. It is a requirement of the workspace, and a preference for less verification is not a reason to drop it.

The general rule, and it is worth stating plainly:

• Workspace Intelligence represents project truth and project requirements. Its rules and required checks are hard requirements.
• User Intelligence shapes collaboration: how the work is approached, how much is done autonomously, how it is reported. It does not redefine what correct means.

Where the two are simply about style, your preference applies. Where the workspace states a safety or correctness requirement, that requirement stands.

The same holds without a workspace rule. A preference that could mean less verification is held back whenever the work touches authentication, payments, data migrations, cryptography or security. Mistakes there are silent and expensive, and a preference formed on everyday code says nothing about whether it is safe there.

What you control

Everything. User Intelligence is inspectable rather than implicit. For each preference you can see:

• Its status: candidate, active, retired or rejected.
• Where it came from, and how sure it is.
• Where it applies: across workspaces, or only in one.
• Why: the words it rests on, with dates.

And you can:

• Teach a preference directly.
• Forget one. It stops being used, and it is kept as rejected so the same statement does not bring it straight back. Add --delete to remove it entirely.
• Keep one to this workspace, or let one go everywhere.
• Check what an agent would receive for a task before you start it.

An inference you never see is an inference you cannot argue with, which is why every preference is one command away.

From the command line

pathrule me list                    # what is in use, and what is not yet
pathrule me teach "I prefer incremental refactors"
pathrule me explain <id>            # the evidence behind one preference
pathrule me scope <id>              # keep it to the workspace you run this in
pathrule me scope <id> --everywhere # let it apply in every workspace
pathrule me forget <id>             # stop using it
pathrule me forget <id> --delete    # remove it entirely
pathrule me context "add a payments webhook"

pathrule me context prints exactly what an agent would receive for that task, and which preferences were held back and why. It is the quickest way to check that a preference reaches the work you meant it for, and only that work. Every subcommand accepts --json.

Moving between projects

Open a different repository and the project knowledge around you changes completely. The preferences you taught, unless you kept one to a single workspace, come with you.

That is where the two meet in a turn: the workspace contributes what is true and required here, you contribute how the work should be done, and the delivery keeps the project's requirements above your preferences. See Agent IR.

Limits worth knowing

• Matching is by words, not meaning. A preference reaches a task that shares its terms. One phrased very differently from the task can miss it.
• Teaching needs the local model, which runs only on Apple Silicon Macs.
• Preferences reach only clients with a prompt hook: Claude Code and Codex.
• It abstains rather than guesses. A sentence it cannot ground in your own words is not stored. Missing a preference costs you one more sentence; inventing one would misrepresent you to every agent you work with.

Privacy

The inference that turns what you teach into a structured preference runs on your own device, and your preferences are kept in a private store on your machine.

If you share a workspace with a team, what syncs is the workspace's knowledge, not your personal working preferences. And when you run Claude Code, Codex or another agent, that agent's own provider boundaries apply to whatever reaches it. The security page keeps those boundaries separate, because collapsing them into one sentence is how a claim stops being true.

What to read next

• Workspace Intelligence: what the project contributes, and why its requirements win.
• The local model: what runs on your device and how to install it.
• CLI command reference: every pathrule me subcommand alongside the rest of the CLI.