Context rules for focused AI sessions
Smaller rooms. Better doors. Written handoffs.
AI agents do better work when they are given a bounded job, a named source of truth, and a clear finish line.
The expensive failure mode is not that the agent lacks context. It is that the agent carries every context at once: product vision, design language, evidence law, dirty git state, unfinished tasks, and an old conversation thread that has already gone stale.
Your goal is to make each session feel like a focused work room. The agent should know which documents matter, which rules are hard, what it is allowed to touch, and when to stop.
Do not feed the whole library when the job needs one shelf. Point the agent at the shelf, name the rule that wins, and ask for a compact handoff when the room closes.
The habits that save the most context first.
Use one task per session.
Define done up front.
Set a token or time budget.
Name the canonical context docs.
Route context by task type.
Ask for a handoff before stopping.
Search before reading.
Keep long instructions modular.
Report conflicts before editing.
Clean the workspace noise.
Avoid side quests.
Use lower effort for rote work.
Reviewing the PRD or design system is useful only when the task calls for it.
Front-loading context is a thing. It is just easy to overdo. The better habit is selective loading: tell the agent which context to use, which context not to load, and what to do if the documents disagree.
Use PRDs for product behavior. Use the design system for UI. Use AGENTS.md for non-negotiable operating rules. Use voice docs for career outputs. Use the long rationale only when the product direction itself is being debated.
Tell the agent which document wins.
Product behavior
Use docs/product/leadjr-prd.md when the task is about page purpose, IA, naming, objects, or feature fit.
North-star strategy
Use docs/product/prd-vision.md when the task is architectural, strategic, or needs the larger promise.
Visual system
Use design.md and web/lib/design-tokens.ts when the task touches UI, layout, components, or page polish.
Design infrastructure
Use docs/decisions/2026-05-design-system-source.md when changing tokens, design-system pages, or component inventory.
Evidence discipline
Use AGENTS.md and the evidence-ledger skill when attribution, sources, claims, registry, or narrative defensibility matters.
Voice and outputs
Use content/voice docs when writing resumes, case studies, interview answers, or public-facing career copy.
Start with the room, the rules, and the exit.
Bounded Implementation
Task: [one concrete outcome] Context: Use [specific doc or skill]. Do not load the full site brain unless blocked. Scope: Only inspect/change [files, routes, tables, feature area]. Definition of done: [tests, browser check, commit, handoff] Budget: Spend up to [X] tokens or [Y] minutes. If not done, stop and write a handoff. Output: Brief final summary: changed files, verification, next step.
Context Routing
Context routing: - For product behavior, use docs/product/leadjr-prd.md. - For north-star or architecture tension, use docs/product/prd-vision.md. - For UI and visual rules, use design.md and web/lib/design-tokens.ts. - For evidence integrity, AGENTS.md wins. - If these conflict, stop and summarize the conflict before editing. - Do not read docs/product/origin-rationale.md unless the task changes product direction.
Long Session Handoff
Before stopping, write a compact handoff: - Goal and current status. - Branch and latest commit. - Files changed and why. - Commands run and results. - Open risks or blockers. - Exact next action. Keep it short enough that the next session can resume from the handoff instead of re-reading the whole thread.
Review Before Build
Review the relevant context first, then act. Use: - AGENTS.md for hard operating rules. - [specific PRD] for product intent. - [specific design doc] for UI rules. - Search before opening corpus files. Return: 1. What matters for this task. 2. Any conflict or ambiguity. 3. The smallest implementation plan. 4. Then make the change unless blocked.
Start the next chat with the map, not the memory.
A new chat should not inherit the whole old chat. It should inherit the current ticket, the current handoff, and the rules that decide what context to load.
For any ticket or feature with server behavior, production data, multiple routes, or Linear context, start by asking Codex to draft the working prompt. That prompt becomes the room the next session works inside.
Use the ticket-start skill when the first question is not "change this file" but "what do we need to know before this is safe to change?"
Start with the ticket-start skill.
For ticket or feature work, ask for a bounded prompt before implementation. The skill finds the relevant docs, files, data paths, routes, risks, and verification commands.
Bring the handoff, not the history.
Paste or point to the latest handoff, branch, commit, ticket, and current blocker. Avoid replaying the full prior conversation.
Name the server/data expectation.
Say whether local-only is enough, or whether the agent must prove Turso, production env vars, deployed routes, and dependent pages.
Make the stop condition explicit.
Give the agent a token or time budget and require a handoff if the ticket is not complete inside that budget.
Start A Ticket Chat
Use $ticket-start-context. Ticket: [ticket key, Linear link, or pasted ticket] Goal: Draft the working prompt before implementation. Required: - Read the ticket first if tools are available. - Search the repo for the ticket key, feature terms, routes, tables, scripts, env vars, and dependent surfaces. - Identify canonical context docs and which source wins if they conflict. - Identify what must not be touched. - Identify server/data expectations, including whether local SQLite is enough or Turso/main-site behavior must be proven. - Identify verification commands and browser checks. - Draft a bounded execution prompt with budget and definition of done. Do not edit code yet. Output: A compact ticket-start packet and a ready-to-run implementation prompt.
The best sessions feel less like chats and more like small engineering tickets.
A strong agent session has an intake, a scope, an operating contract, a verification step, and a handoff. It can still be exploratory. It can still be creative. The structure is not there to make the work rigid. It is there so the agent does not pay the full context cost for every small decision.
“Give the agent a room, not a continent.”