The Conductor Skill

Well-built code for the wrong feature is expensive. The Game UI Conductor clarifies requirements and obtains sign-off on a written specification before writing any UI code.

The Problem It Solves

Agents fill gaps in vague requests with typical answers and build hundreds of lines on assumptions. When those assumptions are wrong, restarting costs less than fixing.

The Conductor clarifies requirements upfront, produces a readable specification, and writes no code until it’s accepted.

Not Every Request Needs This Treatment

This applies to rough ideas only. Bug fixes, copy changes, style adjustments, and requests that already specify interactions and data shape are out of scope—they’re already specifications.

The Six Stages

1. Reason about the relevant dimensions

   The skill consults a checklist of game UI design dimensions covering interaction, animation and feedback, data and state, scale, accessibility, localization, sort and filter, and lifecycle. It then determines which apply. Not every dimension applies to every feature, and the purpose is to catch the ones the request did not mention.

2. Clarify in rounds

   Three rounds at most, stopping earlier once nothing new surfaces.

   Round one asks everything relevant as a single batch rather than as a sequence of separate messages, and every question carries a sensible default, so “use your judgment” is a valid answer. Round two follows what round one opened up, so a yes to drag-and-drop leads to “what is the gamepad equivalent?” and “what happens when an item is dropped outside the panel?”. Round three occurs only when a genuine open question remains.

   Anything still unresolved becomes a stated assumption in the specification rather than a further question.

3. Draft the specification and obtain sign-off

   A short document under fixed headings: Goals, Interactions, Data and state, Scale, Accessibility, Localization, Assumptions. It closes with a direct question asking whether this is what should be built.

   This stage is a hard gate . No code is written until the specification is accepted in the conversation. Rejecting it loops back with the correction, repeating as required.

4. Implement

   Normal rules apply from this point. The agent follows gameface://code-instructions and calls search_gameface_docs while writing CSS and JavaScript, as covered in Grounding the Agent.

5. Validate

   Given a Gameface MCP connection, the agent runs the layout assertions, perf_lint, and, where the view is dominant, perf_measure against what it built. Failures are fixed and the specific check re-run.

   Without a connection it reports that fact rather than skipping silently. Verifying What the Agent Builds covers interpreting the results.

6. Report

   What was asked against what was assumed, what was accepted at sign-off, what was built, and which checks passed or could not run.

Running It

One set of files serves every client. The trigger differs.

Client	Invocation
Claude Code	Automatic, matching the skill’s description against the request. Direct invocation with /gameface-conductor also works.
GitHub Copilot (VS Code)	Automatic. Copilot’s Agent Skills scans .claude/skills/ alongside .github/skills/, so the file is picked up unmodified.
Gemini CLI	Explicit only, since Gemini CLI has no auto-triggered skill concept. /gameface-conductor <request> injects the same skill content rather than duplicating it.

Copy .claude/skills/gameface-conductor/ into the project to use it, plus .gemini/commands/gameface-conductor.toml for Gemini CLI. Both live in the Gameface-MCP repository .

Why the Questions Matter More Than the Specification

The questions surface decisions early—what the empty state says, whether the panel pauses the game, whether the list holds 500 rows. Answering them in advance costs less than answering them later, under pressure, with code already written against a different answer.

Limits

Answering every question with the default produces a specification full of reasonable-sounding assumptions, which the build then follows precisely.

The dimensions checklist covers behavior only. Nothing in it asks what the panel should look like, which is why Design First is a separate step.

Sign-off is also not review. Accepting a specification confirms the plan and says nothing about the code produced from it.