A design contract records what an interface is for, who uses it and which decisions should guide its implementation. It gives both people and agents context that a screenshot or component API cannot express.
Capture the intent
Describe the page’s purpose, audience, important data, key actions and constraints. Add rationale for decisions that would otherwise look arbitrary to the next person working on the page.
For a billing page, useful context includes who can change a plan, how a pending change is represented, and when the interface must ask for an explicit confirmation. Visual foundations and shared design rules belong to the Design System; product-specific decisions belong in the page contract. A rule can say to make the primary action clear; the billing contract explains which action is primary and who can take it.
Work with Design Skills
Use /ff-design to work from the relevant foundations and contracts. /ff-import extracts intended flows from a prototype into page contracts; /ff-audit reviews the interface against the relevant context.
Contracts can be draft, inferred or decided. Review inferred decisions before treating them as accepted product requirements. A contract records intent; it is not an authorization to execute a sensitive action.
Make decisions visible in code review
The cloud contract store is canonical. Sync the repository mirror with:
npx frontfriend design syncThe generated .frontfriend/design/ directory makes the context available alongside the implementation. Review and commit its changes with your project workflow. Avoid editing the mirror directly because a later sync can replace those changes.
Keep the system and the product connected
Combine contracts with MCP for target-specific component facts and Design Skills for guided workflows. When the product’s behavior changes, update the accepted decisions so later iterations work from current intent.