# Artifact Flow > OUTPUT IS ALWAYS A SINGLE `.html` FILE (never `.md`, never separate per-screen files) containing multiple screens navigated by clickable hotspots and/or a hash router. Use this skill whenever the user asks for a clickable prototype, clickable mockup, multi-screen flow, user-flow walkthrough, "click-through demo", "tap-through prototype", interactive wireframe, or any artifact whose primary shape is "a sequence of screens linked by hotspots". Pair with `artifact-css` for the underlying design system. Do NOT use for slide decks (use `artifact-deck`) or for fully-functional editors (use `artifact-editor`). - Skill: `olakunlevpn/artifact-flow` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add olakunlevpn/artifact-flow` - Raw SKILL.md: https://api.skillmd.com/api/skills/olakunlevpn/artifact-flow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: olakunlevpn (https://skillmd.com/u/olakunlevpn) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/olakunlevpn/artifact-flow --- # artifact-flow > ## OUTPUT CONTRACT > > **Produces ONE `.html` file.** A clickable flow has many screens. ALL of them live in the same file, switched by JavaScript (clicks on hotspots, hash routing). NEVER one HTML per screen. > > File extension is `.html`. File name typically `-prototype.html`. --- A clickable, hotspot-driven prototype. The reader experiences a multi-screen user flow by clicking marked targets on each screen. Useful for walking stakeholders through a feature before it's built, or for capturing a UX path in a single shareable file. Read `artifact-css/SKILL.md` first for the OUTPUT CONTRACT, the design tokens, and the class vocabulary. This skill uses **vanilla JS only** — no jQuery required. ## When to reach for this skill - User says "make me a clickable mockup of X", "wireframe the signup flow", "show me what the multi-step migration UI would look like". - User wants a stakeholder to *feel* the flow without engineering it. - User wants a single-file deliverable that captures an end-to-end UX path. If they want one screen per slide for a presentation, use `artifact-deck`. If they want a fully working editor with state, use `artifact-editor`. ## Anatomy of a flow Four element types. 1. **Flow chrome** — fixed top bar with: flow title, current screen N / total, breadcrumb of screen names. Optional "Reset to start" button. 2. **Screen** — a `
`. Only the active screen is visible. Each screen is a mocked-up page (header, body, ghost CTAs, fake data — whatever the real UI would show). 3. **Hotspots** — clickable regions overlaid on screen elements. Each carries a `data-go=""` attribute pointing to the next screen. Hotspots can be visible (subtle pulsing ring) or invisible (full-bleed transparent layer over a button). 4. **Annotations** — optional small numbered callouts on the side of the canvas explaining what's happening on this screen. Toggleable via "Notes on / off". Five to ten screens is the right zone. More = wireframe inflation. Fewer = doesn't justify the format. ## Hotspot styles Three patterns. Pick per screen. | Pattern | When | |---|---| | **Full-bleed** — invisible div covering an entire CTA / button | Most natural — user clicks where they'd click in the real UI | | **Ringed** — a subtle dashed outline over the active region, pulsing | First-time flows where the user needs to be told where to click | | **Visible button** — labelled `.button` that says "Continue" / "Next" | When mocking happy-path narration over a complex screen | Avoid mixing patterns within one screen. Pick one per screen. ## Navigation contract - **Click on a hotspot** — go to the screen it points to. - **Back button in chrome** — return to previous screen in history. - **Hash routing** — `#scr-` jumps to a named screen. Shareable. - **Reset** — return to first screen, clear history stack. - **N or →** — advance to "primary next" hotspot (the one marked `data-primary`). - **B or ←** — go back. ## Fallback contract With JS disabled: - All screens render stacked top-to-bottom. - Each screen is labelled with an `h2` header so the reader can tell what's what. - Hotspots render as visible `` anchors linking to `#scr-` — still navigable via in-page anchors. ## Voice and density rules 1. **Real-looking data.** Fake screens with `Lorem ipsum` look like a wireframe. Fake screens with plausible names, plausible numbers, plausible copy look like a real preview. Use the second. 2. **One primary action per screen.** Even if the real UI has six buttons, the flow walks a happy-path. Other buttons render as `.muted` ghosts that don't react. 3. **Don't fake what the next screen looks like.** If clicking "Save" in the real UI would show a toast and stay on the page, then in the flow clicking "Save" should also stay (with a faked toast), not navigate to a new screen. 4. **Annotate sparingly.** Annotations are for capturing the *why* of a screen, not the *what*. 5. **The closing screen exists.** Every flow ends. The last screen has a "Flow complete" callout + a "Restart" button. ## Common mistakes - **Hotspots that go nowhere.** If `data-go` references a screen ID that doesn't exist, clicking the hotspot is silently broken. Always lint the IDs. - **Sequential numbering only.** Real UX is a tree, not a chain. Use named screen keys (`scr-cart`, `scr-checkout`, `scr-confirm`) — not `scr-1`, `scr-2`, `scr-3`. - **Wireframe greyboxes.** A flow is supposed to *feel* real. Use the actual artifact.css palette and components. Don't go grey-on-grey unless that's literally the brand. - **No back button.** A flow without back is a presentation. The whole point is interactivity. ## After the artifact Offer two derivatives: 1. A flat screen map (text outline) listing all screens and their primary outgoing hotspots. Useful for a PR description. 2. A list of suggested next steps if this prototype were greenlit (what to build first, what's risky, what's unknown).