ui-wireframes

name	ui-wireframes
description	Creates low-fidelity clickable HTML wireframe pages and associated Mermaid flow diagrams to validate navigation, screen intent, and user journeys before implementation. Produces a linked set of HTML files in a docs/wireframes/ directory plus Mermaid flowcharts for user journey, process/status, and data interaction flows. Used by the UX Designer agent and planning workflows. Triggers on "wireframe", "wireframes", "mockup", "mockups", "low fidelity", "lo-fi", "clickable prototype", "HTML mockup", "screen flow", "navigation mockup", "app flow diagram", "mermaid flow", "user journey diagram", "wireframe validation", "screen inventory".
user-invocable	false

UI Wireframes — Clickable HTML Mockups & Mermaid Flow Diagrams

You create low-fidelity clickable HTML wireframe pages and Mermaid flow diagrams that validate an application's navigation, screen inventory, and user journeys before any real UI code is written.

This skill produces artifacts, not production code. Wireframes are disposable validation tools. They prove that every persona can complete every critical journey through clickable links — nothing more.

---

Resources

Resource	Content
resources/wireframe-guide.md	HTML wireframe conventions, templates, file naming, CSS rules, validation checklist
resources/mermaid-flows-guide.md	Mermaid diagram patterns for user journey, process/status, and data interaction flows

Load the relevant resource when creating wireframes or flow diagrams.

---

Critical Rules

1. Intentionally ugly. Wireframes must look like wireframes — gray boxes, system fonts, no colors, no branding, no images. If it looks pretty, you added too much.
2. Every screen is a file. Each screen gets its own HTML file in the docs/wireframes/ directory. Files link to each other with standard <a href> anchors.
3. No dead ends. Every page must have a way back. Every journey must be completable end-to-end by clicking links.
4. Role annotations. If a screen is restricted to specific roles, mark it visibly at the top of the page (e.g., [Role: Admin only]).
5. Action buttons are anchors. Represent actions (Save, Submit, Approve, Delete) as styled anchors that link to the resulting state/screen.
6. Mermaid diagrams are mandatory. Every wireframe set must include at least a user journey flowchart and a process/status state diagram.
7. File plan first. Before writing any HTML, produce a wireframe file plan table listing every file, what screen it represents, and what it links to.
8. Match the screen inventory. Wireframe files must map 1:1 to the screen inventory from the UX design. If the plan says 8 screens, there must be 8 HTML files.

---

Workflow

Phase 1 — Screen Inventory

Before creating any files, confirm the screen inventory. This comes from:

• The UX Designer's navigation/route design (in planning workflows)
• The user's requirements (in standalone usage)

Produce or validate a wireframe file plan table:

File	Screen	Purpose	Links To	Access
docs/wireframes/index.html	Home/Dashboard	Landing page with nav	requests.html, settings.html	All roles
docs/wireframes/requests.html	Request List	Browse/filter requests	request-detail.html, index.html	All roles
docs/wireframes/request-detail.html	Request Detail	View/edit single request	requests.html	All roles
docs/wireframes/admin.html	Admin Panel	System configuration	index.html	Admin only

Phase 2 — Create HTML Wireframes

For each file in the plan, create an HTML wireframe following the conventions in resources/wireframe-guide.md. Key principles:

1. Use the shared CSS boilerplate (inline <style> block — no external files)
2. Include a consistent nav bar on every page with links to all top-level screens
3. Use placeholder content blocks ([List of requests], [Form: Request details])
4. Represent actions as anchor links to their destination screens
5. Add role annotations where applicable
6. Add breadcrumb or back-link navigation for detail/child pages

Phase 3 — Create Mermaid Diagrams

After wireframes are complete, create Mermaid flow diagrams following the patterns in resources/mermaid-flows-guide.md. At minimum:

1. User Journey Flow — flowchart TD showing how each persona navigates through screens
2. Process/Status Flow — stateDiagram-v2 showing entity lifecycle states and transitions
3. Data Interaction Flow — flowchart LR showing UI → Service Layer → Data Source relationships

Place Mermaid diagrams in the plan document (not separate files).

Phase 4 — Validate

Run through the validation checklist:

• Every screen in the inventory has a corresponding HTML file
• Every HTML file has navigation back to at least one parent screen
• Every critical user journey can be completed by clicking links
• No dead-end pages exist
• Role-restricted screens are clearly annotated
• Mermaid user journey flow matches the wireframe link structure
• Mermaid process/status flow covers all entity states from the data model
• All <a href> targets exist as actual files

---

Integration with Other Skills

Skill	Relationship
team-planning	Wireframes are produced during Phase 3 (Parallel Design) by the UX Designer. Sections 8–9 of the plan template are populated by this skill's output.
power-apps-code-apps	Wireframe screens map to React routes/feature modules in the implementation plan.
power-pages	Wireframe screens map to site pages and navigation in the implementation plan.
ui-fluentui-react	Implementation replaces wireframe blocks with real Fluent UI components.
ui-website	Implementation replaces wireframe blocks with themed website components.

---

Standalone Usage

This skill can be used outside of the planning team workflow. When invoked directly:

1. Ask the user for the app/site description, personas, and key journeys
2. Derive a screen inventory from the requirements
3. Produce the wireframe file plan table
4. Get user confirmation on the file plan
5. Generate all HTML wireframes into docs/wireframes/
6. Generate Mermaid diagrams
7. Run the validation checklist