Core concepts

Pathrule has a small data model on purpose. Three kinds of content, a tree of nodes, and a path based scope. Once you have the shape in your head, everything else in Pathrule is a thin layer on top.

The workspace tree

A workspace is a tree of nodes. The root is the workspace itself. Children are folders or files that mirror the parts of your repo your team writes knowledge about.

/                            workspace root
  /apps                      folder node
    /apps/web                folder node
      /apps/web/auth         folder node
        /apps/web/auth/login.tsx   file node

You do not need to create the tree by hand. When you write a memory at /apps/web/auth, Pathrule materialises the chain of nodes on demand. Empty nodes do not cost anything and they are easy to delete later if the path stops being useful.

Memories

A memory is a short markdown document a teammate writes down so the assistant can read it later.

• Facts: schema notes, design decisions, gotchas.
• Postmortems: what broke, what we learned, how we patched it.
• Conventions: the way this team prefers to do a thing.

Memories are advisory by default. They appear in the assistant's context when the hook decides they are relevant to the path the assistant is working in.

Rules

A rule is a constraint the assistant must follow in a scope.

Rules have:

• A scope type. folder means the rule applies under a directory. file_type means it applies to a file glob like *.tsx. project means it applies everywhere in the workspace.
• A priority. high for the constraints that matter most, medium for general guidance, low for stylistic preferences. Priority controls how strongly a rule surfaces, not whether it blocks.
• An enforcement mode. advisory rules ride along as context and the assistant decides how to apply them. strict rules can block a matching change before it lands.
• A body. A short imperative bullet list works best.

Higher priority rules surface first when their scope matches the current path. Lower priority rules surface when they are likely to help.

Skills

A skill is a named procedure the assistant can invoke instead of re deriving the steps every time.

Examples:

• replay-stripe-webhook: a checklist with the exact CLI command and the safety steps before running it.
• regenerate-fixtures: the script path, the inputs, and the expected output.
• release-check: the pre release checklist that the team always wants the assistant to walk through.

Skills are discoverable by name. The assistant can ask Pathrule for the skills attached to the current path and pick the one that matches the task.

Path scope

Every memory, rule, and skill lives at a node path. The path decides where it surfaces.

• A memory at /apps/web is relevant for any work under apps/web.
• A memory at / is relevant everywhere.
• A skill at /services/billing is offered to the assistant when work happens inside the billing service.

Path scope is what keeps the assistant's context window small. A UI tweak in apps/web/dashboard does not need to see the rules about database migrations.

Priority and enforcement

Priority and enforcement are two independent settings.

• Priority (high, medium, low) ranks how strongly a rule surfaces. Use high sparingly, for the constraints that matter most.
• Enforcement (advisory or strict) decides what happens on a violation. Advisory rules are surfaced as context and the assistant decides how to apply them. A strict rule with a matching pattern is enforced by the local hook, which blocks the change before it lands and surfaces the rule as the reason.

Strict enforcement runs through the hook on Claude Code, Cursor, and Codex. The Remote MCP surface has no hooks, so it surfaces every rule as context only.

Where this fits

• How hooks work describes how the runtime picks the slice to send.
• MCP overview lists the tools the assistant uses to read and write nodes.
• Quickstart is the fastest way to see this model in action.