# Prototype Interface

> Create and verify an interactive UI prototype from a selected visual target or an existing product language. For greenfield work without a target, first generate exactly three different image-based directions and wait for selection. Use for wireframes, prototypes, and UI exploration.

- Skill: `leihuang23/prototype-interface` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add leihuang23/prototype-interface`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leihuang23/prototype-interface/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: leihuang23 (https://skillmd.com/u/leihuang23)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/leihuang23/prototype-interface

---


# Prototype Interface

A prototype is a testable hypothesis about hierarchy and interaction, not a collection of attractive screens.

## Visual-target gate

1. Inspect the product’s existing UI, tokens, components, assets, and representative flows.
2. If an authoritative screenshot, design file, brand system, or selected direction exists, use it as the visual target.
3. If the work is greenfield and no target exists, generate exactly three image-based directions that differ in layout composition, typography, density, color behavior, and visual voice. Label them A, B, and C with a short rationale and tradeoff.
4. Show the three directions together and wait for the user to select one. Do not build the interface before selection.

Text-only mood boards do not satisfy the gate.

### Greenfield stop contract

When no visual target exists, the current invocation ends at the selection gate:

- Persist exactly three inspectable direction artifacts in the workspace. A conversation-only image or a claim that directions are "shown above" is not evidence.
- Persist each direction as a static image artifact: PNG, JPG, WebP, or standalone SVG. Preselection HTML, CSS, JavaScript, and runnable UI files are forbidden, even when described as concept boards.
- Keep each direction at visual-language fidelity, not interface fidelity. Show an aesthetic thesis, type pairing, palette, spatial rhythm, abstract composition thumbnail, and three voice keywords. Use static shapes and text rather than product controls.
- Do not show forms, buttons, inputs, navigation routes, responsive behavior, component states, multiple flow screens, or a detailed end-to-end product interface. Those belong after selection.
- Name or caption every artifact as Direction A, Direction B, or Direction C. Reference the artifact paths in the final response.
- Keep every SVG self-contained and text-safe. Each `url(#id)` reference must resolve to an `id` defined in the same file; dangling paint-server references render black. Decorative shapes stay behind text: reserve text-safe zones and never overlap motifs with captions, labels, or keywords. Do not embed scripts, `foreignObject`, links, or event handlers.
- Validate every SVG with the bundled checker before persisting it: run `scripts/validate_directions.py` from this skill's directory against each file and record the result in the evidence packet. Then render each SVG once and inspect it for black regions and text occlusion; fix and re-validate before stopping.
- Render one static overview image containing all three directions if the tools support it, using a single batch or rendering session.
- Do not create the product app, prototype flow, state matrix, or implementation scaffold before selection. Do not begin any step in the prototype workflow below.
- Once the three artifacts, rationales, tradeoffs, and selection request exist, stop. Optional polish is not a reason to continue working.
- If no available tool can persist a static image or SVG, report that evidence blocker and stop. Do not substitute an interactive artifact.

## Prototype workflow

1. Define the user task, entry state, success signal, and critical decision points.
2. Map the shortest complete flow and its alternate or failure routes.
3. Write a state matrix before styling.
4. Build semantic structure and interaction using the selected design language.
5. Use realistic content, including long, empty, invalid, and localized examples.
6. Implement keyboard behavior, focus management, labels, announcements, target sizes, contrast, zoom, and reduced motion.
7. Capture the prototype at agreed narrow and wide viewports.
8. Compare expected and actual at the same browser, scale, theme, data, fonts, and motion state. Preserve expected, actual, and diff.
9. Test the critical flow as a user, then revise until no material visual or interaction mismatch remains.

## State matrix

```markdown
| Surface | State | Trigger | Visible response | Keyboard/focus | Evidence |
| --- | --- | --- | --- | --- | --- |
```

## Quality rules

- Wireframes must still establish hierarchy, content, and interaction.
- Do not hide weak layout behind gradients, glass, illustrations, or excessive cards.
- Avoid placeholder text where content length affects design.
- Treat overflow, clipping, unexpected wrapping, inconsistent spacing, and fallback fonts as failures.
- Report browser rendering context because visual snapshots are environment-dependent.

## Evidence packet

Before selection, return the three local artifact paths, rationales, tradeoffs, one recommendation, and a request to select A, B, or C. After selection, return target selection, flow and state matrix, runnable prototype path, test instructions, viewport matrix, expected/actual/diff artifacts, accessibility checks, and unresolved product or visual questions.