UI to code
Implement a visual design in the user's actual stack while preserving an
honest boundary around reviewer independence.
Current availability boundary
The coordinator has no image or binary attachment contract. Managed
cross-family structural extraction is temporarily unavailable. Do not pass
paths, base64 image bytes, invented media fields, or raw provider commands.
When the user requires an independent visual extraction as a governance gate,
return typed unavailable and stop that gate.
Workflow
- Inspect the image using the active host's native visual capability. When any region is
detail-bound — small text, dense charts, closely spaced lines, fine UI
detail — magnify it before reading: use the host's native zoom or crop
actions, or a code-execution crop from the full-resolution source. A
full-view-only read of sub-patch detail is unreliable and tends to fail
confidently rather than uncertainly.
- State that the structural read is primary-only; do not call it a two-read or
cross-family result.
- Extract a working spec: layout regions, elements, visible text, hierarchy,
approximate spacing and colors, interaction hints, responsive behavior, and
accessibility requirements.
- Inspect the project before writing. Reuse its framework, components, design
tokens, naming conventions, tests, and accessibility patterns.
- Implement in the trusted primary's normal mutation boundary. This public
skill does not grant a provider backend file-write, shell, test, commit, PR,
merge, or deploy authority.
- Run project-appropriate verification and compare the rendered result against
the source image. Record assumptions where the image is ambiguous.
If the caller supplies an independently authored textual design spec, an
advisory route may review that text with the exact artifact snapshot and author
model. That is a text-spec review, not image analysis.
Guardrails
- Do not invent the user's framework or component library.
- Prefer existing design tokens over hardcoded values.
- Add semantic HTML, keyboard behavior, focus states, and accessible labels
even when the static mockup cannot depict them.
- Do not reuse working element identifiers blindly; map them to project
conventions.
- Do not claim pixel precision for values that were visually estimated.
- Do not claim independent verification until a signed typed image contract is
advertised by the native runtime.
1---2name: ui-to-code3description: Turn a UI mockup, screenshot, or wireframe into code in the active primary's project context. Use when the user says "turn this into code," "build this UI," "implement this mockup," "code this screenshot," or "extract a UI spec." Also offer this proactively when implementation is about to start from a visual artifact. The unified plugin currently has no managed cross-family image transport, so the active primary performs the visual extraction and implementation while explicitly reporting that independent visual extraction is unavailable; never claim a second visual read occurred.4---56# UI to code78Implement a visual design in the user's actual stack while preserving an9honest boundary around reviewer independence.1011## Current availability boundary1213The coordinator has no image or binary attachment contract. Managed14cross-family structural extraction is **temporarily unavailable**. Do not pass15paths, base64 image bytes, invented media fields, or raw provider commands.16When the user requires an independent visual extraction as a governance gate,17return typed unavailable and stop that gate.1819## Workflow20211. Inspect the image using the active host's native visual capability. When any region is22 detail-bound — small text, dense charts, closely spaced lines, fine UI23 detail — magnify it before reading: use the host's native zoom or crop24 actions, or a code-execution crop from the full-resolution source. A25 full-view-only read of sub-patch detail is unreliable and tends to fail26 confidently rather than uncertainly.272. State that the structural read is primary-only; do not call it a two-read or28 cross-family result.293. Extract a working spec: layout regions, elements, visible text, hierarchy,30 approximate spacing and colors, interaction hints, responsive behavior, and31 accessibility requirements.324. Inspect the project before writing. Reuse its framework, components, design33 tokens, naming conventions, tests, and accessibility patterns.345. Implement in the trusted primary's normal mutation boundary. This public35 skill does not grant a provider backend file-write, shell, test, commit, PR,36 merge, or deploy authority.376. Run project-appropriate verification and compare the rendered result against38 the source image. Record assumptions where the image is ambiguous.3940If the caller supplies an independently authored **textual** design spec, an41advisory route may review that text with the exact artifact snapshot and author42model. That is a text-spec review, not image analysis.4344## Guardrails4546- Do not invent the user's framework or component library.47- Prefer existing design tokens over hardcoded values.48- Add semantic HTML, keyboard behavior, focus states, and accessible labels49 even when the static mockup cannot depict them.50- Do not reuse working element identifiers blindly; map them to project51 conventions.52- Do not claim pixel precision for values that were visually estimated.53- Do not claim independent verification until a signed typed image contract is54 advertised by the native runtime.
sumitake