> ## 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. # Commands A **command** in the [Context Base](https://docs.frontic.com/context-base/overview.md) is a named operation the agent runs when you invoke it by name. Commands share the same shape as [skills](https://docs.frontic.com/context-base/skills.md) - 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. ## How commands fit with the other Context Base types The four Context Base types compared: | | Triggered by | Shape | Example | | - | - | - | - | | **Commands** | Forced by name only | Task procedure | `code-review` | | **Skills** | A matching domain (or forced by name) | Domain expertise | `seo-optimizer` | | **Rules** | Always active | Always-on constraint | `product-images-through-cdn` | | **Guides** | Explicitly referenced | Reference document | `authentication-flow` | 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 > [card] 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. > [card] 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 **Context → Commands** in the admin app and click **Add Command**. Creation asks only for a **name**. Write it as a plain title - **Code Review**, **Build Landing Page**. Once you name it, the command is saved and 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 **Active**. Switch one to **Draft** while you're still writing it. Commands can be scoped to this project (the default) or [promoted to your Team](https://docs.frontic.com/context-base/overview.md#document-scoping-project-vs-global) so they apply across every project on it. 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. ```markdown theme={"theme":"css-variables"} # build-landing-page Build a new marketing landing page from a brief. Before starting, I'll give you a short brief - the offer, the primary call-to-action, the audience, and any imagery direction. The flow: 1. **Confirm the brief.** Summarize what you understood back to me. If anything is ambiguous (CTA target, audience, hero copy), ask before scaffolding. Landing pages are cheap to rebuild but annoying to partially redo. 2. **Add a page route** under `pages/marketing/` following the project's slug convention. Wire it into the navigation entry for marketing pages (not the main site nav). 3. **Lay out the page using existing blocks.** Start from `HeroWithCTA`, then one or two supporting blocks from the marketing block library (`FeatureGrid`, `TestimonialStrip`, `SplitImageText`). Don't invent new blocks unless the brief genuinely needs one - if it does, stop and ask. 4. **Wire the SEO composite.** Title, description, canonical URL, OG image. Pull the OG image from the brief's hero imagery. 5. **Translate all user-facing strings** from the start - don't leave them hardcoded "to translate later". Use the existing key prefixes for the marketing namespace. 6. **Verify the page renders in both default and secondary markets.** Request context resolution is where most landing page bugs come from on this project. 7. **Give me a preview URL** and list what's left for me to review (imagery review, copy check, analytics tags). ### Reminders - Landing pages on this project all follow the hero + three-block layout. If the brief asks for more, check in before adding. - Analytics tagging goes through the `useMarketingEvent` composable - don't wire events manually. - Never inline images. Every image goes through the image CDN; `` handles it. ``` Now when anyone asks for 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. ```markdown theme={"theme":"css-variables"} # verify-accessibility Run an accessibility pass on the page, component, or feature I'm pointing you at. Goal: surface issues that would fail our team's a11y baseline, with enough context that I can fix them myself or have you fix them. 1. **Identify the target.** If I gave you a route, audit that route's rendered output. If I gave you a component, audit that component's markup and any direct children it renders. 2. **Check the baselines** in this order (stop and report any failures - don't keep digging if the first few are broken): - Every interactive element has an accessible name - Color contrast meets WCAG AA on brand colors (don't trust the token defaults blindly; check the combinations in use on this view) - Keyboard-only navigation reaches every interactive element in a sensible order, with visible focus indicators - Form fields have visible labels, not only placeholders - Images have alt text (empty `alt=""` for decorative is fine; meaningful images need real text) 3. **Scan for our project-specific gotchas:** - Custom dropdowns built from divs (should use `