# Design rules

Teach your AI how your brand looks, behaves and speaks.

Design rules capture the decisions behind your interface. Tokens define a color, a type scale or a shape. A rule explains when to use it, where it applies and why it matters. Frontfriend connects this guidance to the actual components your team and agents build with.

## Start with a decision

Write a rule that someone can act on. Add a reason so an agent can understand the intention when a new situation comes up.

| Area       | Rule                                                                                               | Why                                                 |
| ---------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| Color      | Reserve the brand accent for one primary action per view.                                          | A clear hierarchy makes the next step easy to find. |
| Components | Use the main Button for the primary action and secondary or ghost variants for supporting actions. | Emphasis should match importance.                   |
| Feedback   | Explain errors in words and offer a useful next step.                                              | Color alone cannot explain what happened.           |
| Voice      | Name the action: “Create workspace” instead of “Proceed.”                                          | Specific language helps people act with confidence. |

These are examples to adapt to your product. Each Design System owns its decisions; a warm editorial brand and a dense technical product can use the same component library with different tokens, styles and rules.

## Organize and scope your rules

Group related decisions in chapters such as Color, Typography, Feedback, Accessibility, or Language & voice. Give rules the scope they need: an area, a component, or a pattern.

For example, `component:button` connects a rule to Button usage, while `area:COL` describes a color-area rule. Application rules add product-specific context to the shared Design System. Agents should read relevant system-wide rules as well as the component guidance for the task.

A rule can carry its text, rationale, scope, nature, maturity, references and check coverage. Keep inferred guidance traceable to its evidence and review it before accepting it as a shared decision.

## Requirements and guidance

A rule is **in force** when it is enabled, applicable, decided and required. Other active rules can still be delivered to the agent as guidance. A recommendation is useful context; it is not the same as an accepted requirement.

Changes that touch a decided rule or chapter can require review. If an agent receives `PENDING-REVIEW`, the change has not been published. Review the proposal in Frontfriend before treating it as part of the system.

Starter packs provide versioned rules that a Design System can enable. They remain linked to their pack and version, so their origin stays visible instead of becoming an untracked copy.

## Give the agent the right context

Connect [MCP](/docs/mcp/) and use the rules tools with the intended Design System and Application:

1. **`get_rules_index`** maps the available areas and counts. It does not return the rule text.
2. **`get_rules`** reads effective rules from shared chapters, application rules and enabled starter packs. Filter by area or scope when appropriate. Applicable rules in force are returned in full; other guidance is paginated.
3. **`search_rules`** finds candidates. Read the relevant area with `get_rules` before building: a search result is not the complete context.

Keep the selected working view, release or design snapshot consistent across the task. Pair rule context with target-specific component APIs and the page’s [design contract](/docs/design-contracts/).

For example, ask your agent:

> Build our billing page using this application’s design system. Read the color, feedback and Button rules first. Use the installed components, explain your design decisions, and check the result against the applicable rules.

## Rules, skills and contracts

**Rules** describe shared design decisions. **[Design Skills](/docs/design-skills/)** guide the work: setting up context, designing a screen or auditing an interface. **Contracts** describe product intent and page-specific decisions. Together they give an agent both the foundations and the reason behind the interface it is building.

Rules provide explicit context to the agent; they do not retrain the underlying model. Read the relevant context again as the system changes.

## Review the result

Use the rules as a basis for reviewing a real interface. Check coverage describes what can be checked; it does not mean an interface has passed an audit. Look at findings and evidence, and review behavior, accessibility and visual quality in the application.

Next, [connect your agent](/docs/mcp/), [import your brand](/docs/brand-import/), or explore the [component catalogue](/components/).