Context Priming
Your AI already knows your codebase when the session starts. Context priming maintains a set of reference files about your project and loads exactly the right ones into every session: no wasted tokens, no re-explaining your architecture, no starting from scratch.
The problem it solves
Every fresh AI session starts from zero. It does not know how your project is laid out, which conventions matter, or where the sharp edges are. So either you explain it again, or the agent burns time and tokens rediscovering it by reading files, and it rediscovers it slightly differently each time.
Context priming replaces that ritual with maintained knowledge. The project carries a written description of itself, split into areas, and sessions load the parts that are relevant to the task at hand. The explanation happens once, in a file, instead of once per session.
The model: an index plus areas
Priming has two layers, and the shape is simple: an area-index.md file plus a set of areas/*.md reference files.
- The area index is a short map of the project: what areas exist and what each one covers. It is cheap to load, so the AI reads it first in every session.
- Area reference files hold the actual knowledge: how that part of the codebase is structured, the key files and patterns, and the operational notes that only come from working in it.
The AI loads the index, then pulls in only the areas relevant to the current task. A styling tweak loads the frontend reference and nothing else. Knowledge about your deployment pipeline costs zero tokens until a task actually touches deployment.
How areas map to your codebase
Areas are yours to define, and they should follow the natural seams of the project: frontend, api, messaging, deployment, whatever divisions you already think in. A small project might have three areas; a larger one might have seven or eight.
Areas also connect to the kanban board. Cards carry area tags drawn from the same list, and those tags flow into the session when a card's terminal opens. A card tagged api tells the session which references to load before any work starts, so the agent begins the task already oriented.
Self-maintenance
Reference docs usually rot because updating them is a separate chore nobody does. Here the skill maintains its own references: while working, the AI compares what the references say against what the code actually does, and responds to drift proportionally.
| What it notices | What it does |
|---|---|
| Minor drift | Skips it. Small wording gaps are not worth churn. |
| A reference contradicts the code | Fixes the reference in stride, as part of the session. |
| Larger restructuring, or adding, removing, or splitting areas | Checks with you before changing the shape of the map. |
Areas also accumulate short operational notes over time, in a "when X, do Y" format: the kind of hard-won detail that normally lives only in your head. Notes are capped per area so the references stay lean instead of growing without bound.
Works across providers
Priming is not tied to one AI. The skill deploys to Claude, Codex, and Gemini sessions alike, and they all read the same reference files. Explain something once and every provider knows it; a correction made in one session benefits the next session regardless of which agent runs it.
Getting started
There is nothing to install. Context priming is one of the skills that ship with SlyCode, and it is scaffolded into every project you add. The AI builds the references as it works in the project, and they improve from there.
To refresh the references deliberately, run the update-priming action from a project terminal. It walks the areas, compares them against the current code, and brings them up to date. And because it is an action, you can schedule it: automations can refresh priming nightly, so the references track the codebase without you thinking about it.
Next steps
- Skills: what a skill is, the format, and the rest of the built-in set.
- Kanban workflow: cards, stages, and how area tags feed sessions.