Design

Design checks that your project's screens follow one standard and work for everyone: on a phone, with a keyboard, with a screen reader, in low light. The yardstick is the project's design.md, the guide with your colors, fonts and components, along with a quality floor that applies to every screen (contrast, touch target size, states, focus and motion).

design.md

design.md is your project's design guide, a text file in the code folder. It says which colors, fonts and components to use and what to avoid. With it, the agent stops inventing a new style for every screen.

To create one, run /faundr:design in a project without a design.md. The agent:

1. collects the colors, fonts and components your code already uses;
2. asks up to 4 questions: which screen is the reference, the colors, the typography and the product's personality, then the scope (mobile, product type, theme, motion);
3. writes design.md only after you approve.

From then on, Faundr tells the agent to follow the guide on every new screen, and the checks compare your screens against it.

How screens are checked

A finding from the automatic check closes on its own once the check stops finding it. Folders listed in .faundrignore (third-party code, generated files) are left out of the check.

Supported languages

The automatic check works without installing anything on screens built with JavaScript and TypeScript (React, Next.js, Vue, Angular, Svelte, Astro and React Native), Flutter, PHP, HTML, CSS (including Sass and Less) and Tailwind. For Android screens written in Kotlin, only the AI audit checks them, by reading the screens. In languages without screens (a Go server, for example), design doesn't apply. The full table is in Supported languages.

Tabs

Issues

The D-n findings. A card at the top shows whether the project has a design.md, how many screen files were checked and when.

Filter by type (only types with findings appear):

In apps with light and dark themes, the automatic check also flags palette colors hard-coded in the code (they look the same in both themes), a browser bar color (theme-color) that's the same in both themes, and an app that doesn't start in the device's theme.

You can also filter by status: Open, Resolved or Archived.

A finding's detail shows what's wrong, the file and line (or the screen, width and theme, when it was measured in the browser), the source (automatic check, AI audit or reported by you) and the rule. The buttons:

• Fix with your AI agent copies /faundr:design-fix D-n. The agent fixes it following design.md, verifies the fix and marks it resolved.
• Mark as resolved, when you fixed it yourself.
• Archive, when the issue doesn't apply to this project. See below.

Report issue records something you saw on screen: what's wrong, where, the type and the severity. It becomes a D-n like the others. From the agent: /faundr:design-report the list menu opens hidden.

Archive findings and turn off rules

Not every rule fits every project. When you archive a finding, pick a reason (Doesn't apply to this project, False alarm or Design decision) and a scope:

• Only this issue;
• Stop checking this rule in the project, which also archives the other open findings for that rule;
• Stop checking anything of this type in the project.

Disabled rules appear under Guide → Design scope, with a Turn back on button.

When the agent archives a finding, it's labeled "Archived by the agent" along with the reason, and you can reopen it.

To skip one specific piece of code, add a comment on the line above it: // faundr-ignore <rule>: <reason>.

Coverage

What the last full audit checked, area by area: responsive, accessibility, content and states, visual bugs, consistency with design.md, motion and identity. Each area has:

• a result: Passed, Failed, Partial, Not checked, Never checked or Off;
• a score from 0 to 4;
• how it was checked: from the code, measured in the browser or on a device.

The bars show how scores trend between audits. Below them, the Measured responsiveness grid crosses screens with the 4 widths. Each cell says "OK" or how many issues it has; click to see them. When the app has both themes, the Dark theme / Light theme button at the top switches the grid, and each measured finding says which theme it appeared in.

Guide (design.md)

It opens with the Design scope card, which tells Faundr what to check (the same card is under Settings → Design):

Below it are the Approved exceptions (a technique and the reason, like "rounded buttons — part of the brand") and the Disabled rules. After that comes the text of the project's design.md. To change the guide, edit the file in the project or ask the agent.

Showcase

A zoomable, draggable canvas with:

• the design tokens: colors, typography, radii and shadows;
• replicas of your components (buttons, inputs, cards, menus, tags…), with their variants side by side.

The agent draws the replicas with /faundr:design-showcase, from design.md and each component's code. When a component's file changes, its replica gets an Out of date tag. Run the command again to redo only the outdated ones.

Click an element in a replica to open the inspector: classes, size, padding, colors with their token names, border, corner radius and font. It's handy when you're talking to a designer or checking whether a component follows the guide.

Fix order

With many open findings, /faundr:design-fix without a number fixes them in order of importance and pauses after each stage:

1. anything that breaks usability or accessibility;
2. states and content;
3. responsive layout and flow;
4. deviations from design.md;
5. polish.

To fix everything in one go without pausing between stages, use /faundr:design-fix --all. The agent fixes findings one at a time, shows progress (D-15 resolved (3/30)) and doesn't stop to ask. Anything that needs your OK (redoing a whole screen, changing navigation or a form) gets skipped and listed at the end under "Waiting on you". The same --all works with /faundr:quality-fix, /faundr:security-fix, /faundr:error-fix and /faundr:tests-fix.

Commands