design-directions

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

1. 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.
2. 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.
3. 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"
4. 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".
5. 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.
6. Present for reaction: screenshot each direction and embed the images in your reply (fall back to open design-directions/*.html if you cannot render), and ask what to keep and what to kill. Then iterate on the chosen direction, or combine elements on request.