A pattern is a ready-to-use package of team knowledge for a specific stack or job. Instead of starting a workspace empty and writing every memory, rule and skill by hand, you add a pattern and your AI assistant starts the project already knowing the conventions that stack tends to need.

Each pattern is a bundle of the same three content types Pathrule already uses, and every piece arrives pre-scoped to the path it belongs to. A rule about server components lands on `/app`, a billing memory lands on the billing service, a review skill lands at the root. Nothing is dumped into one global file.

## Why patterns exist

Most repositories share the same early questions. How should a Next.js App Router project split server and client components? Where do you keep Supabase row-level security rules? What is the safe way to handle a Stripe webhook? The answers are well understood, but every team rediscovers and re-types them.

Patterns capture those answers once, as path-scoped Pathrule content, so a new workspace can adopt them in seconds:

- **Pre-scoped, not pasted.** A pattern is not a prompt blob. Each piece declares the path it lives at, so your assistant only sees it where it is relevant. A UI tweak never has to read a database rule.
- **Typed, not freeform.** A pattern is made of memories, rules and skills, the same types you write yourself. An imported rule keeps its scope, priority and enforcement mode; an imported skill is invocable by name.
- **Yours after import.** Importing a pattern is a one-time seed, not a live subscription. The pieces become ordinary content in your workspace and you edit them like anything else.

## The catalog

The public catalog lives at [pathrule.io/patterns](/patterns). Every package there is first-party and published under Apache-2.0, organised into categories:

- **Framework** for app frameworks like Next.js App Router, Nuxt, SvelteKit, Astro and React Router.
- **Frontend** for component, forms and styling conventions.
- **Backend** for data access, APIs and server patterns.
- **Billing** for payment and subscription flows.
- **Infra** for build, deploy and platform concerns.
- **Workflow** for review checklists and team process.

Each catalog entry has its own page showing the full bundle grouped by path, a derived contents summary (how many rules, memories and skills it carries and how many paths it touches), the reference token used to import it, and a manual copy that works today. Every pattern is also served as plain markdown at `/patterns/<slug>/raw`, so an AI assistant can read the whole bundle directly from a shared link.

## How a pattern fits the rest of Pathrule

A pattern does not introduce a new runtime concept. It is a packaging format over the model you already know:

- The pieces are [memories, rules and skills](/docs/start/core-concepts).
- Each piece's path uses the same [path scope](/docs/start/core-concepts#path-scope) rule as content you write yourself.
- Once imported, the pieces surface through the same [hooks](/docs/hooks/how-hooks-work) and the same just-in-time retrieval as the rest of your workspace.

That is the whole idea: a pattern is a curated head start, expressed in the exact shape your assistant already reads.

## What to read next

- [Anatomy of a pattern](/docs/patterns/anatomy) breaks down the content model: pieces, paths, versioning and the open package behind the catalog.
- [Importing a pattern](/docs/patterns/importing) covers the one-token import, the path preview, and removing a bundle later.
- [Core concepts](/docs/start/core-concepts) explains memories, rules and skills if you are new to the model.