HTML Semantic Wireframe SVG

Recode the objects, relationships, states, and reading order from the original content into restrained technical-document-style wireframes. First ensure the diagram accurately restates teaching judgments, then handle composition and SVG details; do not mechanically trace original illustrations into vector outlines. Deliver a self-contained wireframe generation prompt alongside each output, enabling the same semantic design to be reused, reviewed, and iterated on.

Before Starting

Read the target content, adjacent content, existing images or sketches, the HTML/CSS it will be embedded in, and available space.
When working in
```
course-design
```
, read the root directory
```
AGENTS.md
```
,
```
docs/design/STYLE_DNA.md
```
, design tokens used by the target page, and more specific directory specifications.
When called by another skill, return to the upper workflow that invoked it: comply with the fact sources, source files, material registration, trace records, deliverables, and verification scope specified by the upper skill; do not fixate on binding to
```
tailor-html-to-slide
```
,
```
ppt-like-html
```
, or any single carrier. When called independently, follow the rules of the target project and the directory where the target file is located.
Protect original conclusions, conceptual boundaries, directions, states, and quantities. Do not draw arrows for relationships that cannot be confirmed from the materials.

Workflow

1. Write Semantic Specifications and Optional Mermaid Relationship Structure

Write a minimal specification before drawing; it can be placed in work notes and does not need to become final page text.

yaml

teaching_claim: A single judgment that this diagram must make readers understand
objects:
  - id: object-a
    label: Object Name
    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: Optional; fill only when the handover object is necessary for understanding
states:
  - target: object-b
    type: added-later | waiting | incomplete | fading | persistent | warning | blocked
visible_labels:
  - text: Text visible to readers
    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

Only retain information that supports the

teaching_claim

. Names, quantities, arrow directions, solid or dashed lines must all have semantic justifications in the specification.

path

distinguishes main processes from non-main processes;

payload

is only filled when the handover object is essential to understanding the relationship, do not forcefully add products to every arrow.

visible_labels

are used to identify duplicate text in adjacent levels in advance;

layout_constraints

write relative constraints, not coordinates that only apply to a single diagram.

When the diagram focuses on node relationships, prioritize adding a Mermaid snippet before or after the YAML as an executable, previewable relationship structure specification. System architectures, flows, Agent collaborations, state transitions, sequence interactions, class relationships, and entity relationships are usually suitable; GUI wireframes, pure visual comparisons, and illustrations that are difficult to abstract into node relationships can omit this. Refer to the Mermaid Official Chart Syntax Documentation when selecting syntax and writing methods, and navigate to corresponding diagram types such as Flowchart, Architecture, Sequence, State, Class, Entity Relationship from that page.

Mermaid specifications follow 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 without basis from materials.
Choose the minimal diagram type that can express semantics, do not add node shapes, colors, or relationships just to showcase Mermaid features.
Treat Mermaid nodes, groups, and edges as semantic references, do not treat automatic layouts, broken paths, coordinates, or default styles as final designs.
Mermaid cannot replace
```
teaching_claim
```
, object roles, state ambiguity explanations, visible labels, layout constraints, reading order, and narrow-screen behavior; still supplement this information with YAML or text adjacent to Mermaid.

Example:

mermaid

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, retain node identities, grouping boundaries, relationship verbs, directions, and reading order; re-compose the diagram based on actual page space, do not mechanically replicate Mermaid rendering results. If Mermaid is used, the subsequent wireframe generation prompt must include the final adopted Mermaid code or equivalent complete relationship description.

2. Generate Wireframe Generation Prompt

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

The prompt must cover:

Task and Teaching Conclusion: Explain that an HTML semantic wireframe SVG needs to be generated, and the core judgment that readers must understand.
Objects and Visible Text: List objects, roles, groupings, quantities, and labels that need to be displayed exactly as is.
Relationships, Directions, and States: Describe who connects to whom, relationship verbs, arrow directions, line types, and special states item by item; do not write relationships without basis into the prompt.
Layout and Reading Order: Explain the composition type, grouping method, common anchor points, reading direction, target canvas or applicable viewport behavior, and safe spacing. Use relative constraints unless precise coordinates themselves have reproduction value, do not solidify debug coordinates.
Visual Syntax: Specify the semantic use of colors, meanings of solid and dashed lines, fonts, rounded corners, and disabled effects.
SVG Technical Constraints: Require
```
viewBox
```
, semantic grouping, text retained as
```
<text>
```
, unique IDs,
```
vector-effect
```
,
```
<title>
```
,
```
<desc>
```
, and
```
aria-labelledby
```
.
Acceptance and Output: Require checks for semantics, structure, geometry, visuals, target canvas or applicable viewport, and accessibility, and output a complete editable SVG instead of a bitmap or just explanations.

When using Mermaid, attach the final adopted Mermaid relationship structure in "Relationships, Directions, and States", then supplement roles, state meanings, and layout constraints that cannot be expressed by Mermaid; do not write styles or coordinates automatically generated by Mermaid as requirements that SVG must copy.

Write the prompt in the main language consistent with the user; retain original names for code names, fields, and commands. The prompt should reference actual content instead of leaving placeholders like

[Object Name]

. Do not include temporary file paths, debugging processes, unconfirmed relationships, or old designs inconsistent with the final SVG.

The prompt uses the following fixed structure:

text

# Wireframe Generation Prompt

Please generate an accessible, responsive, editable HTML semantic wireframe SVG based on the following specifications.

## Task and Teaching Conclusion
[Fill in the purpose of the diagram and the unique core judgment]

## Objects and Visible Text
[Fill in objects, roles, groupings, quantities, and labels that must appear]

## Relationships, Directions, and States
[Fill in relationships, verbs, directions, line types, and states item by item]

## Layout and Reading Order
[Fill in composition, alignment, separation, safe distance, reading direction, and target canvas or applicable viewport behavior]

## Visual Syntax
[Fill in color semantics, wireframes, fonts, rounded corners, and prohibited items]

## SVG Technical Constraints
[Fill in structure, responsiveness, ID, text, stroke, and accessibility requirements]

## Acceptance and Output
[Fill in verification requirements and request complete SVG output]

3. Select Relationship Syntax and Minimal Diagram Type

Determine the connection method based on semantics first, then choose the composition. Arrows only represent directions that can be confirmed by materials, not default connectors.

Relationship	Graphic Syntax
Flow, dispatch, claim, call in main process	Blue solid one-way arrow; direction consistent with the verb
Non-main process, alternative path, optional starting point or jump	Blue dashed one-way arrow; use relationship labels to explain specific meanings
Bidirectional synchronization	Blue bidirectional arrow
Directionless association, pairing, contact	Black solid line, no marker
Containment, still existing within a certain range	Nested inner and outer boxes, no arrows; outer label occupies an independent safe area
Parallel evidence, three scenarios, peer objects	Groups aligned with the same scale and anchor point, no interconnections
State change	Keep object position as stable as possible, change line type or state label; only add arrows when there is a clear time or transfer relationship

Comparison: Two containers of the same scale are placed side by side, only highlighting changed relationships or states.
Hierarchy or dispatch: Upstream objects are placed at the top, downstream objects are arranged horizontally, arrows flow in a single direction.
Handover object: Only when tasks, data, documents, or products are essential to understanding the relationship, label it as a relationship tag near the arrow; do not label it unnecessarily. When the label is far from the arrow, draw an orange arrowless indicator line from the midpoint of the arrow line, do not let readers mistake it for a new process.
Public environment and autonomous collaboration: The environment or kanban occupies one side, peer participants occupy the other side, label relationships with verbs like "claim".
Human-machine dual interface: Use page wireframes for GUI, machine-readable fields for LUI; use one-way relationships for retrofitting, two-way relationships for synchronous design.

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

4. Organize Labels and Layout Contracts

Inventory card titles, group titles, object labels, relationship labels, and captions. Only retain one instance when adjacent levels express the same information; directly delete in-diagram subtitles that only repeat card or group titles.
For three or more peer diagrams, first determine a common anchor point. When object sizes differ, prioritize aligning to the visual center; accessory text such as titles and corner markers are not used as alignment benchmarks for the main body.
First define the boundaries and safe areas for dividing lines of each group, then place objects and connections. Object wireframes, text, and markers must not cover dividing lines or adjacent groups.
For containment relationships, first expand the outer frame, then reserve an independent area and padding for the outer label; inner and outer labels and wireframes must not overlap.
Use relative tolerances and safe distances; auxiliary lines or measurement boundaries can be added during debugging, and auxiliary elements must be removed before acceptance.

5. Apply Visual Syntax

docs/design/STYLE_DNA.md

: pure white, minimal, whitespace, restrained, technical document feel.

White
```
#FFFFFF
```
: Canvas and object interiors.
Black
```
#0A0A0A
```
: Object wireframes, main text.
Dark gray
```
#171717
```
: Secondary body text; medium gray
```
#737373
```
: Labels, relationship verbs.
Light gray
```
#E5E5E5
```
: Dividing lines, outer auxiliary boundaries.
Blue
```
#0348ED
```
: Only used for relationships such as direction, links, claims, dispatches, synchronization; do not use for ordinary explanatory text or large-area object fills.
Orange
```
#FE7E0F
```
: Prompts, task corner markers, warnings such as immature status, and arrowless indicator lines from main relationship lines to distant handover object labels.
Red
```
#FF3700
```
: Obstacles, conflicts, errors, or gaps; do not use without negative semantics.
Solid wireframe: Existing, available, confirmed objects.
Dashed wireframe: Objects added later, waiting, incomplete, fading, or candidate states; ambiguity must be resolved by text or context.
Monospace font:
```
name
```
,
```
desc
```
, parameters, commands, and other machine-readable fields.
Keep rounded corners slight, usually
```
rx="2"
```
to
```
8
```
; do not make pill-shaped cards.
Establish line weight hierarchy: Main relationship lines and arrows are the clearest, followed by object wireframes; handover object indicator lines can be slightly thinner but must not be hairline-thin. Do not mechanically apply overly thin default values; confirm lines are clearly recognizable in actual delivery dimensions.

Never add gradients, shadows, filters, textures, noise, complex backgrounds, 3D, tech-style UI, decorative icons, or semantic-free connections. Do not pursue "cute", "weird", or "poster-like" styles.

6. Construct SVG

Use a stable
```
viewBox
```
coordinate system, start with
```
0 0 600 250
```
as a priority, then adjust according to content.
Use
```
<g>
```
to group by objects, relationships, and states; use
```
<rect>
```
,
```
<line>
```
,
```
<path>
```
,
```
<text>
```
,
```
<tspan>
```
, and
```
<marker>
```
. When geometric acceptance is needed, add semantic attributes such as
```
data-align-group
```
,
```
data-boundary
```
,
```
data-relation
```
.
Retain text as SVG text, do not convert text to paths, do not use
```
<foreignObject>
```
.
Add
```
role="img"
```
,
```
aria-labelledby
```
, a
```
<title>
```
with a unique ID, and
```
<desc>
```
to each diagram.
```
desc
```
should explain objects, relationships, directions, and special states, not just repeat the title.
All
```
id
```
s within the same HTML document are unique, especially arrow markers. Use the page or component ID as a prefix, such as
```
s07-native-arrow-end
```
.
Use
```
vector-effect: non-scaling-stroke
```
for lines; arrows and relationship lines use the same semantic color. Handover object indicator lines use orange, no marker, and are grouped with the main relationship line.
Let HTML/CSS handle size, font, and token mapping; SVG handles structure. When an independent SVG file is needed, embed a minimal
```
<style>
```
and use the same token values.

Implementation patterns, CSS containers, and accessibility templates can be found in references/implementation-patterns.md.

7. Embed into HTML and Adapt to Target Canvas

Set the outer container to
```
width: 100%
```
,
```
min-width: 0
```
, appropriate padding, and
```
overflow: hidden
```
.
Set SVG to
```
display: block; width: 100%; height: auto;
```
, use
```
max-height
```
to control visual weight within the card.
Inherit canvas and viewport requirements from the upper skill that called it. Fixed-size HTML Presentations or PPT-style carriers only verify the target presentation size; course pages or responsive web pages need to maintain the same reading order when stacked in narrow screens, and not rely on arrow positions that only work on desktop.
Avoid small font sizes and long sentences. Prioritize using 2–6 characters for labels; use
```
<tspan x="…" dy="…">
```
to explicitly control line breaks when needed.
Do not use fixed pixel width and height in SVG to replace responsive CSS.

8. Verification

Check in order:

Semantics: Does the diagram accurately express the
```
teaching_claim
```
? Verify relationship syntax item by item, confirm arrows, dashed lines, and colors all have basis, and there are no duplicate adjacent labels.
- When using Mermaid, first preview or perform syntax checks in an available Mermaid renderer, then verify nodes, groupings, relationship verbs, and directions between Mermaid and the final SVG item by item; clearly record if rendering cannot be performed.
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 a local copy exists in the project. This script checks SVG structure and does not replace geometric acceptance.
Geometry: In the real canvas or viewport required by the upper skill, measure alignment deviations of peer main bodies, safe distances from objects to dividing lines, containment relationships of nested boxes, and collisions between text, wireframes, and connections; also check
```
viewBox
```
cropping and overflow. This must be done when there are three or more peer objects, dividing lines, or nested boxes. Fixed-size Presentation or PPT-style carriers only measure the target presentation size; responsive web pages check both desktop and narrow-screen viewports.
Visuals: View real page screenshots of the target canvas or applicable viewport, confirm reading order, visual focus, and whitespace are stable; do not ignore edge sticking or imbalance just because technically "no intersection" occurs. Also confirm that main lines, dashed lines, wireframes, and indicator lines have clear hierarchies in actual delivery dimensions, without being too thin or粘连.
Connection Traceability: Trace each relationship from the start to the arrow end in actual delivery dimensions, confirm each relationship has a unique, continuous visual path that does not require guessing. The line end should clearly leave the source object boundary, and the arrow should clearly land on the target object boundary; unless there is a clear convergence or branching node semantically, prohibit multiple relationships from sharing the same line segment over long distances. If coaxial overlap, path adhesion, inability to determine direction after crossing, connections blocked by objects or text, or arrows disconnected from targets occur, directly judge as unqualified. Prioritize reallocating connection ports, separating parallel paths, reducing crossings, or splitting diagrams; when long-distance backflow, cross-layer jumps, or dense broken lines are still difficult to trace, use smooth quadratic or cubic Bezier curve arrows. Curves must maintain a single direction, not pass through unrelated objects or text, and not create new crossing ambiguities; continue splitting diagrams if it cannot be solved within the target canvas, do not勉强保留 complex networks.
Accessibility: Confirm
```
<title>
```
,
```
<desc>
```
, and
```
aria-labelledby
```
correspond, and the main text can understand the core judgment even without looking at the diagram.
Prompt Consistency: Compare the final SVG with the prompt item by item, confirm objects, text, relationships, layout, color semantics, and output requirements are consistent; abandoned solutions during implementation must not remain in the prompt.
Integration: Execute existing build and verification commands of the target project; do not only verify isolated SVG.

Standard Output

Each time this skill is used, the following four items are delivered by default; reduce only when the user explicitly requests omission:

SVG Finished Product: Complete inline SVG, target HTML modifications, or independent
```
.svg
```
file.
Wireframe Generation Prompt: Filled in according to the fixed structure in Step 2, consistent with the final SVG and reusable independently.
Delivery Summary: Brief text explaining the diagram type, core objects, key relationships, and special states.
Verification Results: Explain the results of structure, geometry, visuals, connection traceability, target canvas or applicable viewport, accessibility, and project integration checks; clearly mark any checks that were not performed.

When using Mermaid, deliver a copyable Mermaid relationship structure specification; it can be placed in the "Relationships, Directions, and States" section of the wireframe generation prompt, no need to create a separate file. Mermaid only serves as an intermediate semantic asset, and SVG remains the final graphic deliverable.

When creating independent files, save the prompt as

<basename>.prompt.md

with the same name as the SVG, for example:

text

agent-collaboration.svg
agent-collaboration.prompt.md

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

<desc>

Reuse Examples

When needing to select composition, compare visual semantics, or copy initial structures, read references/example-catalog.md, and view 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 examples, must rewrite titles, descriptions, IDs, text, quantities, and relationships; examples are visual syntax, 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, has no unfilled placeholders, and can be used independently without the current conversation.
Each object, relationship, state, and accent color has clear semantics.
When using Mermaid, its nodes, groupings, relationship verbs, and directions are consistent with the final SVG, and the final composition does not mechanically copy Mermaid's automatic layout.
There are no duplicate labels in adjacent levels, and blue only expresses real direction or link semantics.
SVG is inlineable, scalable, accessible, and has no ID conflicts in the document.
Peer main bodies are aligned and maintain safe distances from dividing lines; labels, boundaries, and content of nested boxes do not collide.
Each directed relationship can be continuously traced from the source object to the target object in actual delivery dimensions; there are no collinear, adhesive, or crossing paths that require guessing directions, and complex backflow has eliminated ambiguity through rewiring, curve arrows, or diagram splitting.
No overflow, cropping, or unreadable text in the target canvas and applicable viewport specified by the upper skill.
The style remains pure white, low-color, with clear line weight hierarchy, no shadows, and does not distract from the main text.
When modifying existing courseware, source files, trace files, deliverables, and verification results remain consistent.

html-line-svg

NPX Install

Tags

SKILL.md Content (Chinese)