Screen Wireframes

Screen wireframes

A wireframes canvas shows how a complex screen looks and works before all of it exists: each region drawn where it sits, marked with where it stands, explained in a note, and the choices only the owner can make set out as questions. It is the design's picture, kept true to the code as the work lands. The library's (library-ui-wireframes.canvas.tsx in this project's canvases) is the example to follow.

Where

• ~/.cursor/projects/<workspace>/canvases/<feature>-wireframes.canvas.tsx: <workspace> is the Cursor project folder for this repository (list ~/.cursor/projects/ if it isn't in the environment), <feature> a short kebab-case name (library-ui-wireframes, import-wireframes).
• One canvas per feature or screen family. A workstream's board links to it, and its open questions also go on the board's Needs you (.cursor/skills/workstream-canvas/SKILL.md).
• Read ~/.cursor/skills-cursor/canvas/SKILL.md once per session before the first write: its rules apply (theme tokens only, no empty states, no gradients, emojis or shadows).

Start

1. Gather what it's drawn from: the design document, the tracker rows, the code as merged (git log), and the app it follows, if any (Lightroom Classic for the library). Note what each region's status rests on.
2. Copy template.tsx to the path above.
3. Replace the data at its top: WIREFRAMES (title, a line saying what it's drawn from and the date, the reading note), the meanings in STATUS, FLOW, PRINCIPLES and QUESTIONS. Keep the building blocks and the Overview and Questions tabs as they are.
4. Replace the example tab with one tab per area of the screen, listed in TABS between Overview and Questions.
5. Link the canvas in your reply: [Feature wireframes](/absolute/path/<feature>-wireframes.canvas.tsx).

The tabs

• Overview: the user's path through the screen as three to six numbered steps, each with its status; what makes the design work, three to six points with a title and a sentence; how to read the wireframes, the statuses and what each means; and a callout to the questions while any are open.
• One tab per area: a window, a panel set, a sheet, a flow (the library's are The window, Finding photos, Culling, Keywords and metadata, and Import, files and health). Each opens with a heading and a sentence, then the wireframe, then its notes, then what doesn't draw well: a table of keys, the tokens a field takes, the states a control goes through.
• Questions: each choice the wireframes leave open, and below them the ones answered.

Drawing a wireframe

• The real layout, in proportion. A Window with its toolbar, regions laid out on a CSS grid with the screen's real columns and widths ("170px minmax(0, 1fr) 230px"). Draw what the user sees, not the code's structure.
• Every region a Box: a number (n), a short label and a status. The notes under the wireframe use the same numbers: what the region does and why, the tracker ID or decision it comes from (LIB-27, DEC-48), and its status. A wireframe with more than about ten regions splits into two.
• Real content. Real labels, menu names, keys (Kbd), templates and values, and plausible counts, saying once in the reading note that counts are made up. No placeholder text, no "TBD" box: a region not yet designed isn't drawn, it's a question.
• Dashed boxes for what shows on demand: a sheet, a popover, a panel opened from a menu.
• The building blocks: Box, Window, ListSection (a sidebar's rows with counts), Tile (a cell of content), Field (a labelled value), Segmented, Chip, Kbd, Slider, Mini, Caption, Notes, StatusTag. Add a block the screen needs (a domain's cell, such as the library's photo with stars and flags) beside them, in the same style.
• A playground where a behaviour is easier to feel than to read: the library's query bar narrows a made-up million photos as terms are clicked. Keep it self-contained (useState, data inline) and say it's illustrative.