Design-to-Spec Handoff

Convert a reference UI design into an implementation-ready specification package that a downstream coding agent or developer can implement with minimal ambiguity.

Why this skill exists

Design-to-code is lossy, and the losses compound on specialized platforms. A coding agent looking at a mockup will reach for familiar patterns — but those patterns break when the target is a Chrome extension (CSP blocks inline scripts), a Splunk dashboard (must use SplunkUI components), or a Tauri app (UI runs in a webview with Rust IPC). This skill sits between "here's what it should look like" and "go build it." It forces a structured analysis that surfaces platform constraints, flags architectural decisions, and prevents committing to code before the constraints are understood.

The structured JSONC output works as a discipline gate: the coding agent gets a spec with explicit platform rules, component mappings, and acceptance criteria rather than improvising from a screenshot.

Core workflow

1. Analyze the design input — accept images, screenshots, URLs, mockups, or natural-language descriptions. Extract layout, components, color system, typography, spacing, interaction cues, responsive assumptions, and accessibility implications.

2. Inspect project context — if the user provides a codebase or project, infer: framework, component library, styling system, theme/token strategy, routing, build conventions, and existing design-system patterns. Classify as greenfield, retrofit, or extension.

3. Discover platform constraints — this is the step generic tools skip. Identify what the target platform forbids, requires, or changes:

   • Chrome extensions: manifest v3 schema, CSP restrictions (no inline scripts, no eval), background service worker limitations, popup size constraints, message passing patterns
   • Splunk dashboards: SplunkUI component library requirements, dashboard framework SDK, search job patterns, token-based data binding