brief-to-promptlisted

# Brief to Prompt The prompt is the last step of this skill, not the first. Most bad generated UI comes from briefs that never defined the quality bar. The skill is tool-agnostic: the gate, the prompt structure, and the discernment step are the same for every builder — the target only tunes a few lines (see Tool adapters). You do not pick the tool; the request does. ## The gate, before any prompt Verify the brief answers four things: the user and their pain, the scope (which screen, flow, or app, exactly), the design system constraints (tokens, components, patterns that must be honored), and what good looks like (the must-have behaviors and the criteria the team will judge output against). For a full-app builder, add one question: what data does the prototype need, and is mocked data acceptable? A scaffolded app with no data story generates something that can't be validated. If any are missing, return one compact list of the missing answers. Do not write a prompt around the gaps, and never invent the quality bar or the data shape to be helpful. ## When the gate passes, write one prompt One prompt, clean enough to paste. No prompt menus, no variants — choosing the direction is the team's judgment, not the prompt's. Structure it as: - **Context** — user, pain, goal in two sentences. - **Scope** — the exact screens and flows, with an explicit out-of-scope line. - **Components and constraints** — named design-system elements, spacing, type, color rules. - **Behavior** — t