> ## Documentation Index > Fetch the complete documentation index at: https://docs.frontic.com/llms.txt > Use this file to discover all available pages before exploring further. # Guides A **guide** in the [Context Base](/context-base/overview) is a longer document you pin to your project so an agent can pull it into a conversation on demand. Unlike [rules](/context-base/rules) (always-on), [skills](/context-base/skills) (matched to a task), or [commands](/context-base/commands) (triggered by name), guides have **no automatic behavior** — they sit in the Context Base as reference material, and the agent reads one when you point it at one. Think of guides as the shelf of reference documents your team keeps next to the codebase: the authentication flow write-up, the migration plan nobody wants to re-derive, the brand styleguide you haven't translated into rules yet. Available when needed, not injected on every task. ## What guides are good for Architecture notes, data flow explanations, historical decisions, onboarding reading. Things you want an agent to read *when the topic comes up*, not on every unrelated task. An existing styleguide, a long design doc, an email thread with a decision buried in it. Drop it in as a guide; extract rules or skills from it over time as patterns become clear. A migration plan ("move from v1 blocks to v2"), a refactor runbook, a one-off procedure that isn't recurring enough for a command but is long enough that re-explaining it in chat is painful. "Why we chose Pinia Colada for data fetching", "How we handle preview context in server components". The *why* behind choices the agent will otherwise second-guess. ## How guides fit with the other Context Base types The four Context Base types compared: | | Triggered by | Shape | Example | | ------------ | ------------------------------------- | -------------------- | ---------------------------- | | **Guides** | Explicitly referenced | Reference document | `authentication-flow` | | **Skills** | A matching domain (or forced by name) | Domain expertise | `seo-optimizer` | | **Rules** | Always active | Always-on constraint | `product-images-through-cdn` | | **Commands** | Forced by name only | Task procedure | `code-review` | A rule says "do it this way on every task." A skill says "when doing *this kind* of task, here's the approach." A command says "when I say *this*, run this flow." A guide says "here's something you can read when you need it." If in doubt: if you want the agent to act on something automatically, it's not a guide. Guides are material, not behavior. ## Writing a guide Open **Studio → Context → Guides** in the admin app and click **New Guide**. You don't have to author guides by hand. Ask [Buddy](/essentials/buddy) in the admin app, or the chat in a [Studio workspace](/studio/frontic-studio), to draft or populate a guide for you. Studio's strength here is context capture: it can turn the artefacts of a job into a guide. "Save the testcase I wrote this morning as a guide" or "run an SEO audit on the homepage and store the results as a guide", and you end up with a reference document alongside the work that produced it. Anything a session produces — findings, walkthroughs, audits — can land in the guide collection instead of scrolling away with the chat. Creation asks for two things: * **Name** — short, descriptive. `authentication-flow` is good; `notes-dump` is not. * **Description** — one sentence about what the guide covers. Agents use this to decide whether to pull the guide into a conversation when you reference the collection. Once the guide is created, you land in the editor where you write the document body in Markdown — guides are where length is allowed, so as long or short as the material needs. New guides start as **Draft** — flip the status to **Active** when the content is ready. Only Active guides are available to agents. Guides can be **scoped to this project** (the default) or **promoted to your organization** so they're available across every project on your team. Promote the ones that apply broadly — a company-wide styleguide, a shared glossary. Leave project-specific architecture notes at the project level. ## Referencing a guide in chat A few ways guides end up in an agent's context: * **Pick from the command menu** — in a Studio workspace, open the command menu and select the guide from the list. The reliable path: you know the guide lands in context. * **Prompt and trust the agent** — say *"Read the Authentication flow guide before touching the login page"* and the agent matches by name/description and pulls the guide in. Works in any MCP-capable editor, but it depends on the agent's discovery — not as sure-fire as the command menu. * **Linked from another document** — a skill or rule can reference a guide using Studio's cross-reference syntax, and the agent pulls the linked guide in when the parent document applies. Because guides are often long, the system loads them **on demand** rather than injecting every guide into every session. That's what lets you keep a library of 30 guides around without burning context on irrelevant ones. **Heads-up on syncing.** Guides don't currently export through `frontic context init` — only [skills](/context-base/skills) and [rules](/context-base/rules) sync to `.claude/` and `.cursor/` today. Outside Studio, the way an agent reads a guide is by calling the Frontic [MCP](/ide/mcp-tools) to fetch the document directly. Coming soon: a CLI option to pull guides into a target destination in your project (default `/guides`) so they live on disk alongside the rest of your Context Base. ## Related The mental model for the whole Context Base. Task-specific reusable know-how. Always-on constraints on agent behavior. Named shortcuts for recurring operations.