Ui Mockup Desktop Workbench

ui-mockup-desktop-workbench

中文速查

• 中文名：高保真 UI 交付对齐器 / 桌面工作台 UI Mockup 生成器
• 英文稳定名：ui-mockup-desktop-workbench
• 分类：产品与 PRD
• 你可以这样叫我：基于 PRD 和 UI 规范出高保真 mockup、先从 PRD 出 UI 结构和 ASCII 布局再做高保真、生成桌面工作台真实页面、把这个 Agent Client PRD 做成可交付开发的 UI、让前端按这个 UI 复刻
• 适合：把 PRD、UI 规范、真实项目组件、参考截图和状态清单转成先结构、后视觉、再交付实现的 UI contract、mockup 或项目原生 preview。
• 不适合：问题还没定义清楚；只需要 PRD 文案；只做移动端或营销页；不需要视觉/状态确认而是直接写生产功能。

Overview

Use this Skill when the goal is not just a pretty standalone page, but a staged UI handoff that product, design, and engineering can inspect and implement from.

The default output is a UI implementation contract, not disposable HTML. The contract starts with UI structure and states, then moves to visual fidelity only after the screen model is coherent. Standalone HTML is allowed only as one output mode. When the user provides a real frontend project path and wants development to reproduce the design, prefer a project-native preview route/component using the real app's components, tokens, icons, and layout conventions.

The workflow combines:

1. ui-wireframe-to-html discipline: structure and state before polish.
2. Desktop Agent workbench patterns: navigation, task list, execution canvas, artifact/workspace panel, settings, and result surfaces.
3. User-provided UI specifications: tokens, layout rules, component style, copy tone, and interaction constraints override generic design instincts.
4. Project-native design discovery: real routes, components, styles, tokens, icons, screenshots, and nearby states must be inspected before claiming production alignment.
5. Frontend design quality: dense but readable desktop UI, realistic data, stable dimensions, no decorative one-note visual filler.

Relationship To ui-wireframe-to-html

ui-wireframe-to-html is the lightweight structure-only entrypoint. It is useful when the user only wants UI structure, state model, ASCII layout, or a quick low-fidelity HTML wireframe.

This Skill owns the full chain:

PRD -> screen inventory -> state model -> ASCII layout -> structure review gate -> high-fidelity visual handoff or project-native preview -> implementation handoff

If the user asks for high fidelity, real project alignment, visual handoff, frontend replication, or component mapping, stay in this Skill and include the wireframe stage internally instead of handing off to ui-wireframe-to-html.

If the user explicitly wants only low-fidelity structure and does not need visual polish or implementation mapping, use ui-wireframe-to-html instead.

Output Modes

Choose one mode before implementing visuals. State the chosen mode and why.

For detailed selection rules, read references/output-mode-selection.md.

| Mode | Use When | Primary Outputs | Do Not Use When | | --- | --- | --- | --- | | project-native-preview | The user provides a real frontend project path or asks development to "replicate" the UI. | ascii-layout.md, preview route/component in the project, screen-contract.md, component-map.md, implementation-notes.md, screenshots. | The user only wants early concept exploration or forbids repo edits. | | visual-handoff | The PRD is stable and development needs exact visual guidance, but direct project integration is risky or not requested. | ascii-layout.md, high-fidelity HTML/React artifact, screenshots, component map, implementation notes, migration boundary. | The user expects production-ready code. | | concept-html | Early product/design discussion needs a quick visual reference after structure is checked. | ascii-layout.md, standalone mockup.html, screen contract, assumptions. | The user wants frontend to implement it accurately; then use visual-handoff or project-native-preview. |

Default to project-native-preview when all are true:

• A real frontend project path is provided or discoverable.
• The user says the UI should match the production app, online version, existing components, or screenshots.
• The mockup is intended to guide implementation.

Default to visual-handoff when the real project exists but editing it would exceed the requested scope.

Use concept-html only when the goal is fast concept confirmation, not production implementation alignment.

PRD Boundary

This Skill is downstream of PRD maturity:

• If the user still needs to define the product goal, scope, workflow, states, or acceptance criteria, hand off to prd-architect.
• If a PRD exists but has conflicts, missing acceptance criteria, unclear states, or untestable flows, hand off to prd-review before producing the formal mockup.
• If the PRD and UI spec are clear enough, use this Skill to create the desktop mockup artifact.
• If the mockup process exposes PRD gaps, stop and record a PRD feedback note instead of silently inventing requirements.

prd-architect may include lightweight UI references, screenshots, or mockup notes inside a PRD. Formal multi-state desktop HTML mockups belong here.

If the UI is meant to drive implementation, update the PRD or prepare a PRD UI appendix after the final visual decision. The PRD should link the final mockup/preview, screenshots, and screen contract.

Context Intake

Before generating UI, collect or discover:

• PRD path or pasted PRD content.
• UI specification path or pasted style rules.
• Real frontend project path, app name, route, or package when available.
• Target page set: workbench, task list, execution session, artifact page, settings page, empty state, error state, or all of them.
• Runtime/product context: desktop app, browser shell, Electron/Tauri/native wrapper, logged-in assumptions, target viewport.
• Existing app conventions, component library, screenshots, or competitor references if provided.
• Output destination and expected format: standalone HTML, React route, static artifact folder, screenshot, or design handoff markdown.

Minimum input maturity:

• product goal and target user are known
• page or screen set is known
• primary workflow and key states are known
• non-goals or out-of-scope states are known
• acceptance or review criteria are known enough to judge the mockup

If these are missing, route back to prd-architect or prd-review depending on whether the PRD must be created or reviewed.

Ask at most three questions only when missing information changes the page set, design constraints, or output format. If the user supplied PRD and UI spec paths, read them and proceed with explicit assumptions.

Design Discovery Gate

Before any visual implementation, inspect project-local design evidence when available. Do not ask the user for information that can be read from the repo.

Read or inspect:

• Real page entrypoints, route files, shell/layout components, and adjacent page states.
• Global styles, theme tokens, CSS variables, design token files, icon system, and UI library usage.
• Existing navigation, sidebar, modal, menu, avatar/settings, button, input, tab, toast/error, artifact/result, and empty-state components.
• Local screenshots, Storybook, design docs, or current running app screenshots when available.
• Existing copy tone, density, spacing, radius, shadows, status colors, and light/dark mode defaults.

Before generating UI, output 5-8 bullets under Discovered UI Constraints:

• concrete component/style evidence found
• what must be reused
• what can be newly created
• where assumptions start

If the project cannot be started or inspected fully, say so and mark the mockup as static inference. Never claim "matches production" without project evidence.

Wireframe Stage And Review Gate

Always model structure before visual fidelity. This stage is the reusable core inherited from ui-wireframe-to-html.

Create or include:

• screen-inventory: pages, modals, popovers, panels, and major regions.
• state-model: empty, draft, loading, queued, running, stopped, success, partial failure, error, permission, and settings states relevant to the PRD.
• ascii-layout.md or an equivalent section: desktop layout zones, fixed/flexible widths, scroll containers, primary actions, and state-specific changes.
• interaction-notes: user actions, agent actions, state transitions, and recovery paths.
• prd-traceability: the PRD section, UI spec rule, screenshot, or assumption that justifies each screen/state.

Run a structure review gate before high fidelity:

• If the user asked for exploration, stop after the wireframe stage and ask for confirmation before visual implementation.
• If the user already asked for high-fidelity implementation handoff, continue after documenting unresolved structure assumptions.
• If the wireframe reveals missing PRD states, conflicting IA, or untestable flows, record a PRD feedback note and route to prd-review or prd-architect before polishing.
• Do not use visual polish to hide unresolved navigation, state, or artifact ownership questions.

Workflow

1. Read authoritative inputs

• Read the PRD before designing screens.
• Read the UI specification before choosing colors, typography, spacing, density, or component styling.
• Read the real frontend project when provided; project-local design language outranks generic mockup style.
• If both conflict, preserve product requirements from the PRD and visual constraints from the UI spec; call out unresolved conflicts.
• If conflicts block screen/state decisions, create a PRD feedback note and recommend prd-review.

1. Choose output mode

• Select project-native-preview, visual-handoff, or concept-html.
• Explain the selection in one paragraph.
• If the user wants implementation alignment and a project path exists, do not default to standalone HTML.

1. Run the Design Discovery Gate

• Inspect the real app's route, components, styles, tokens, and screenshots when available.
• Write Discovered UI Constraints before implementing.
• If the project cannot be inspected, document the limitation and lower confidence.

1. Run the Wireframe Stage

• Extract the screen inventory from the PRD and target workflow.
• Draft the state model before drawing final visuals.
• Produce ascii-layout.md or an equivalent layout section before styling.
• Identify scroll containers, fixed rails, flexible work areas, primary actions, and state-specific region changes.

1. Pass the structure review gate

• If structure is exploratory, stop and ask for confirmation.
• If the user already requested final handoff, proceed while clearly marking unresolved assumptions.
• If structure gaps block implementation, produce PRD feedback instead of high-fidelity output.

1. Extract a screen contract

• Identify primary user roles, core jobs, navigation model, data objects, and page hierarchy.
• List required screens and states, including empty, loading, streaming/running, success, partial failure, error, permission/login, and recovery.
• Map each screen to PRD sections and UI spec constraints.

1. Create a component map

• Map every visible UI region to a production component, style source, or explicit "new component needed" entry.
• Include related file paths, reuse/new/modify status, states, and implementation notes.
• Do not treat standalone HTML class names as production component names.

1. Refine structure before visual styling

• Use the confirmed ASCII layout as the visual skeleton.
• For Agent workbenches, default to a four-zone shell when suitable:
• left navigation and account/workspace switcher
• task/session list or recent work rail
• central execution/conversation/work canvas
• right artifact, resource, preview, inspector, or settings panel
• Do not invent large marketing heroes, decorative cards, or mobile-first stacks for dense desktop tools.

1. Design realistic page states

• Use real product nouns from the PRD.
• Fill tables, task cards, logs, artifact panels, and settings with plausible domain data.
• Include the state transitions a PM or engineer needs to judge: first-run empty, active execution, completed output, error/retry, and settings or artifact management.

1. Implement the chosen artifact

• For project-native-preview, create a non-production preview route, story, fixture state, or preview component following local conventions. Keep it isolated and reversible.
• For visual-handoff, create a high-fidelity HTML/React artifact and mark it as visual reference, not production code.
• For concept-html, create a standalone HTML/CSS mockup that opens locally without a build step.
• Keep dimensions stable with explicit desktop layout constraints, fixed rails, responsive min/max widths, and scrollable panels.
• Use icons from the existing project icon library when available. For standalone HTML, use inline SVG or simple CSS shapes only when no icon library is available.

1. Verify visually

• Open or render the mockup when tools are available.
• Check at least one desktop viewport around 1440x900 and one narrower desktop viewport around 1280x800.
• Verify text does not overflow buttons, cards, rails, tabs, or panels.
• Verify the UI is not blank, overlapped, or dominated by a single decorative color family.
• For project-native previews, start the local app if feasible and capture screenshots from the real route.

1. Package the result

• Provide file paths, local open/run instructions, screenshots if generated, and a short handoff note.
• Include the wireframe-stage output or link to ascii-layout.md.
• Include a traceability table from PRD requirement to screen/state.
• Include component-map.md and implementation-notes.md when the UI is meant to guide frontend implementation.
• Include known assumptions and any PRD/UI-spec conflicts.
• Include any PRD feedback discovered while building the mockup, with recommended next route: prd-review for conflict/readiness issues, prd-architect for missing PRD sections.
• Update the PRD UI appendix or provide exact PRD changes to sync the final UI contract.

Desktop Workbench Rules

Read references/desktop-workbench-ui-principles.md before designing a desktop Agent workbench shell, multi-panel workspace, settings page, artifact page, or task execution UI.

Key defaults:

• Dense operational UI beats landing-page composition.
• User attention should flow from navigation/context to task list to execution canvas to artifact panel.
• Running, queued, failed, and completed task states must be visually distinct.
• Settings pages should feel like system controls, not content cards.
• Artifact pages should prioritize inspection, versioning, actions, and provenance.

Output Contract

Read references/mockup-output-contract.md before finalizing deliverables.

Default deliverables:

• README.md or handoff note with purpose, assumptions, and open/run instructions.
• ascii-layout.md or equivalent wireframe-stage section covering UI structure, layout zones, and state model.
• screen-contract.md or equivalent section describing screens, states, and PRD traceability.
• component-map.md when the result is used for implementation alignment.
• implementation-notes.md when a frontend team will build or convert the UI.
• mockup.html, high-fidelity React artifact, or project-native page/component depending on the chosen mode.
• Screenshot or browser verification notes when feasible.

Resource Guide

• references/output-mode-selection.md：选择 project-native-preview、visual-handoff 或 concept-html。
• references/verification-checklist.md：最终视觉和交付包验证清单。
• references/desktop-workbench-ui-principles.md：桌面 Agent 工作台布局和状态规则。
• references/mockup-output-contract.md：交付物结构、迁移边界和 implementation handoff。
• scripts/check_mockup_package.py：检查 mockup package 的最小文件结构。

Side Effects And Safety

• Do not overwrite existing product routes or design files unless the user explicitly asks for repo integration.
• For p

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: PANGKAIFENG
• Source: PANGKAIFENG/ai-product-manager-skills
• License: MIT

Install and usage instructions live in the source repository linked above.