CI Mockup Figure

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