Skip to main content
A command in the Context Base is a named operation the agent runs when you invoke it by name. Commands share the same shape as skills — the content body is the same kind of instruction — but there’s one crucial difference: the agent never auto-picks a command. It runs only when you ask for it. Use commands for work that’s too narrow or too invasive to auto-apply: a code-review, a test-checkout, a verify-accessibility — things you sometimes want to run and don’t want the agent starting on its own.
Commands currently don’t sync to your local repo via frontic context init. Only skills and rules are exported to .claude/ and .cursor/ today. You invoke commands from the Frontic surfaces (Studio chat, MCP in your editor) where the agent can read them directly from the project’s Context Base.

​
How commands fit with the other Context Base types

The four Context Base types compared: A skill is knowledge, a rule is a constraint, a guide is reference material — all three are things the agent reads. A command is the only one that’s an action. You ask for a skill implicitly (by describing the task) or explicitly (by naming it); you invoke a command by name to have the agent run its defined flow.

​
What commands are good for

Reviews & checks

code-review, verify-accessibility, check-performance — things you run when you want them, not every time the agent touches the codebase. Invoking them explicitly keeps the agent from second-guessing.

Build recipes

build-landing-page, scaffold-product-detail-page, add-block-component — the team’s way of creating something you put together often enough that “build me one of those” should always land the same shape.
The common pattern: work you want done a specific way when you ask for it, not every time the agent looks at a task.

​
Writing a command

Open Studio → Context → Commands in the admin app and click New Command. Creation asks for two things:
  • Name — short, memorable, triggerable. code-review and build-landing-page are good.
  • Description — one sentence for the commands list.
Once the command is created, you land in the editor where you write the operation itself in Markdown — the steps in order, with enough detail that the agent doesn’t have to guess. New commands start as Draft — flip the status to Active when the content is ready to run. Commands can be scoped to this project (the default) or promoted to your organization so they apply across every project on your team. The command body is the operation itself. Unlike skills (domain expertise) and rules (constraints), the command body is an actionable procedure the agent is expected to execute when triggered.

​
Example: build-landing-page

A creation recipe — a repeatable “build me one of these” pattern that bakes in the team’s choices so every landing page lands in the same shape.
Now when anyone types /build-landing-page for the spring sale campaign, the agent follows the same flow. Every landing page matches the rest of the site.

​
Example: verify-accessibility

An audit command — a different shape from a build recipe. The agent reviews something that already exists and reports back.
Typing /verify-accessibility gets you a consistent report every time — the same baselines, the same gotchas, the same severity language. No restating “check this, check that” in the prompt.

​
Triggering a command

Commands are invoked as slash commands from the agent chat — the same mechanism in Studio, Claude Code, Cursor, and any other MCP-capable editor:
/build-landing-page — brief for the spring sale campaign attached.
/verify-accessibility on the checkout confirmation page.
In Studio, there’s a second path: the command menu lets you pick a command from a list and run it without typing the slash — handy when you don’t remember the exact name. The agent loads the command’s content, confirms the parameters, and starts executing. You stay in control: destructive steps still go through normal approval, and the agent will pause for confirmation at any step that needs it.

​
Command or skill — how to choose

Commands and skills share the same content shape, so the decision is about what the content describes and when you want it to fire:
  • Is it a domain the agent should carry into every relevant task → skill. shopware-headless-commerce, seo-optimizer, product-variants-and-scopes — expertise that applies across many tasks. Let the agent discover and apply it on its own.
  • Is it a specific procedure you only want run when you ask → command. code-review, verify-accessibility, build-landing-page — narrow actions with a beginning, middle, and end. Stay out of every task until invoked.
Tiebreaker: “would I be annoyed if the agent picked this up on its own without me asking?” If yes, it’s a command.

Context Base

The mental model for the whole Context Base.

Skills

Task-specific reusable know-how.

Rules

Always-on guardrails build-side agents follow.

Guides

Reference documents the agent reads on demand.