SuperAPI AI Directory
Partner中文AI newsFavorites
Skillshtml-line-svg

html-line-svg

Design & creation

View repository

Updated 10-16 08:40

About this skill

HTML semantic box-and-line SVG

Recode the objects, relationships, states, and reading order in the original content into a restrained technical-documentation-style box-and-line diagram. First ensure the diagram accurately restates the instructional judgment, then handle composition and SVG details; do not mechanically trace the original illustration into vector outlines. With each delivery, also generate a self-contained wireframe prompt so that the same semantic design can be reused, reviewed, and further iterated.

Before starting

  1. Read the target content, adjacent content, existing images or sketches, the HTML/CSS that hosts it, and the available space.
  2. When working in course-design , read the root directory AGENTS.md、docs/design/STYLE_DNA.md, the design tokens used by the target page, and the more specific directory conventions.
  3. When invoked by another skill, return to the upper-level workflow that invoked it: follow the source of truth, source files, asset registration, traceability records, generated artifacts, and verification scope specified by the upper-level skill, and do not be fixedly bound to tailor-html-to-slide、ppt-like-html or any single carrier. When invoked independently, follow the rules of the target project and the directory containing the target file.
  4. Protect the original conclusions, conceptual boundaries, directions, states, and quantities. Do not draw relationships as arrows when they cannot be confirmed from the materials.

Workflow

1. Write the semantic specification and optional Mermaid relationship structure

Write a minimal specification before drawing; it may be placed in working notes and is not required to become final page text.

teaching_claim: 这张图必须让读者看懂的一个判断
objects:
  - id: object-a
    label: 对象名称
    role: interface | agent | task | container | document | state
relations:
  - from: object-a
    to: object-b
    type: flow | dispatch | claim | sync | association | compare | contains
    direction: forward | bidirectional | none
    path: primary | alternative
    payload: 可选；仅在理解交接物时填写
states:
  - target: object-b
    type: added-later | waiting | incomplete | fading | persistent | warning | blocked
visible_labels:
  - text: 对读者可见的文字
    role: group-title | object-label | relation-label | caption
layout_constraints:
  peer_alignment: visual-center-y | top | baseline | none
  alignment_tolerance: "0.5% of viewBox height"
  minimum_safe_gap: "2% of viewBox width"
  containment_label_zone: top | side | none
reading_order: left-to-right | top-to-bottom | center-out | board-to-peers

Keep only information that supports teaching_claim . Names, quantities, arrow directions, and solid or dashed lines must all have a semantic justification that can be found in the specification.path Distinguish main flows from non-main flows;payload Fill this in only when the relationship cannot be understood without stating the handoff artifact; do not force an artifact for every arrow.visible_labels Use this to detect duplicate text across adjacent levels in advance;layout_constraints Write relative constraints, not coordinates that apply only to one specific diagram.

When the diagram is primarily about node relationships, prefer adding a Mermaid section before or after the YAML, treating it as an executable, previewablerelationship structure specification. System architecture, processes, agent collaboration, state transitions, sequence interactions, class relationships, and entity relationships are usually suitable; GUI page wireframes, purely visual comparisons, and illustrations that are difficult to abstract into node relationships may omit it. When choosing syntax and style, refer to the official Mermaid diagram syntax documentation, and navigate from that page to the corresponding diagram types such as Flowchart, Architecture, Sequence, State, Class, and Entity Relationship.

The Mermaid specification follows these requirements:

  • Use stable, readable node IDs; write text that must be displayed as explicit labels.
  • Clearly write groupings, relationship verbs, arrow directions, and confirmable states; do not add connections that have no basis in the materials.
  • Choose the smallest diagram type that can express the semantics; do not add node shapes, colors, or relationships just to demonstrate Mermaid features.
  • Treat Mermaid nodes, groupings, and edges as the semantic basis; do not treat automatic layout, polyline paths, coordinates, or default styles as the final design.
  • Mermaid cannot replace teaching_claim, object roles, state ambiguity notes, visible labels, layout constraints, reading order, and narrow-screen behavior; still use YAML or text adjacent to Mermaid to supply this information.

Example:

flowchart TB
    scheduler["调度器"]
    subgraph agents["执行层"]
        agent_a["Agent A"]
        agent_b["Agent B"]
    end
    scheduler -->|派发| agent_a
    scheduler -->|派发| agent_b

When converting Mermaid to SVG, preserve node identity, group boundaries, relationship verbs, direction, and reading order; recompose according to the real page space, and do not mechanically replicate the Mermaid rendering result. If Mermaid is used, the subsequent wireframe generation prompt must include the final Mermaid code used or an equivalent complete relationship description.

2. Generate wireframe prompt

Draft a self-contained "wireframe generation prompt" based on the semantic specification, and revise it to match the final implementation after the SVG has been verified. The prompt is not a summary of the work process, nor an atmospheric description for a bitmap model; it should enable another implementer with HTML/SVG capabilities to reconstruct a semantically consistent wireframe without seeing the current conversation or the finished product.

The prompt must cover:

  1. Task and teaching conclusion: state that an HTML semantic wireframe SVG is to be generated, and one core judgment that the reader must understand.
  2. Objects and visible text: list objects, roles, groups, quantities, and labels that need to be displayed as-is.
  3. Relationships, direction, and state: explain item by item who connects to whom, relationship verbs, arrow direction, line styles, and special states; do not write relationships without basis into the prompt.
  4. Layout and reading order: explain the composition type, grouping method, shared anchors, reading direction, target canvas or applicable viewport behavior, and safe spacing. Unless the exact coordinates themselves have reproduction value, use relative constraints and do not hard-code debugging coordinates.
  5. Visual grammar: specify the semantic use of colors, the meaning of solid and dashed lines, fonts, corner radii, and prohibited effects.
  6. SVG technical constraints: require viewBox, semantic grouping, text preserved as <text>, unique IDs,vector-effect、<title>、<desc> and aria-labelledby。
  7. Acceptance and output: require checking semantics, structure, geometry, visuals, target canvas or applicable viewport, and accessibility, and output a complete editable SVG, not a bitmap or only an explanation.

When using Mermaid, include the final Mermaid relationship structure in "Relationships, direction, and state", then supplement the roles, state meanings, and layout constraints that Mermaid cannot express; do not write Mermaid's automatically generated styles or coordinates as requirements that the SVG must copy.

Write the prompt in the same primary language as the user; keep code names, fields, and commands in their original form. The prompt should reference actual content, rather than retaining [对象名称] and similar unfilled placeholders. Do not include temporary file paths, debugging processes, unconfirmable relationships, or old designs inconsistent with the final SVG.

The prompt uses the following fixed structure:

# 线框图生成提示词

请根据以下规格生成一张可访问、响应式、可编辑的 HTML 语义框线 SVG。

## 任务与教学结论
[填写图的用途和唯一核心判断]

## 对象与可见文字
[填写对象、角色、分组、数量和必须出现的标签]

## 关系、方向与状态
[逐条填写关系、动词、方向、线型和状态]

## 布局与阅读顺序
[填写构图、对齐、分隔、安全距离、阅读方向和目标画布或适用视口行为]

## 视觉语法
[填写颜色语义、线框、字体、圆角和禁止项]

## SVG 技术约束
[填写结构、响应式、ID、文本、描边和无障碍要求]

## 验收与输出
[填写验证要求，并要求输出完整 SVG]

3. Choose relationship grammar and minimal diagram type

First determine the connection method by semantics, then choose the composition. Arrows only indicate directions that the material can confirm, and are not default connectors.

Relationship Diagram grammar
Flow, dispatch, claim, and invocation in the main process Blue solid one-way arrow; direction matches the verb
Non-main process, alternative paths, optional starting points, or jumps Blue dashed one-way arrow; use relationship labels to explain the specific meaning
Bidirectional synchronization Blue bidirectional arrow
Undirected association, pairing, contact Black solid line, no marker
Containment, still existing within a certain scope Inner and outer nested boxes, no arrows drawn; the outer label occupies an independent safe area
Parallel evidence, three cases, peer objects Groups aligned at the same scale and anchor point, not connected to each other
State change Keep object positions as fixed as possible, change line style or state labels; add arrows only for explicit temporal or transfer relationships
  • Comparison: two same-scale containers placed side by side, highlighting only the relationship or state that has changed.
  • Hierarchy or dispatch: upstream objects at the top, downstream objects arranged horizontally, arrows flowing in a single direction.
  • Handoff item: only when a task, data, document, or artifact is essential to understanding the relationship, place it as a relationship label near the arrow; do not label it when unnecessary. When the label is far from the arrow, draw an orange arrowless indicator line from the midpoint of the arrow line, and do not let readers mistake it for a new flow.
  • Shared environment and autonomous collaboration: the environment or board occupies one side, peer participants occupy the other side, and relationships are labeled with verbs such as "claim".
  • Dual human-computer interfaces: GUI uses page wireframes, LUI uses machine-readable fields; supplementary construction uses one-way relationships, synchronous design uses bidirectional relationships.

If a diagram requires multiple crossing lines, more than three levels of nesting, or a large amount of explanatory text, first split the diagram, switch to numbered steps, or remove non-core information.

4. Organize labels and layout contracts

  • Take inventory of card titles, group titles, object labels, relationship labels, and captions. When adjacent levels express the same information, keep only one instance; if an in-diagram subtitle merely restates a card or group title, delete it directly.
  • For three or more groups of peer diagrams, first determine a common anchor point. When object sizes differ, prioritize aligning visual centers; ancillary text such as titles and corner marks should not be used as the alignment baseline for the main subject.
  • First define the boundaries and divider safe areas for each group, then place objects and connections. Object frames, text, and markers must not press against dividers or adjacent groups.
  • For containment relationships, first expand the outer frame, then reserve an independent area and inner padding for the outer label; inner and outer labels and frame lines must not overlap.
  • Use relative tolerances and safe distances; auxiliary lines or boundary measurements may be added during debugging, and auxiliary elements must be removed before acceptance.

5. Apply the visual grammar

Follow docs/design/STYLE_DNA.md: pure white, minimal, whitespace, restrained, technical documentation feel.

  • White #FFFFFF: canvas and object interiors.
  • Black #0A0A0A: object frame lines, primary text.
  • Dark gray #171717: secondary body text; medium gray #737373: labels, relationship verbs.
  • Light gray #E5E5E5: dividers, outer auxiliary boundaries.
  • Blue #0348ED: used only for relationships such as direction, links, claiming, dispatch, and synchronization; do not use it as ordinary explanatory text or for large-area object fills.
  • Orange #FE7E0F: warnings such as tips, task corner marks, and not-yet-mature items, as well as arrowless indicator lines pointing from the main relationship line to a distant handoff item label.
  • Red #FF3700: obstacles, conflicts, errors, or gaps; do not use it when there is no negative semantics.
  • Solid frame: an object that already exists, is available, and is definite.
  • Dashed box: later-added, pending, incomplete, fading, or candidate status; ambiguity must be resolved by text or context.
  • Monospace:name、desc, parameters, commands, and other machine-readable fields.
  • Keep corner radius slight, usually rx="2" to 8; do not make pill-shaped cards.
  • Establish a line-width hierarchy: primary relationship lines and arrows are the clearest, object box lines come next, and handoff-item indicator lines may be slightly thinner but must not become hairline strokes. Do not mechanically apply thin default values; confirm that lines are clearly legible at the actual delivery size.

Never add gradients, shadows, filters, textures, noise, complex backgrounds, 3D, tech-style UI, decorative icons, or semantically meaningless connectors. Do not pursue "cute," "bizarre," or "poster-like" aesthetics.

6. Construct the SVG

  1. Use a stable viewBox coordinate system, preferably starting from 0 0 600 250 and then adjusting according to the content.
  2. Use <g> to group by object, relationship, and state; use <rect>、<line>、<path>、<text>、<tspan> and <marker>. When geometric acceptance is needed, you may add semantic attributes such as data-align-group、data-boundary、data-relation .
  3. Keep text as SVG text; do not convert text to paths, and do not use <foreignObject>。
  4. Add to each diagram role="img"、aria-labelledby, <title> with a unique ID, and <desc>。desc must describe the objects, relationships, direction, and special states, not merely repeat the title.
  5. Within the same HTML document, all id must be unique, especially arrow markers. Use the page or component ID as a prefix, for example s07-native-arrow-end。
  6. For lines, use vector-effect: non-scaling-stroke; arrows and relationship lines use the same semantic color. Handoff-item indicator lines use orange, have no marker, and are grouped with the primary relationship lines.
  7. Let HTML/CSS handle dimensions, fonts, and token mapping, and let SVG handle structure. When a standalone SVG file is needed, you may embed a minimal <style> and reuse the same token values.

For implementation patterns, CSS containers, and accessibility templates, see references/implementation-patterns.md。

7. Embed into HTML and adapt to the target canvas

  • Set the outer container to width: 100%、min-width: 0, moderate padding, and overflow: hidden。
  • Set the SVG to display: block; width: 100%; height: auto;, and use max-height to control the visual weight within the card.
  • Inherit canvas and viewport requirements from the upper-level skill that calls it. Fixed-size HTML Presentation or PPT-style carriers only verify the target presentation size; course pages or responsive web pages that need narrow screens should maintain the same reading order after stacking and must not rely on arrow positions that only work on desktop.
  • Avoid small font sizes and long sentences. Labels should preferably use 2–6 characters; when line breaks are needed, use <tspan x="…" dy="…"> for explicit control.
  • Do not use fixed SVG pixel width and height as a substitute for responsive CSS.

8. Generate a PNG preview

  • After completing the SVG and passing the structural check, generate by default a PNG with the same content as a formal deliverable that can be viewed directly, shared, and inserted into carriers that do not support SVG; omit it only when the user explicitly requests omission.
  • When creating a standalone SVG file, save the PNG in the same directory with the same basename as <basename>.preview.png. When modifying HTML directly, name the preview image after the target component or page, and state the corresponding relationship in the delivery summary.
  • Use Chromium, Chrome, or an equivalent standard browser rendering engine, on a white background, at the SVG's original viewBox Rasterize the aspect ratio and target delivery size; fixed canvases are output at the target pixel dimensions, and responsive pages are output at the representative viewport specified by the parent skill.
  • It is forbidden to use macOS Quick Look, file manager thumbnails, or other thumbnail pipelines that incorrectly scale vector-effect: non-scaling-stroke, markers, fonts, or dashed lines to generate the official PNG.
  • When the page depends on web fonts, external CSS, or scripts, wait for resources and layout to stabilize before taking the screenshot. The PNG must not change the SVG's aspect ratio through secondary stretching, compression, or cropping.
  • After generation, verify the PNG pixel dimensions and inspect it side by side with the SVG in the browser: node positions, text wrapping, line-width hierarchy, dash rhythm, arrow sizes, and color semantics should be visually consistent. If they are inconsistent, fix the rendering pipeline or the SVG, then regenerate the PNG; do not use a distorted PNG as a deliverable.

9. Verification

Check in sequence:

  1. Semantics: Does the diagram accurately express teaching_claim; check the relationship grammar item by item, confirming that arrows, dashed lines, and colors are all justified, and that there are no adjacent duplicate labels.
    • When using Mermaid, first preview or run a syntax check in an available Mermaid renderer, then check the nodes, groups, relationship verbs, and direction of the Mermaid and the final SVG item by item; if rendering cannot be performed, clearly record that it was not checked.
  2. Structure: Run node <html-line-svg-skill-dir>/scripts/validate-line-svg.mjs <svg-or-html> [...], where <html-line-svg-skill-dir> is the actual installation directory of this skill; do not assume that a local copy exists in the project. This script checks the SVG structure and does not replace geometric acceptance.
  3. Geometry: On the real canvas or viewport required by the parent skill, measure the alignment deviation of peer-level subjects, the safe distance from objects to divider lines, the containment relationships of nested boxes, and collisions between text, box lines, and connectors; also check viewBox cropping and overflow. This item is mandatory when there are three or more groups of peer-level objects, divider lines, or nested boxes. Fixed-size Presentation or PPT-style carriers measure only the target presentation size; only responsive web pages check desktop and narrow-screen viewports.
  4. Visual: View a real page screenshot of the target canvas or applicable viewport, and inspect it side by side with the official PNG preview to confirm that the reading order, visual center of gravity, and whitespace are stable, and do not ignore edge-hugging or imbalance just because there is technically "no intersection"; also confirm that main lines, dashed lines, box lines, and indicator lines have a clear hierarchy at the real delivery size, without being too thin, sticking together, or becoming abnormally thicker due to rasterization.
  5. Connector traceability: At the real delivery size, trace each relationship from its starting point to the arrow endpoint, confirming that every relationship has a unique, continuous visual path that requires no guessing. The line tail should clearly leave the source object boundary, and the arrow should clearly land on the target object boundary; unless there is a semantically clear merge or split node, multiple relationships are forbidden from sharing the same line segment over long distances. If coaxial overlap, path sticking, inability to determine direction after crossing, connectors blocked by objects or text, or arrows disconnected from their targets occur, directly judge it as unqualified. Prioritize reassigning connection ports, separating parallel paths, reducing crossings, or splitting the diagram; when long-distance return flows, cross-layer jumps, or dense polylines are still hard to trace, switch to smooth quadratic or cubic Bezier curve arrows. Curves must maintain a single direction, not pass through unrelated objects or text, and must not create new crossing ambiguity; if it cannot be resolved within the target canvas, continue splitting the diagram rather than reluctantly keeping a complex network.
  6. Accessibility: Confirm that <title>、<desc> corresponds to aria-labelledby , and that the main text can be understood even without looking at the diagram.
  7. Prompt consistency: Compare the final SVG against the prompt item by item, confirming that objects, text, relationships, layout, color semantics, and output requirements are consistent; approaches abandoned during implementation must not remain in the prompt.
  8. PNG: Confirm that the PNG's pixel dimensions and aspect ratio match the target canvas, and that nodes, text, lines, markers, dashed lines, and colors are visually consistent with the browser-rendered SVG.
  9. Integration: Run the target project's existing build and validation commands; do not validate only an isolated SVG.

Standard output

Each time this skill is used, deliver the following five items by default; reduce them only when the user explicitly requests omission:

  1. SVG deliverable: A complete inline SVG, modifications to the target HTML, or a standalone .svg file.
  2. PNG preview: The .preview.pngrendered by a standard browser from the final SVG at the target delivery size; do not use thumbnail tools that would distort strokes or markers.
  3. Wireframe generation prompt: Fill it in according to the fixed structure in Step 2; the content must be consistent with the final SVG and independently reusable.
  4. Delivery summary: Use brief text to explain the diagram type, core objects, key relationships, and special states.
  5. Validation results: Explain the results of structure, geometry, visual, PNG consistency, connection traceability, target canvas or applicable viewport, accessibility, and project integration checks; checks that were not performed must be clearly marked.

When using Mermaid, also deliver a copyable Mermaid relationship structure specification; it may be placed in the "Relationships, Direction, and States" section of the wireframe generation prompt, and a separate file is not required. Mermaid serves only as an intermediate semantic asset; SVG remains the final graphic deliverable.

When creating a standalone file, save the prompt with the same name as the SVG as <basename>.prompt.md, for example:

agent-collaboration.svg
agent-collaboration.preview.png
agent-collaboration.prompt.md

When directly modifying HTML or returning an inline SVG in the conversation, output the complete prompt in a separate Markdown code block in the delivery information. Do not hide the prompt only in working notes, SVG comments, or <desc> .

Reuse examples

When you need to choose a composition, compare visual semantics, or copy a starting structure, read references/example-catalog.md, and view the four independently openable SVGs in assets/examples/ :

  • centralized-agent-dispatch.svg
  • distributed-agent-claim.svg
  • gui-lui-retrofit.svg
  • gui-lui-native.svg

After copying an example, you must rewrite the title, description, IDs, text, quantities, and relationships; examples are visual grammar, not content templates.

Completion criteria

  • The teaching judgment of the diagram can be restated in one sentence.
  • The standard output includes a wireframe generation prompt that is consistent with the final diagram, contains no unfilled placeholders, and can be used independently of the current conversation.
  • Every object, relationship, state, and accent color has a clear semantic meaning.
  • When using Mermaid, its nodes, groups, relationship verbs, and direction are consistent with the final SVG, and the final composition does not mechanically copy Mermaid's automatic layout.
  • Adjacent levels have no duplicate labels; blue expresses only genuine direction or link semantics.
  • The SVG can be inlined, scaled, and made accessible, and IDs within the document do not conflict.
  • By default, generate a PNG preview that is visually consistent with the final SVG and has explicit dimensions; the PNG must not be stretched or cropped a second time, and line widths, arrows, dashed lines, fonts, and colors must not be distorted by rasterization.
  • Subjects at the same level are aligned and maintain a safe distance from divider lines; labels, boundaries, and content of nested boxes do not collide.
  • Every directed relationship can be traced continuously from the source object to the target object at the actual delivery size; there are no collinear, overlapping, or crossing paths whose destination must be guessed, and complex backflows have had ambiguity eliminated through rerouting, curved arrows, or diagram splitting.
  • There is no overflow, clipping, or unreadable text on either the target canvas specified by the upper-level skill or the applicable viewports.
  • The style remains pure white, with few colors, clear line-width hierarchy, and no shadows, and does not distract from the body text.
  • When modifying existing courseware, the source files, traceability files, generated artifacts, and verification results remain consistent.