Skip to main content

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.

A rule in the Context Base is an always-on constraint that agents follow on every task in your project. Image loading patterns, SEO coverage, i18n for user-facing strings, architectural guardrails, “never do X without asking” policies — anything that should apply uniformly regardless of what the agent is being asked to do. Rules are the boring infrastructure of consistency. They’re not exciting, but they’re the difference between a codebase where the same pattern is used the same way everywhere and one where every developer (human or AI) reinvents it.

​
Project Rules vs. Context Rules

Frontic exposes rules on two surfaces, and most projects use both:
  • Project Rules — a single, monolithic document in Studio Settings → Project Rules. Always applied in full, not modular, not targeted. Good for the short list of constraints that must absolutely hold on every task regardless of what else is going on: “product images always through the CDN”, “no rounded corners on the brand”, “every user-facing string gets a translation key”.
  • Context Rules — individual rule files in the Context Base, each focused on one concern. Modular: review, update, and delete them independently. The rest of this page is about Context Rules — they’re what you edit in Studio → Context → Rules and what grows with your project over time.
Default to Context Rules. Reserve Project Rules for the handful of constraints whose omission would break the first thing an agent does on a fresh session — things you can’t afford to have “not picked up yet” because they didn’t happen to match the current task.

​
How rules fit with the other Context Base types

Quick reminder on how the four types divide the work:
  • Rules apply on every task by default — constraints that hold uniformly, narrowable by path when a rule should only fire in certain parts of the codebase.
  • Skills apply when the task touches the domain (or when you force them by name) — domain experts like seo-optimizer kick in whenever relevant.
  • Commands apply only when you force them by name — task procedures like code-review, same body shape as a skill but the agent never auto-picks one.
  • Guides apply when explicitly referenced — reference documents the agent pulls in on demand.
If you’re about to write a rule that says “when doing X, do it this way”, you’re probably writing a skill. If you’re writing “always do X when doing anything”, that’s a rule. If you’re writing a long document with no specific behavioral trigger, it’s probably a guide.

​
What rules are good for

Performance defaults

“Load product images through the CDN with responsive srcset, not from the source URL.” “Lazy-load below-the-fold blocks.” “Never fetch Frontic data in client components — use the server layer.” Things that must hold on every page or revenue suffers.

SEO coverage

“Every page gets a canonical URL and the built-in SEO composite.” “Withdrawn categories 302-redirect, never 404.” “Locale variants link each other via hreflang.” The SEO basics agents forget to include unless told.

i18n coverage

“Every user-facing string gets a translation key — no hardcoded copy.” “New translatable fields need entries for every active locale before merging.” The rules that keep the multi-market build shippable.

Accessibility baselines

“Every interactive element needs an accessible name.” “Maintain WCAG AA contrast on brand colors.” “Every new form field gets a visible label.” Non-negotiable floors agents can’t be trusted to apply without a rule.

Architectural discipline

“Never drop a field from a storage schema — deprecate it first.” “Never edit a generated client file by hand.” “Always render through a server component, never fetch in the browser.” Boundaries that prevent slow, expensive mistakes.

Architectural guardrails

“All listings go through the generated SDK, never raw fetch.” “Use Frontic UI components before building new ones.” “Block components live under components/blocks/, not mixed into pages.” Patterns you want everywhere without nagging.

​
Writing a rule

Open Studio → Context → Rules in the admin app and click New Rule.
Don’t want to author rules by hand? Ask Buddy in the admin app to draft one. Describe the constraint in your own words (“product images should always go through the CDN with responsive sizing”) and Buddy writes a focused rule in the right shape for you to review and activate. Buddy doesn’t apply Context Rules to its own behavior, but it reads and maintains them as documents you manage together.
Creation asks for two things:
  • Name — short, memorable. product-images-through-cdn is good; miscellaneous-frontend-rules is not.
  • Description — one sentence summarising the constraint, shown in the rules list.
Once the rule is created, you land in the editor where you write the body as Markdown. New rules start as Draft — flip the status to Active when the content is ready to apply. Only Active rules are enforced on agent tasks. Rules can be scoped to this project (the default) or promoted to your organization so they apply across every project on your team — a company-wide accessibility baseline or a shared CDN image rule are classic globals. Keep each rule focused on one concern. product-images-through-cdn should be its own rule, not buried inside a 50-line “general frontend rules” document. Focused rules are easier to review, easier to update, and easier to delete when they become obsolete. Keep the total count small, too. Agents already apply sensible defaults for the obvious things — “make layouts responsive”, “handle errors gracefully”, “write accessible markup”. Rules earn their place by enforcing the specific decisions your project made that the agent wouldn’t guess — a brand constraint like “no rounded corners”, a commerce choice like “product images only through the CDN”, a destructive-action boundary unique to your setup. If a rule restates what a competent engineer would already do, it adds noise on every task without moving the output.

​
Example: Product images through the CDN

# Product images through the CDN

All product and category imagery must be rendered through our
image CDN, not the raw source URL. This is non-negotiable —
non-CDN images bypass compression, responsive sizing, and cache
warming, and they're what regressed our LCP on the category page
last quarter.

## What to do

- Use the `<FronticImage>` component — it handles CDN URL
  rewriting, `srcset`, and `sizes` for you.
- When the component doesn't fit (rare), build the CDN URL via
  `buildImageUrl(record.image, { width, format: 'auto' })`. Never
  inline the raw source URL.
- Always provide `sizes` alongside `srcset` so the browser picks
  the right variant. The component does this automatically; if
  you're rolling your own, don't skip it.

## What to avoid

- Don't use the raw `record.image.url` in `<img src="…">`. That's
  the source URL, not the CDN URL.
- Don't hardcode a single width ("the 800px version will be fine
  everywhere"). Responsive sizing is the whole point.
- Don't disable lazy loading for below-the-fold images. The
  `<FronticImage>` default is correct.

## Why

Source URLs are uncompressed, unresized, and not cached at the
edge. On category pages with 24 product tiles, that's the
difference between a 1.2s LCP and a 4.8s LCP.
Every build-side agent proposal that touches an image now runs through this rule — the <FronticImage> component gets used, CDN URLs get generated, raw source URLs get flagged. If you see a stray <img src="{record.image.url}"> proposed, the rule isn’t being read; check that it’s Active.

​
Example: Use createClient for SDK initialization

# Use createClient for SDK initialization

When adding Frontic Client SDK calls to the frontend, always
initialize via `createClient` with config, not via the default
`import client from './.frontic/generated-client'` path.

Reason: direct imports don't let us configure the proxy URL for
CORS prevention, and we need that for the production build.

Correct:

    import { createClient } from './.frontic/generated-client';
    const client = createClient({ proxyUrl: '/api/frontic' });

Incorrect:

    import client from './.frontic/generated-client';
Rules like this one are how you stop recurring style drift. The first time someone lands a direct import, you add the rule; the rule prevents the next ten.

​
Rules are project-wide

Rules apply on every build-side agent task in the project — whether the agent is running in a Studio workspace or your editor — scoped to whatever paths targeting allows. Rules don’t govern Buddy; Buddy has its own separate context and can read or edit rule documents without applying them to its own behavior. If you have a guideline that only applies in one situation, that’s a sign it should probably be a skill scoped to that situation, not a rule.

​
Targeting a rule by path

By default, every Context Rule applies to every build-side task. When a rule should only fire when the agent is touching certain parts of the codebase, narrow it using the Apply to field on the rule’s metadata. Open a rule in Studio → Context → Rules and find Apply to alongside name and description. Add one or more path patterns — for example src/checkout/** or src/api/payments/**. The rule will apply only when a task touches a matching path; leave Apply to empty and the rule applies everywhere.
Rule metadata editor showing the Apply to field with two path patterns entered
Path targeting works in Studio, Claude Code, and Cursor — Frontic maps what you enter in Apply to into each environment’s native targeting format, so you don’t maintain separate configs per editor. If a rule keeps showing up on unrelated work, add Apply to entries and narrow where it matters. If a rule genuinely should apply across the whole codebase, leave Apply to off.

​
Reviewing and pruning rules

Rules decay. A rule that was essential six months ago might be obsolete because the codebase moved, the framework changed, or the convention it enforced is now the default. When something feels off — a rule that keeps getting violated, a new pattern that supersedes an old one, a teammate flagging friction — walk through the list and ask:
  • Is this still true? If the codebase no longer follows it, decide: update the rule, or delete it.
  • Does this still matter? A rule that’s technically correct but irrelevant to the work people are actively doing is noise.
  • Is this still the right granularity? Rules that accumulated into multi-concern walls of text should be split.
Aim to have 10–20 active rules for most projects. More than that and you’re drowning the agent in constraints; fewer than that and you probably have gaps where consistency would help.

​
Rules agents can’t follow perfectly

Rules aren’t executable code — the agent reads them and tries. That means some rules are imperfectly enforced:
  • Vague rules get vague compliance. A rule that says “write clean code” is meaningless. A rule that says “prefer early returns over nested conditionals” is actionable.
  • Contradictory rules produce arbitrary behavior. If Rule A says “always use arrow functions” and Rule B says “always export named functions”, the agent picks one. Review your rules for contradictions when you add new ones.
  • Rules that require information the agent doesn’t have get skipped. If a rule says “always tag blocks with the owner team”, the agent needs to know what the owner team is. Put the information in the rule or the agent can’t apply it.
For anything that must be enforced — not only preferred — back the rule with CI or linting. Rules are the first line of defense, not the last.

Context Base

The mental model for the whole Context Base.

Skills

Task-specific reusable know-how.

Commands

Named shortcuts for recurring operations.

Guides

Reference documents the agent reads on demand.