Overview

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.

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 in a workspace, and agents running in your editor via MCP. You write your team’s expectations down once, and they show up everywhere an agent touches your code. Buddy works on a different plane: it handles stack configuration in the admin app, runs on its own context, and doesn’t read Context Base rules or skills to shape what it does. Where Buddy and the Context Base meet is content maintenance — Buddy can read and edit Context Base documents for you, but it doesn’t apply them to itself.

​

What’s in it

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.

​

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 to your storefront. Edit a skill or a rule and the change lands immediately; build-side agents pick it up on their next session.

​

One Context Base, every build surface

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

• A rule you write once applies whether the change is happening in a Studio workspace 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.

​

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 organization, available to every project on your team. Good for organization-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, 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