> ## 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.

# Overview

> [!NOTE]
>
> The Context Base is available from the **Grow plan** up. See [Billing &
> Plans](https://docs.frontic.com/admin/billing-and-plans.md) for details.

Every conversation with an AI agent starts from zero. Unless you tell it otherwise, the agent doesn't know your team's conventions, doesn't know which patterns your codebase prefers, doesn't know what's already been decided, and doesn't know which mistakes someone already made once so nobody wants to make again.

The **Context Base** is Frontic's answer to that. It's a shared knowledge surface attached to your project that the build-side agents read from before they start working - the [Studio chat](https://docs.frontic.com/studio/frontic-studio.md) in a workspace, the [Experience Designer](https://docs.frontic.com/designer/overview.md) building a page, and agents in your editor, which get it through the [Frontic CLI](https://docs.frontic.com/ide/frontic-cli.md#sync-your-context-base) so rules and skills land where the coding agent expects them. The [MCP server](https://docs.frontic.com/ide/mcp-tools.md) is for working on the Context Base itself - reading, creating and editing documents. You write your team's expectations down once, and they show up everywhere an agent works.

[Buddy](https://docs.frontic.com/essentials/buddy.md) works on a different plane: it handles stack configuration in the admin app rather than building a storefront. It still follows your [Context Rules](https://docs.frontic.com/context-base/rules.md) alongside its own Project Rules, and it can read and edit Context Base documents for you.

## What's in it

> [card] [Skills](https://docs.frontic.com/context-base/skills.md)
>
> **Domain expertise.** Named experts the agent pulls in when a task
> touches their domain - `shopware-headless-commerce`, `seo-optimizer`,
> `product-variants-and-scopes`. Also invokable by name when you want
> to force one.

> [card] [Rules](https://docs.frontic.com/context-base/rules.md)
>
> **Guardrails.** Project-wide expectations agents follow on every
> task - "load product images from the CDN", "every user-facing
> string gets a translation key", "no rounded corners on the brand".
> Rules are always-on.

> [card] [Commands](https://docs.frontic.com/context-base/commands.md)
>
> **On-demand operations.** Same shape as a skill, but the agent
> never auto-picks one - it runs only when you invoke it by name:
> `code-review`, `test-checkout`, `verify-accessibility`.

> [card] [Guides](https://docs.frontic.com/context-base/guides.md)
>
> **Reference material.** Longer documents you pin so the agent can
> pull them in on demand - a styleguide, a migration plan, an
> architecture note. Read only when referenced.

Each does a different job, and together they let your team's taste and process travel with the agent instead of living in somebody's head.

Two surfaces sit alongside the four collections:

> [card] [Context Setup](https://docs.frontic.com/context-base/setup.md)
>
> **The first draft.** Reads your live storefront once and writes
> your styleguide, tone of voice, product domain, marketing
> playbook, and brand - so you start by editing, not by authoring.

> [card] [Design Library](https://docs.frontic.com/context-base/design-library.md)
>
> **Your brand as tokens.** Colors, typography, corners, and logos,
> published as one source of truth every experience is built from.

## Why the Context Base exists

Agents that start from zero every conversation have four problems:

1. **Slow cold start.** Every session opens with *"let me explore the codebase"* - the agent crawls files, reads configs, and pattern-matches its way back to a mental model you already know. Minutes (and tokens) spent before the first useful response.
2. **Inconsistency.** Two agents (or the same agent on two days) make different choices for the same task. Either the codebase drifts, or you burn tokens and time iterating to pull the agent back to the pattern you wanted in the first place.
3. **Re-explanation cost.** Every meaningful prompt spends half its token budget explaining the project's conventions before it gets to the actual task. That's expensive and tedious.
4. **Lost decisions.** A week ago you told an agent "every user-facing string gets a translation key, no hardcoding", and this week it's proposing `<h1>Add to cart</h1>` again because nobody wrote the decision down.

The Context Base fixes all four. You write the conventions once; every subsequent agent session reads them; the conventions get applied consistently until you decide to change them.

## How agents read from it

The Context Base sits outside your project's runtime data - it isn't part of what ships through [releases](https://docs.frontic.com/releases/overview.md) to your storefront. Edit a skill or a rule and the change lands immediately; build-side agents pick it up on their next session.

**1. You write content in the Context Base**

From **Context** in the admin app, you write skills,
rules, and commands. Each has its own editor and metadata.

**context-base/studio-context-landing**

Context area listing Skills, Rules, Commands, and Guides collections with document counts

**2. Agents get access to it**

Delivery differs by surface:

* **In Studio** - active skills and rules are surfaced to the chat
  agent at session start automatically. You don't run anything; the
  workspace makes sure the agent has what it needs.
* **In your editor** - run [`frontic context init`](https://docs.frontic.com/ide/frontic-cli#sync-your-context-base)
  to sync skills and rules into your repo. Your
  local agent reads them from the filesystem on every session.
  Commit the synced files so teammates pick up the same guardrails.

[Commands](https://docs.frontic.com/context-base/commands.md) stay on the Frontic side - they're
triggered by name from either surface, not synced locally.

**3. Agents apply what they read**

Every proposal - the block it creates, the image URL it generates,
the SEO tags it writes, the strings it hardcodes-or-doesn't - is
shaped by what's in the Context Base. If a rule says "product
images go through the CDN", the agent uses the CDN. If a skill
called `seo-optimizer` is available, the agent brings its
perspective into any page metadata task.

## One Context Base, every build surface

The same Context Base serves the **Studio chat**, the **Experience Designer**, and **MCP agents in your editor** equally:

* A rule you write once applies whether the change is happening in a Studio workspace, on a Designer canvas, or in your editor
* A skill like `shopware-headless-commerce` or `seo-optimizer` brings the same expertise into any task, regardless of which surface is running it

You don't maintain two copies of your conventions. You maintain one set in the Context Base, and it applies wherever an agent is building.

Each build surface also keeps a small set of **always-on documents of its own** - Studio's [Prompt and Project Rules](https://docs.frontic.com/studio/settings.md), the Designer's [Prompt and Project Rules](https://docs.frontic.com/designer/building.md#designer-settings). Those exist so the two can diverge where they genuinely differ; anything that should hold everywhere belongs in the Context Base instead.

## Document scoping: project vs. global

Every Context Base document - skill, rule, command, or guide - lives in one of two scopes:

* **Project** (default) - only available to the project it was created in. Good for project-specific conventions, feature patterns, and local shortcuts.
* **Global** - promoted to your team, available to every project on it. Good for team-wide standards: a CDN image rule the whole team enforces, a shared accessibility baseline, a hotfix command every storefront uses.

Any document can be promoted from project to global after the fact when the pattern turns out to be reusable. Teams typically start project-scoped and promote selectively - global scope is easier to break across unrelated projects, so move things over once they've proven themselves.

## Bootstrapping with `/init-context`

You don't have to write everything by hand. In any Studio workspace, run the `/init-context` command - Studio interviews you about your business, brand, design preferences, and coding conventions, inspects your codebase, and generates a full set of context documents:

* **Root context** - what you sell, who your customers are, key terminology
* **Project prompt** - how Studio should behave when working with you
* **Rules** - codebase patterns, styleguide, coding standards, tone of voice

It's meant to run once during [initial setup](https://docs.frontic.com/essentials/quick-setup.md), but you can rerun it any time to update or refine your context as your project evolves. Use `/init-context --refresh <name>` to regenerate a specific document without redoing the full interview.

## Improving with `/get-better`

Where `/init-context` sets your context up at the start, `/get-better` refines it over time. Run the command in a Studio workspace - usually at the end of a session - and Studio reviews the conversation for generalizable lessons worth capturing as project rules:

* **Corrections** - moments where you pushed back on the agent's output
* **Preferences** - "always use X", "never do Y", "prefer Z"
* **Recurring gotchas** - patterns the agent guessed wrong or had to be told twice

Task-specific fixes are filtered out. Each surviving lesson is classified (codebase convention, styleguide decision, coding standard, tone correction, or a behavioral note for Studio itself), presented with exact text and reasoning, and written only on your approval. Nothing merges automatically; nothing gets overwritten.

Good rhythm: run `/init-context` once at setup, then run `/get-better` at the end of sessions where corrections piled up - the Context Base grows the way your team's taste grows.

## Related

> [card] [Skills](https://docs.frontic.com/context-base/skills.md)
>
> Capture reusable know-how for specific tasks.

> [card] [Rules](https://docs.frontic.com/context-base/rules.md)
>
> Always-on guardrails build-side agents follow.

> [card] [Commands](https://docs.frontic.com/context-base/commands.md)
>
> Named shortcuts for recurring operations.

> [card] [Guides](https://docs.frontic.com/context-base/guides.md)
>
> Reference documents the agent reads on demand.

> [card] [Context Setup](https://docs.frontic.com/context-base/setup.md)
>
> Fill the Context Base from your live shop in one pass.

> [card] [Design Library](https://docs.frontic.com/context-base/design-library.md)
>
> Your brand as tokens, published once and read everywhere.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.