/ci-mockup-figure

name: ci-mockup-figure
description: Create paper and proposal figures guided by confirmed visual preferences and efficient use of page space. HTML mockups for systems, dashboards, and timelines; TikZ or skia-canvas for abstract diagrams with arrow routing. Covers tool selection, design, capture, and LaTeX insertion.

CI Mockup Figure

Overview

For Yue Zhao's paper and proposal figures, understanding and imitating the confirmed gallery references is the top design priority. Before layout or styling, resolve `editable-figure` and follow its `references/gallery/index.md#required-preference-first-design`. Inspect images and feedback, state the reference-to-design mapping, implement it, and compare the rendered output against those images. Revise unmet preference requirements before delivery. Current task instructions, scientific correctness, required output constraints, and an established document palette or figure-series identity govern; generic density, color, and icon defaults below must yield to confirmed preferences. For another user, use that user's confirmed preferences.

The goal is **space-efficient, information-dense figures** that communicate a system's design, a method's pipeline, or an architectural flowchart in minimal page area. Three paths depending on figure type:

• **HTML mockup path** (Phases 1-4 below): for UI mockups, dashboards,

timelines, and any figure where content is rectangular with no cross-node arrows. Build interactive HTML, capture screenshots, insert into LaTeX.

• **README / Markdown hero path** (README / Markdown Target section): same

HTML build phase, but capture via headless Chrome to a PNG and embed it as a Markdown image referencing `assets/fig.png`. Requires larger type, higher content density, and one dominant focal element -- the viewer scales the image down to column width.

• **Abstract figure path** (Abstract Figure Toolchain section): for

architecture overviews, dependency topologies, and any figure needing arrow routing between non-adjacent nodes. Use TikZ, skia-canvas, or Illustrator ExtendScript.

Every figure must pass the space test: does this figure communicate more per square inch than the text it displaces? If a full-width figure takes half a page but only says "A → B → C → D", it fails. A wrapfigure showing an interactive prototype with search results, graph nodes, and real data labels passes because it communicates system design, data model, and UX simultaneously.

This skill works for any document where figures need to communicate design or methodology credibly: research papers (method overview, architecture diagrams, pipeline flowcharts), proposals (NSF, NIH, DOE, etc.), technical reports, or demo writeups. It is especially effective when the figure needs to show multi-component structure, data flow, or step-by-step methodology and reviewers evaluate whether the design is credible and well-conceived.

For paper and proposal explanatory figures, especially overviews and Figure 1, resolve `editable-figure` through the normal skill lookup and read its `references/gallery/index.md` and relevant images and feedback. Apply selected preference dimensions in the design brief and implementation, preserving meaningful technical detail and domain imagery when liked. Use its durable update procedure for new feedback. For these figures, confirmed preferences override conflicting defaults below for the affected dimension. This includes the pre-flight color rule, light-tint fills, minimal panel elements, and low-opacity or desaturated domain imagery. Preserve the requested HTML, TikZ, or other output format.

HTML mockups vs TikZ/LaTeX diagrams

HTML and TikZ each have a clear strength. The deciding factor is **whether the figure needs arrow routing between non-adjacent nodes**.

| | HTML mockup | TikZ | |---|---|---| | Visual polish | Modern CSS, shadows, gradients, rounded cards | Flat, academic-looking boxes | | Iteration speed | Change CSS and refresh | Recompile LaTeX, debug positioning | | Layout control | Flexbox/grid, responsive | Manual coordinate math | | Color/font variety | Full CSS + web fonts | Limited, verbose color defs | | Interactivity | View switching, capture mode | Static only | | **Arrow routing** | **Breaks on cross-row/non-adjacent nodes** | **Node anchoring solves this natively** | | Font matching | Separate from LaTeX | Perfect match with document body |

**Prefer HTML** for system mockups, dashboards, Gantt/timeline figures, and any figure where the content is inherently rectangular and flows naturally (no cross-node arrows needed).

**Prefer TikZ** for abstract framework diagrams, dependency topologies, and architecture overviews where arrows must route between non-adjacent nodes (L-shaped, curved, crossing rows). TikZ node anchoring (`node.south`, `node.east`) handles this natively. Also prefer TikZ for small inline diagrams that must live inside the LaTeX source or when exact font matching is critical.

**Prefer skia-canvas** (Node.js) when you need the arrow-routing control of TikZ but want faster iteration (edit `.mjs`, run, get PDF) and richer visual styling than TikZ provides.

HTML mockups vs AI image generation

HTML mockups are strictly better than AI-generated images for system and method figures. AI image generation is acceptable only for artistic/conceptual overview diagrams.

| | HTML mockup | AI image generation | |---|---|---| | Text legibility | Pixel-perfect, real fonts | Often garbled or blurry | | Data accuracy | Every number/label controlled | Hallucinated values | | Iteration speed | Change CSS and refresh | Re-prompt and hope | | Consistency | Same palette across figures | Each generation varies | | Print quality | Vector PDF via browser print | Always raster | | Reviewer trust | Looks like a system you could build | Looks like a concept sketch |

HTML mockups vs PowerPoint (for timelines)

HTML is also better than PPTX for Gantt/timeline figures:

| | HTML | P