GreatMark Design Directions
The user has "unknown knowns": criteria they can only articulate when they see something. Give them things to react to, cheaply, before touching real code.
Workflow
- Confirm scope from context: what surface is being designed (page, panel, component, report) and what data it shows. Do not ask more than one clarifying question; guessing reasonably is part of the point. If it turns out the user wants a technical feasibility spike, say this skill does not apply and build the spike instead.
- Build 4 deliberately different directions by default (fewer only if the user asks; at one direction this skill's divergence machinery is moot — say so, and either just build it or propose a second contrasting take). Different means different layout philosophy, density, hierarchy, or interaction model — not one design with four color schemes. Before building, put all directions on one shared set of axes (layout philosophy, density, hierarchy, interaction model) and state each direction's position on them; every pair of directions must sit at opposite ends of at least one axis.
- Deliver as self-contained HTML: inline CSS/JS, realistic fake data
hardcoded inline (in the language of the conversation), no build step,
no network calls. Aim for high-fidelity visuals — the user should react
to the design, not the sketchiness; static is fine, and add only the
minimum JS that makes the core loop legible (e.g. a ticking timer for a
timer app). When interaction itself is the core loop (charts, drag,
filtering), prefer rendering one frozen mid-interaction moment (tooltip
already open, panel mid-drag) over scripting it; script only what a
static frame cannot convey. Include a viewport meta; default to desktop
web unless the surface is obviously mobile — then wrap in a phone-width
(390px) frame. For non-web surfaces (CLI/TUI, email, native), still
deliver HTML but simulate the medium honestly — monospace grid and
16-color palette for a terminal — and never show an effect the real
medium cannot render. Default to one file per direction (a single file
with a direction switcher only if the user asks). Write files to a
scratch directory under the project root (
./design-directions/; in a non-project directory, confirm where to put them first), never into the real app; do not commit them. In a git repo, exclude the directory:n=design-directions/; p="$(git rev-parse --git-path info/exclude 2>/dev/null)" && { mkdir -p "$(dirname "$p")" && { grep -qxF "$n" "$p" || echo "$n" >> "$p"; }; } 2>/dev/null || echo "note: could not exclude — leaving it untracked, never staging it" - Name each direction with a short memorable label and one sentence on the idea behind it, so the user can say "the second one, but denser".
- Self-check before showing: render each file (headless browser or screenshot tool if available) and verify it holds up at the target viewport — no layout breakage, all fake data visible, no console errors. Then the divergence gate: if the screenshots shown side by side would read as tweaks of one design, rebuild the weakest until they don't. If no renderer is available, downgrade explicitly: run static checks (tags balanced, inline JS parses, no external URLs, viewport meta present) and tell the user the files are unrendered — ask them to report any breakage on first open. Fix what you find before presenting; a broken first render defeats the purpose.
- Present for reaction: screenshot each direction and embed the images in
your reply (fall back to
open design-directions/*.htmlif you cannot render), and ask what to keep and what to kill. Then iterate on the chosen direction, or combine elements on request.
Rules
- Do not modify application code, add dependencies, or wire up backends at this stage.
- Use realistic fake data (plausible names, numbers, edge-case lengths) — lorem ipsum hides layout problems.
- If the project has an established design system, keep its tokens and branding; diverge on layout, density, and information architecture instead.
- Do not build these prototypes as Cursor canvases: canvas locks a single flat visual style and only works in Cursor.
- Push at least one direction beyond the user's stated taste; the point is to discover what they didn't know they wanted. Under an established design system this rule stays inside the tokens: push on structure and information architecture, not on brand.
Examples
Four directions for a pomodoro timer:
- Monolith — one giant timer, fullscreen, nothing else on screen.
- Workbench — three-pane workspace: task list, timer, session stats.
- Garden — playful narrative: each finished session grows a plant.
- Ticker — data-dense terminal: streaks, logs, and stats in a grid.