Overview

Coding agents write CSS for the browser they were trained on. Gameface implements a subset of the web platform , so a substantial share of that CSS reaches the engine, gets flagged in the console, and never renders.

This chapter documents four tools that close the gap: an MCP server, a documentation corpus, a negative ruleset, and a skill that produces a signed-off specification before any code is written. The final article reports three interfaces built with them.

The Problem

Agents write CSS for the browser they were trained on. Gameface implements only a subset of the web platform, so many modern CSS features are not supported. When an agent writes unsupported CSS, the engine silently drops it—no build errors, no linter warnings, just silent failures that appear only when code runs.

The knowledge of what works exists, but it’s not accessible to the agent while writing. Constraints are discovered in review comments, not prevented during generation.

The Toolchain

Each tool works independently, and they compose.

Tool	Function	Article
Gameface MCP server	Drives a live Player over the Chrome DevTools Protocol, so the agent can read the console, inspect the DOM, capture screenshots, assert on layout, and measure frame timing	Setting up the MCP Server
Documentation corpus	This guide, restructured for an agent to search while writing	Grounding the Agent
Negative ruleset	An explicit “never emit this” list generated from engine feature detection	Grounding the Agent
Game UI Conductor skill	Extracts requirements and produces a written specification, signed off before any code	The Conductor Skill

All four live in one repository, github.com/CoherentLabs/Gameface-MCP . The skill files are shared across Claude Code, GitHub Copilot, and Gemini CLI rather than duplicated per client.

Limitations

This toolchain catches runtime errors but doesn’t prevent design issues. An agent without a defined palette and type scale produces competent but incoherent work. See Design First to settle design before prompting.

The toolchain also checks in isolation—an agent can complete a screen correctly while breaking the dashboard hosting it. And assertions report what the agent believes it ran, not what actually ran.

Reading Order

The second and third articles set up the toolchain. The fourth covers the work that precedes any UI request. The last two cover the loop of specifying, building, and checking the result. Read them in order on a first pass.

Experiments collects internal write-ups. The first entry documents three UIs built with this toolchain: a screen added to an existing dashboard, a reusable component family, and a complete eight-screen interface.

Nothing in Experiments is a Product

Those write-ups exist for their specifics, and because the failures are more instructive than the successes. Results vary with the model, the prompt, and above all the design handed to the agent.