# Agent context & generated facts

Keep component knowledge close to the code that uses it.

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

```bash
npx frontfriend design sync
```

Review 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](/docs/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](/llms.txt) and Markdown versions of its documentation for reading. Those public documents complement authenticated context; they contain no private Design System data.