Memory, Rules, and Skills: Three Kinds of Team Knowledge
Not all context should behave the same way.
Some knowledge explains, some constrains, and some teaches a repeatable procedure.
What this covers
- Pathrule organizes team knowledge into memories, rules, and skills.
- Memories capture facts and decisions, rules enforce constraints, and skills encode repeatable procedures.
- Different knowledge types help teams avoid dumping every instruction into one global prompt.
- The article explains Pathrule primitives in public-safe terms for teams evaluating AI coding workflows.
Comparison
| Primitive | Use it for | Good example |
|---|---|---|
| Memory | A fact, decision, gotcha, or project note | This path still uses the older response contract |
| Rule | A constraint the assistant should obey | Do not publish private implementation details in public copy |
| Skill | A repeatable procedure or checklist | Prepare a release note from shipped changes |
Choose the right primitive
- If it explains context, make it a memory.
- If it forbids or requires behavior, make it a rule.
- If it describes a repeatable workflow, make it a skill.
- If it applies only to one area, scope it to that path.
- If it applies everywhere, keep it small and project-level.
A pile of instructions is not a knowledge system
Teams often start by writing everything in one place. Run tests this way. Avoid that folder. Remember this incident. Follow this release procedure. Do not expose private details.
Each item may be useful on its own. Together, they become hard to maintain because they are different kinds of knowledge pretending to be one kind of instruction.
Pathrule separates those shapes into memories, rules, and skills.
Memories explain
A memory captures something the team knows and wants the assistant to know when the relevant path is in scope.
It can be a decision, a gotcha, a past lesson, a local convention, or a note about why a piece of work behaves the way it does.
Good memories are short and specific. They do not need to contain source code. They should give the assistant enough context to avoid a repeated wrong turn.
Rules constrain
A rule tells the assistant what must or must not happen. Rules should be written with more force than memories because they guard behavior.
This is especially useful for security, public copy, sensitive workflows, and code paths where a local invariant matters.
Scoped rules are easier to trust because the team can see where they apply and why they were loaded.
Skills encode procedures
Some knowledge is not a fact or a constraint. It is a process.
A skill can describe a repeatable checklist, investigation pattern, writing template, or release workflow. It gives the assistant a method instead of another paragraph of background.
That matters when teams want consistent AI behavior across tools and sessions.
The split helps teams adopt gradually
You do not need to model the whole company on day one. Start with one memory, one rule, and one skill in a path where AI assistants already need help.
Start small, observe real work, and expand where the value is obvious.
If you want help choosing those first primitives, write to [email protected].