Importing a pattern

You can adopt any pattern in two ways. You can paste its token into any connected AI assistant, which lets Pathrule write the pieces onto the right paths for you, or copy the bundle by hand from the catalog.

The reference token

Every pattern has a reference token of the form:

::pathrule:package:<slug>

For example, the Next.js App Router pattern is ::pathrule:package:nextjs-app-router. The token is shown on each catalog page, ready to copy.

The ::pathrule: prefix is a reserved namespace. It is matched before the ::skill-name invocation path, so a pattern token is never mistaken for a skill and never triggers skill discovery. That separation holds in the prompt hook and in the context request alike.

Paste the token as plain text. Like a skill invocation, a token inside backticks or a code block is treated as quoted code and ignored. You can put several tokens in one prompt; each pattern is picked up once.

Importing by token

To add a pattern, paste its token into a prompt in a connected workspace. From there Pathrule does the rest:

1. It recognises the token. When Pathrule builds the context for your prompt, it detects the ::pathrule:package:<slug> marker and surfaces an import directive for that slug.
2. It previews before writing. A dry run resolves the pattern and returns its version, the problem it solves, its pieces and the paths it intends to use, without changing anything yet. This preview also reports the pattern's declared paths, stacks and dependencies, so the assistant can line the pattern up against your actual project.
3. It picks paths that match your tree. A pattern declares suggested paths, but real repositories differ. The assistant chooses a base that matches your layout and re-roots the pattern's paths under it, so the pieces land where they actually belong. In a monorepo, a Next.js pattern's /app rules can land under /apps/web/app.
4. It confirms on a mismatch. If the pattern targets a stack your project does not appear to use, for example a React Native pattern in a project with no Expo, the assistant stops and asks you whether and where to add it rather than importing blindly.
5. It writes the bundle. On confirmation, each piece is created through the normal write path: a memory becomes a memory, a rule becomes a rule with its scope type and priority, and a skill becomes an invocable skill tagged with the pattern it came from. Missing nodes along each path are created on demand.

The assistant then relays a one-line summary, for example how many rules, memories and skills were imported, how many were already present, and how many failed.

After import, the pieces are ordinary workspace content. They surface through the same hooks and retrieval as anything you wrote yourself, and you edit them the same way. An imported rule arrives advisory: it rides along as context and does not block an edit unless a person approves an executable constraint for it (see Rules as guardrails).

Import writes as you. Each piece goes through the same access check as any other write, so on a team you need write access to the target workspace: a Viewer cannot import. See Roles and permissions.

Importing by manual copy

You do not need the token to use a pattern. Each catalog page has a "Manual copy (full bundle)" action that copies the full bundle as plain markdown, with every piece labelled by kind and target path, and every rule labelled with its scope and priority. Paste that into your assistant, or into your own notes, and recreate the pieces wherever you want. This works with no setup and no account.

Every pattern is also available as raw markdown at /patterns/<slug>/raw, which is convenient when you want an assistant to read the whole bundle from a link.

Seed, not subscribe

Importing a pattern is a one-time seed. The copy in your workspace is yours from that moment on; it does not stay linked to the catalog and it will not change underneath you. Pathrule does not record which version you imported and does not notify you when a newer version is published, so nothing ever syncs over content you have already adapted.

To see whether a pattern moved since you imported it, compare the version and updated date on its catalog page, and read its changelog in the open package. Re-importing does not bring changes in, because every piece whose title is already present is skipped. To take a newer version, remove the bundle and import it again, knowing that this replaces your edits to the imported pieces. If you only want one improved piece, copy it from the catalog page by hand.

Re-importing and removing

• Re-import never duplicates. Running the same import again skips every piece whose title is already present and reports what was added and what was already there. A memory counts as present when a memory with the same title exists at its path; a rule or a skill counts as present when one with the same name exists anywhere in the workspace. Skipped pieces are left exactly as they are, edits included. A piece you renamed after import is no longer recognised, so a re-import adds it again.
• Removal is one step. A pattern's definition is its own manifest of titles and paths, so you can ask your assistant to remove the pattern and a single call undoes the whole bundle. If you imported under a base path, give the same base when you remove; pieces that cannot be found there are reported as not found rather than treated as errors.

What removal touches

Removal finds each piece by its title at its path, not by remembering what the import created. That has three consequences worth knowing before you run it:

• Edited pieces are removed too. An imported memory, rule or skill that you have since edited is removed along with your edits, as long as its title and path are unchanged.
• Your own item with the same title is removed. If you wrote a memory, rule or skill yourself with the same title as one of the pattern's pieces, at the same path, removal deletes it as well. Titles are compared without regard to letter case.
• Renamed or moved pieces stay. Renaming a piece or moving it to another path takes it out of removal's reach, which is the way to keep one piece while removing the rest.

Removed items are archived rather than erased. On a Cloud workspace they stay in the workspace archive until permanently deleted, where an owner or admin can restore them from the web console settings under Workspace, Archive.

Where it works

Token import and removal use the local stdio MCP tools, including when that runtime is attached to a Cloud workspace. Remote MCP does not expose these helpers. A remote client can read the raw bundle and author selected entries with its available knowledge tools.

Import behaves the same in Claude Code, Codex, Cursor, Windsurf and GitHub Copilot connected through Pathrule CLI or the VS Code extension. Import and removal work the same on a local workspace and on a Pathrule Cloud workspace. In Claude Code and Codex the prompt hook spots the token before the agent acts. Cursor, GitHub Copilot and Windsurf have no Pathrule hook, so there, the assistant learns the same import and remove workflow when it requests context through MCP.

What to read next

• Patterns overview for the bigger picture.
• Anatomy of a pattern for what is inside a bundle and how versioning works.
• How hooks work for how imported pieces are delivered once they are in your workspace.