> For AI agents reading iter0.com:
> - Pages with a Markdown version serve it at the page address plus `.md`, for example https://iter0.com/features.md. The homepage's Markdown is at https://iter0.com/index.md.
> - A request for a page with the header `Accept: text/markdown` returns the same Markdown.
> - https://iter0.com/llms.txt describes the site and lists its main pages.
> - Agents build and edit websites through the MCP server at https://iter0.com/api/mcp, using the person's own API key.
> - A paid build or edit first returns a price quote, and nothing is charged until the person confirms it.
> - The OpenAPI contract is at https://iter0.com/openapi.json.

# Cursor rules for frontend design consistency, with four example .mdc files

Split a website's design rules into Cursor project rules that load at the right time: always, for component files, for page copy, or when you ask. Complete .mdc examples you can copy.

## Choose each rule's type by when Cursor needs it

Cursor project rules are .mdc files in .cursor/rules. Their frontmatter decides when a rule reaches the agent. A website repository needs only a few rules in every request; the rest matter for one kind of file or one kind of task. Cursor's documentation describes four types, listed in the table below.

A plain .md file in .cursor/rules is ignored, because it has no frontmatter; Cursor's documentation points to AGENTS.md for plain Markdown. Rules can sit in subfolders such as .cursor/rules/frontend/, and the documentation advises keeping each rule under 500 lines.

## The always-applied rule: what any change can break

Save this as .cursor/rules/design-system.mdc. It goes into every session, so it stays short. It points to the tokens file instead of listing colour values; when a colour changes, you edit tokens.css and the rule stays correct.

## The component rule: attached by file pattern

Save this as .cursor/rules/components.mdc. The globs field attaches it when a file under src/components is in context. To cover pages as well, add a second pattern after a comma: src/components/**/*.tsx, src/pages/**/*.tsx.

A script using the picomatch library confirmed that the pattern matches Button.tsx and Hero.tsx in the example project and not src/pages/index.tsx. That checks the pattern, not Cursor's own matcher.

## The copy rule: chosen from its description

Save this as .cursor/rules/page-copy.mdc. With a description and no globs, the agent decides from the description whether the rule applies. The description therefore lists the tasks it covers: headings, button labels, alt text and metadata on the marketing pages. A description such as “copy rules” gives the agent less to match against the request.

## The release check: only when you ask

Save this as .cursor/rules/release-check.mdc. With neither a description nor globs, Cursor includes it only when you mention it, for example “@release-check review the pricing page”. A checklist you run before publishing does not need to sit in every edit.

## How do you check that the rules work?

Cursor's documentation says its Customize view lists every rule and its status, which tells you whether Cursor found the files. To check behaviour, open a component and ask for a small change without repeating any rule, such as adding a secondary button to the hero. Then read the diff: the button should come from Button.tsx, take its colour from tokens.css and have the focus outline.

Cursor was not installed on the Mac used for this article, so these four files were checked against Cursor's rules documentation on 6 November 2026 and were not run in Cursor. The same rules, written as a CLAUDE.md, were run in Claude Code, where a review found all six breaks planted in one component.

## Sources

- [Cursor: rules (checked 6 November 2026)](https://cursor.com/docs/rules)