An agent needs to know which system and components the application actually uses. Frontfriend uses a context channel combining generated facts, registry-served rules and design contracts.
The project files
| Path | Purpose |
|---|---|
.frontfriend/foundation.md | Design-system-specific semantic vocabulary, when generated |
.frontfriend/components.md | Installed component API facts, where generation is available |
.frontfriend/rules/ | Registry-served composition rules |
.frontfriend/design/ | Read-only generated mirror of design contracts |
frontfriend.config.js | Application target and Design System identity |
Read the files present in the repository and ask MCP for missing facts. Context depends on the application’s target and installed components.
Sync the design mirror
npx frontfriend design syncReview the resulting diff. The cloud contract store is canonical; hand changes to the generated mirror can be overwritten by a later sync. Commit the mirror according to your project workflow so reviewers can see the decisions behind an implementation.
Before generating a screen
Read the foundation vocabulary and installed component inventory. Inspect the source or use get_component_api for the target-specific contract. Read applicable design rules through MCP, including shared area rules and component-specific guidance. Fetch missing component knowledge through MCP. Use supported system variants instead of inventing an API from another primitive.
Facts over assumptions
Generated export names and owned props come from source. Inherited native or primitive props are pointers to upstream documentation. Composition rules explain supported usage; they do not make incompatible target exports interchangeable.
This website exposes llms.txt and Markdown versions of its documentation for reading. Those public documents complement authenticated context; they contain no private Design System data.