Create Mockups

Create Mockups

Produces UI mockups and wireframes for a feature from its requirements and specification, settling the visual layout, component breakdown, interaction states, and flows before a line of UI code is written.

Without this step, UI work starts with no shared picture of what to build, so layout, states, and accessibility are improvised during implementation and reworked in review.

For features with no user interface (a pure API, a background job, a CLI), skip this phase and state the skip explicitly.

Prerequisites

• Apply the shared SDLC conventions in skills/sdlc/references/shared.md.
• If no argument is provided, locate the feature directory under .sdlc/features/ whose frontmatter issue field references $ISSUE_NUMBER.
• .sdlc/features/N-/requirements.md (must have passed review with findings verdict approved), or a requirements document provided in context or as a file path ($1)
• .sdlc/features/N-/specification.md (must have passed review with findings verdict approved, if produced): reuse the data models, API contracts, and flows it defines so the mockups stay faithful to what the system can actually deliver
• .sdlc/features/N-/codebase-analysis.md (optional, if existing code was analyzed): reuse existing UI components and patterns it inventoried, and honor any "must not change" constraints on shared components

Steps

1. Read the requirements, the specification if present, and the codebase analysis if present.
2. Decide whether the feature has a UI surface. If it does not, emit verdict: skipped (do not write mockups.md). The skipped verdict routes the pipeline straight to the next phase, bypassing /review-mockups.
3. Inventory every screen, view, or dialog the feature needs, cross-referenced against the requirements and the spec's flows.
4. For each screen, draw an ASCII wireframe inside a fenced block, annotated with the regions, primary action, and data shown.
5. Break the UI down into components, marking which already exist in the codebase (reuse), which must be extended, and which are new.
6. For each key component and screen, enumerate its interaction states: empty, loading, populated, error, and disabled or read-only where relevant.
7. Map the navigation between screens as a flow, including entry points, exits, and the back path.
8. Specify responsive behavior across the viewports the feature targets (mobile, tablet, desktop), noting what collapses, reorders, or hides.
9. Call out accessibility requirements: keyboard reachability, focus order and visible focus, screen-reader labels, color-contrast targets, and minimum touch-target sizes.
10. Note copy and content as placeholders so writers can fill them without changing layout.
11. Flag where high-fidelity mockups (Figma, HTML/CSS, a prototype) are warranted and cannot be conveyed by ASCII, and record a pointer or a request for them.
12. Write the output to .sdlc/features/N-/mockups.md.

Output Format

Use the template at skills/sdlc/templates/features/mockups.md (copied to .sdlc/templates/features/mockups.md by /initialize-sdlc-directory; use the project's customized copy if present). Write the result to the artifact path named in the steps above. +-----------------------------------------------+ | | +-----------------------------------------------+ | | | | | | | [ primary action ] | | | +-----------------------------------------------+

**Regions**

| Region | Content | Data source (spec ref) |
|---|---|---|
|  |  |  |

**Primary action:** 

### 

...

## Component Breakdown

| Component | Status | Notes |
|---|---|---|
|  | Reuse / Extend / New |  |

## Interaction States

### 

| State | What the user sees |
|---|---|
| Empty |  |
| Loading |  |
| Populated |  |
| Error |  |

## Navigation Flow

--select--> --save--> ^ | |_________________back_____________________|

## Responsive Behavior

| Viewport | Layout changes |
|---|---|
| Mobile ( |
| Tablet (640-1024px) |  |
| Desktop (>1024px) |  |

## Accessibility

- **Keyboard:** 
- **Screen reader:** 
- **Contrast:** 
- **Touch targets:** 

## Copy Notes

- 

## High-Fidelity Needs

- 

## Out of Scope

- 

Outcome

If $OUTCOME_YAML is set, emit your verdict there per skills/sdlc/references/shared.md:

| Verdict | When | |---|---| | approved | The mockups artifact was produced (or revised) with status: draft, ready for /review-mockups | | skipped | The feature has no UI surface; no artifact is written and the pipeline proceeds past review to the next phase |

If the artifact could not be produced for any other reason, omit the file.

Example Usage

Scenario 1: Notification center Requirements describe a notification list with read/unread state and an empty state for new users. Wireframes cover the list screen, the empty state, and the per-notification detail, with states for loading, populated, and error, plus the navigation flow from the app shell.

Scenario 2: Bulk file upload Requirements describe a multi-file upload with progress and failure retry. Wireframes cover the drop zone, the in-progress list with per-file progress, and the failure state with retry, plus a responsive note that the list collapses to one column on mobile.

Scenario 3: Pure API feature, no UI The specification defines a webhook receiver with no user interface. The skill leaves the artifact unwritten and emits verdict: skipped so the pipeline continues to the next phase without a review.

Completion Checklist

Before handing off to review, confirm:

• [ ] Each key component and screen enumerates interaction states (empty, loading, populated, error)
• [ ] Accessibility requirements called out (keyboard, screen-reader labels, contrast, touch targets)

Self-check the draft against the [review-mockups checklist](../review-mockups/SKILL.md) and fix what you can, so review finds less to flag.

Next Step

Run /review-mockups to audit the mockups for coverage, usability, accessibility, consistency, and spec fidelity before moving on. Once approved, continue with /create-plan.

Useful Commands Reference

No CLI commands required. This skill operates on document content provided in context.

Source & license

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

• Author: tomzx
• Source: tomzx/agents
• License: MIT

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