What a Pathrule Pattern Is, and Why It Is Not a Skill
Teams reach for one skill or one rule when a real stack is never one habit.
A pattern is the set you actually wanted: the constraints, the conventions, and the checklist, already scoped to where each applies.
What this covers
- A Pathrule pattern is a small bundle of memories, rules, and skills for one topic, not a single file, with each piece pre-scoped to the path it applies to.
- The mix is composed from the subject: security topics are rule-heavy, architecture topics are memory-heavy, review topics are skill-heavy. No two patterns need to look alike.
- On import each piece lands at its target path instead of being dumped into one root file, so an agent working in a folder sees only the pieces for that folder.
- Patterns are content, free and Apache-2.0; Pathrule charges for the hosted team layer and curation, never for the catalog itself.
Comparison
| Question | A single skill or rule | A pattern |
|---|---|---|
| What it is | One file: a checklist, or one constraint | A small bundle of memories, rules, and skills |
| How many pieces | One | A handful, composed for the topic |
| Where it lands | Wherever you put the file | Each piece at the path it belongs to |
| What it covers | A single procedure or constraint | The conventions of a whole stack or concern |
| How it evolves | You edit the one file | Each piece evolves at its path as the project changes |
The unit most teams reach for is too small
When a team wants to teach a coding agent how to work in a stack, the first instinct is to write a skill or a rule. One checklist for code review. One constraint that bans a library. It is a reasonable instinct, and for a single narrow habit it is the right size.
The trouble is that a real stack is never one habit. Next.js App Router is server components by default, route segment config, data fetching conventions, and a handful of mistakes worth warning about. Writing that as one skill flattens it. Writing it as ten loose files scatters it.
What teams actually want is the set: the constraints, the conventions worth remembering, and the review procedure, grouped together because they describe one topic. That set is the missing unit. A single skill is too small to hold it.
A pattern is that set, already scoped
A Pathrule pattern is a small, opinionated bundle of memories, rules, and skills for one topic. Not a single file. A handful of pieces that together describe how to work in a stack or handle a concern, each one carrying the path it belongs to.
The bundle for the Next.js App Router pattern is a concrete example. A rule that server components are the default, scoped to the app folder. A memory describing route segment config, at the same path. A review skill at the root. Add the pattern and each piece lands where it applies, not in one pile.
This is the part that makes a pattern different from a gist or a template. It is not text you read and adapt. It is structured context that knows its own scope, so the agent receives the right piece when it is working in the right place.
The mix is composed, not fixed
A pattern does not follow a template of so many rules and so many memories. The mix is composed from the subject. A security topic is rule-heavy because it is mostly constraints. An architecture topic is memory-heavy because it is mostly conventions. A review topic is skill-heavy because it is mostly procedure.
So the Web Security pattern leans on strict rules, the Drizzle ORM pattern leans on memories about schema and migrations, and the Code Review pattern leans on a checklist skill. No two patterns need to look alike, because no two topics are shaped alike.
This matters more than it sounds. A fixed template would force a memory where a rule belongs, or pad a topic with pieces it does not need. Composing the bundle from the topic keeps each piece earning its place, which is the same discipline that keeps a context window carrying signal.
Scoped on import, not dumped at the root
The most common way to share conventions today is to paste a long file at the repo root. It works for a moment and then becomes the flat-file problem this blog keeps returning to: one file, every scope, loaded everywhere, lower follow-rate as it grows.
A pattern avoids that by carrying scope in its definition. Each piece declares the path it targets. On import, the rule about server components goes to the app folder, the schema memory goes to the database folder, and the review skill goes to the root, because that is where each one genuinely applies.
The result is that adding a pattern does not bloat a single file. It populates the workspace tree at the right places, so an agent working in one folder sees the pieces for that folder and nothing from the unrelated ones.
It is content, free and open
A pattern is content, not a feature of the paid product. The catalog is free and Apache-2.0. Pathrule charges for the hosted team layer, the sync, the activity, and the curation, and never for the patterns themselves.
That line is deliberate. The conventions for a popular stack are not proprietary knowledge, and treating them as a paywalled feature would be dishonest. The value Pathrule sells is the team network and the managed surface, not the public conventions everyone already half-knows.
It also means a pattern is portable. The pieces are memories, rules, and skills in the same format the rest of the system uses, so they work in the open core on a single machine and in the team layer the same way.
Adding your first pattern
The fastest way to feel the difference is to add one to a repo you know. Browse the catalog, find the pattern for a stack you actually use, and import it with its reference token. Each piece lands at its path and the agent starts applying it in the right place.
A good first choice is the stack where the agent most often guesses a convention wrong. Import that pattern, open a session in the relevant folder, and watch the scoped pieces arrive before the first tool call. If the agent stops making the mistake, the bundle is doing its job.
Every signup gets three months of Pathrule PRO on the house. If you want help picking the right patterns for a real repo, or shaping your own, [email protected] is open, and the whole catalog is open too.