DeckKit PPT SVG Assets
Use this skill when a DeckKit PPT replica workflow needs SVG assets for bbox elements whose routes are svg-image, editable-vector, or drawio-svg.
This skill is the SVG reconstruction subset of deckkit-ppt-replica. It authors SVG files, runs a pre-complete batch SVG preview QA/fix loop, and writes a manifest for downstream composition. It does not create workspaces, generate bbox JSON, build native DeckKit elements, or run image generation. Final placement correctness is still validated later by region QA.
You can run this skill standalone inside a prepared DeckKit work folder. A full deckkit-ppt-replica workflow is not required to test Iconfont candidate selection, SVG generation, batch preview QA, or the Iconfont golden-base audit.
Required Iconfont References
Before authoring semantic icons, resolve SKILL_DIR as the directory containing this SKILL.md.
Iconfont is the required default reference source for semantic icon assets. For every semantic icon, search Iconfont through the skill-local helper script, inspect the top candidates, select the best candidate by semantic correctness and asset quality, and use that selected SVG as the reference/base for assembly. For complex Iconfont-selected shapes, the selected show_svg is the golden base SVG, not a loose visual reference.
Inputs
Work inside the current DeckKit PPT work folder. The expected files are:
manifests/tasks/svg-assets.json
manifests/source-raster-cutouts.json
manifests/native-elements.json
crops/
svg/
Use the task manifest and crop manifest to identify every SVG asset to author. The usual candidates are render elements with routes:
svg-imageeditable-vectordrawio-svg
Use native-elements.json only to understand placeholder slots and replacement ownership. Do not modify native element code in this skill.
Output Contract
Write SVG XML files under:
svg/<element-id>.svg
For every selected Iconfont golden base candidate, also preserve a copy of the selected candidate SVG under:
references/iconfont-candidates/<element-id>.svg
Write a complete manifest:
manifests/svg-assets.json
Suggested manifest shape:
{
"taskId": "svg-assets",
"generatedAt": "YYYY-MM-DDTHH:mm:ss.sssZ",
"taskManifest": "manifests/tasks/svg-assets.json",
"sourceRasterCutoutsManifest": "manifests/source-raster-cutouts.json",
"nativeElementsManifest": "manifests/native-elements.json",
"assets": [
{
"elementId": "example_icon",
"route": "svg-image",
"cropPath": "crops/example_icon.png",
"svgPath": "svg/example_icon.svg",
"bbox": { "x": 0, "y": 0, "w": 24, "h": 24 },
"status": "complete",
"iconfontReferences": ["iconfont:q=云#2:id=123456"],
"notes": "Iconfont candidate assembled and adapted to source stroke weight."
}
],
"outputPaths": ["svg/example_icon.svg"],
"validationGaps": []
}
Keep paths relative to the work folder unless the surrounding tool contract requires absolute paths.
SVG Authoring Rules
Author each SVG as explicit visual code for that element. Do not generate a whole slide's SVG library through one object map plus default style branches such as directIconRefs[id] ?? ..., id.startsWith('sensing') ? BLUE : ..., or id.includes('header_icon') ? WHITE : .... The problem is not using a script to write files; the problem is forcing different visual groups through the same default style rules.
The bbox JSON and crop manifest are positioning/reference evidence, not a rendering DSL. Do not implement a generic route/kind/id-driven SVG renderer that loops through elements and dispatches through broad helpers such as strokeFor(element), fillFor(element), iconFor(element), or id.includes(...) rules.
Required approach:
- Use the source crop as the visual reference for the individual element.
- When crop images are attached to the prompt, treat those attached crop images as the primary visual reference for geometry, colors, stroke weight, gradients, and aspect ratio.
- Make visual decisions visible in the SVG source: viewBox, stroke, fill, opacity, path geometry, text-as-path decisions, grouping, transforms, and layer order.
- Keep helpers limited to file lookup, manifest parsing, XML escaping, and truly repeated primitives whose visual spec has been verified against the source.
- Asset files must have truthful extensions. A
.svg file must contain SVG XML; do not write SVG text to a .png path.
- Insertable assets must be self-contained SVGs with explicit
viewBox, width, height, and no dependency on external CSS, fonts, scripts, remote images, or repository-local files.
Icon Reconstruction
For every semantic icon:
Identify the icon's meaning from the source crop, neighboring labels, and task context.
Derive the Iconfont search query from the icon's visual semantic meaning, not by blindly copying nearby PPT text. Nearby labels, section titles, and page theme are context clues for disambiguation, but the query should name what the icon depicts or symbolizes. For example:
- If the nearby label is
营养管理 but the icon depicts a pancreas or organ, search 胰腺 or 器官, not 营养管理.
- If the nearby label is
血糖监测 and the icon depicts a glucose meter, search 血糖仪, 血糖检测仪, or 血糖监测仪.
- If the nearby label is
感染预防 but the icon depicts a shield, virus, mask, or disinfectant bottle, search that visual concept such as 盾牌病毒, 病毒防护, 口罩, or 消毒液.
- If the nearby label is
管路管理 but the icon depicts an infusion tube, drainage tube, catheter, or IV bag, search 输液管, 引流管, 导管, or 输液袋.
Search Iconfont through the skill-local helper script. This Iconfont search is mandatory for every semantic icon, including generic symbols and complex domain-specific concepts such as nurse, liver, lung, kidney, stomach, organ, doctor specialty, local industry symbols, or product icons.
node "$SKILL_DIR/scripts/iconfont-top20-summary.mjs" \
--query "护士" \
--out /tmp/iconfont-nurse \
--limit 20
Do not run raw curl from the session and paste the response into context. The helper script performs the API call, writes raw-response.json, summary.json, candidates/*.svg, contact-sheet.svg, and when possible contact-sheet.svg.png, then prints only compact paths and candidate metadata. The session should inspect the rendered contact sheet PNG or SVG plus summary, then read only the single selected candidate SVG.
Use Chinese query terms when the concept is naturally Chinese or comes from Chinese slide text. If the first query is too broad or misses the concept, try one or two more precise semantic queries, such as 护士, 护士帽, 肝脏, 肝, 医生, or 医疗护理.
The helper script encapsulates the Iconfont API request and response parsing. The API response shape, saved in raw-response.json for traceability but normally not read into model context, is:
{
"code": 200,
"data": {
"icons": [
{
"id": 3767594,
"name": "血糖仪",
"font_class": "xietangyi",
"width": 1024,
"height": 1024,
"fills": 1,
"preview_image": "t/icon_poster/...",
"show_svg": "<svg ... viewBox=\"0 0 1024 1024\">...</svg>"
}
],
"count": 20
}
}
Score Iconfont top-20 candidates before writing the final SVG. Inspect /tmp/iconfont-*/contact-sheet.svg.png when the helper reports renderedPngPath; otherwise inspect /tmp/iconfont-*/contact-sheet.svg, plus /tmp/iconfont-*/summary.json. The selection priority is:
- Semantic correctness: the candidate represents the same concept and contains the right domain-specific structure, such as the correct organ/device/tube/bag/nurse form.
- Asset quality: prefer the most refined, legible, well-proportioned, and visually polished candidate that can stand as the golden base at PPT icon size.
- Adaptability to the slide: prefer candidates whose fill/stroke, color, background, and composition can be adapted with allowed modifications.
Do NOT choose a worse candidate merely because it is line art, has the same fill/stroke mode as the source crop, or superficially matches the crop's rendering style. Line-vs-fill and color are normally adjustable. For example, if a filled pancreas candidate is semantically stronger and more polished than a white-line pancreas candidate, choose the filled candidate and adapt its fill color/background instead of selecting the weaker line-art candidate.
Only after choosing the best candidate should you read that one candidate file from /tmp/iconfont-*/candidates/. Copy that selected file into the work folder at references/iconfont-candidates/<element-id>.svg; do not leave the only provenance path in /tmp. The selected candidate's show_svg becomes the golden base asset for the subject shape. Record the chosen candidate in the manifest, including candidateSvgPath, for example:
{
"iconfontReferences": ["iconfont:q=护士#3:id=123456"],
"selectedIconfontCandidate": {
"query": "护士",
"rank": 3,
"id": 123456,
"name": "护士",
"candidateSvgPath": "references/iconfont-candidates/nurse.svg",
"goldenBase": true,
"reason": "Best semantic and asset-quality match; show_svg used as golden base shape."
}
}
For complex domain-specific shapes from Iconfont, such as organs, nurses, medical devices, drainage/infusion tubes, industrial equipment, or highly specialized pictograms, do NOT redraw the icon from path memory and do NOT author an alternative subject geometry inspired by the candidate. Use the highest-scoring Iconfont candidate's show_svg as the golden base SVG for the subject shape. If the selected candidate is missing important subject details, choose a better complete candidate; do not repair it by drawing new subject internals. Only adjust:
- foreground color or stroke/fill color
- scale, crop, centering, and
viewBox placement
- background circle/card/badge
- generic status badges outside the subject shape, such as warning triangles, plus signs, shields, or status dots
- grouping with other already-selected Iconfont candidate shapes, with each meaningful sub-icon recorded in
iconfontReferences and copied under references/iconfont-candidates/
Do not invent a new organ, nurse, tube, device, or other complex silhouette when a top-20 Iconfont candidate is a better shape match. Preserve the selected candidate's core paths/silhouette unless a minimal transform or color normalization is required for the slide style.
If you need a different color, wrap the candidate paths in groups or change paint attributes; do not replace the subject geometry with hand-authored lookalike geometry.
Do not add hand-authored subject internals or extensions such as leaves, glucose screens, measurement strips, tube extensions, organ lobes, device panels, or anatomical details. Extra authored geometry may only be simple background/status geometry; it must not change what the chosen Iconfont subject depicts.
If the target icon is a composition of multiple meaningful objects, run separate Iconfont searches for each meaningful object and compose the selected candidate SVGs. For example, a glucose monitoring icon that needs a meter plus strip should search/select both 血糖仪 and 试纸 if one candidate does not already include both. A tube-management icon that needs a bag plus tube should search/select both 输液袋 and 输液管 if one candidate does not already include both. Do not search one subject and hand-author the remaining meaningful object.
For simple generic symbols, still use Iconfont search first. You may assemble a final icon from multiple selected Iconfont candidates or simple explicit SVG primitives when composition is needed, but record the Iconfont candidate(s) that drove the semantic choice.
If Iconfont search fails or network access is blocked, still author the best semantic SVG from crop/context and record the attempted query and failure reason in validationGaps.
If the icon is a semantic composition, draw it as multiple sub-icons or subgroups in one SVG instead of forcing all paths into one connected shape. For example, a "low-power sensing" icon can be one battery/lightning subgroup plus a separately positioned leaf subgroup:
<svg viewBox="0 0 48 72" xmlns="http://www.w3.org/2000/svg">
<g id="battery-lightning">...</g>
<g id="leaf" transform="translate(...) scale(...)">...</g>
</svg>
Treat subgroups as independently positioned semantic units. This avoids accidental merged shapes that read as stands, chains, tails, or other unintended objects after scaling.
Visual Group Rules
Treat visual group membership as part of the asset spec. The same semantic icon can require separate SVG code or separate parameters in different regions:
- A large temperature/humidity icon in a pale circle is not the same visual asset as a small temperature sensor icon in a dense architecture diagram.
- Icons inside the same sensing group may still have local exceptions, such as a green air-quality/leaf icon among blue sensor icons.
- Header icons, footer icons, service icons, scenario icons, and core-innovation icons each have their own color, scale, stroke weight, and background context.
Do not reuse an icon file, color rule, scale rule, stroke-width rule, or transform just because the semantic meaning is similar. Reuse is allowed only after comparing source crops and confirming that the visual group specifications match. If they do not match, create separate SVG files and separate manifest records.
Non-Basic Decorative Shapes
For decorations that are not simple PPT primitives, such as curved section headers, swooshes, ribbons, asymmetric tabs, custom frame chrome, diagram connectors, or compound badges:
- Visually identify the semantic role: header tab, section boundary, motion sweep, brand accent, separator, background skin, connector, or badge.
- Reconstruct at the semantic level using SVG paths, gradients, masks, groups, and explicit geometry.
- Match the layout role and visual rhythm of the source crop.
- Use a viewBox that matches the asset's natural bbox aspect ratio for wide/tall decorative assets instead of forcing
0 0 24 24.
- Preserve the crop's silhouette, curvature rhythm, edge treatments, bevel/shadow intent, and layer order well enough that the asset looks usable when placed on the slide.
Do not reproduce random image-generation artifacts unless they define a boundary, hierarchy, repeated style, or reading order.
Pre-Complete Preview QA And Fix Loop
Before handing off, run a lightweight visual QA loop on the generated SVG assets themselves. This is not final slide-region QA; it catches bad icon choices, tiny render previews, off-center graphics, missing paths, wrong colors, and hand-drawn shapes that clearly do not match the crop.
Required preview method:
Create a batch contact sheet that places every generated SVG on a white background, centered and enlarged in a fixed cell. Do not rely on default thumbnail behavior where a tiny SVG appears in the top-left of a large white canvas.
Use $SKILL_DIR/scripts/svg-contact-sheet.mjs when available:
node "$SKILL_DIR/scripts/svg-contact-sheet.mjs" \
--manifest manifests/svg-assets.json \
--out preview/svg-assets/contact-sheet.svg \
--columns 2 \
--cell 500 \
--icon 310
Render the contact sheet to an inspectable image. On macOS, qlmanage is acceptable:
qlmanage -t -s 1000 -o preview/svg-assets preview/svg-assets/contact-sheet.svg
Inspect the rendered contact sheet at a useful size. If a generated SVG is obviously wrong, too tiny, clipped, off-center, poorly colored, or based on a worse Iconfont candidate than another top-20 result, fix it and regenerate the contact sheet.
Repeat until the batch preview is usable enough for downstream composition, or record remaining issues in validationGaps.
Contact sheets should be compact enough to view in one screen. For many assets, create multiple sheets, such as contact-sheet-1.svg, contact-sheet-2.svg, etc. Each icon should be visibly large in its cell.
Do not create verbose per-icon qa.md files unless explicitly requested. Prefer batch visual evidence and concise manifest notes.
Static Validation
After the preview QA/fix loop, perform static validation:
manifests/svg-assets.json parses as JSON.- Every SVG replacement slot owned by
svg-assets has exactly one asset record.
- Every asset record has a matching
elementId, original route, cropPath, and svgPath.
- Every
svgPath is under svg/, ends with .svg, exists, and contains SVG XML.
- Every authored SVG has a
viewBox and no external network or filesystem dependency.
- Every complex Iconfont-derived asset records the chosen top-20 candidate in
iconfontReferences and selectedIconfontCandidate, with candidateSvgPath.
- Every complex Iconfont-derived SVG should preserve selected candidates as the subject source and should not introduce hand-authored subject internals. Catch this in the batch visual QA loop by comparing the final SVG contact sheet against the selected Iconfont contact sheets/candidates.
- The batch preview contact sheet path is recorded in
validationGaps or notes only if it exposes a remaining issue; otherwise it can be left as a generated QA artifact.
validationGaps records any asset that could not be reconstructed semantically.
When running this skill standalone, use the skill-local validator before handoff:
node "$SKILL_DIR/scripts/validate-svg-assets.mjs" --workdir .
This does not require running the full replica workflow. It checks manifest shape, SVG files, and Iconfont candidate provenance. The semantic rule that complex subjects must come from selected Iconfont candidates is enforced by the skill workflow and batch visual QA, not by brittle geometric path matching.
Then stop and report:
- The path to
manifests/svg-assets.json.
- The number of SVG assets authored.
- Any static validation gaps.
1---2name: deckkit-ppt-svg-assets3description: Reconstruct SVG-ready PPT slide assets from bbox/crop inputs using Iconfont reference search, golden base SVG selection, explicit SVG assembly, batch SVG preview QA, and manifest output.4---56# DeckKit PPT SVG Assets78Use this skill when a DeckKit PPT replica workflow needs SVG assets for bbox elements whose routes are `svg-image`, `editable-vector`, or `drawio-svg`.910This skill is the SVG reconstruction subset of `deckkit-ppt-replica`. It authors SVG files, runs a pre-complete batch SVG preview QA/fix loop, and writes a manifest for downstream composition. It does not create workspaces, generate bbox JSON, build native DeckKit elements, or run image generation. Final placement correctness is still validated later by region QA.1112You can run this skill standalone inside a prepared DeckKit work folder. A full `deckkit-ppt-replica` workflow is not required to test Iconfont candidate selection, SVG generation, batch preview QA, or the Iconfont golden-base audit.1314## Required Iconfont References1516Before authoring semantic icons, resolve `SKILL_DIR` as the directory containing this `SKILL.md`.1718Iconfont is the required default reference source for semantic icon assets. For every semantic icon, search Iconfont through the skill-local helper script, inspect the top candidates, select the best candidate by semantic correctness and asset quality, and use that selected SVG as the reference/base for assembly. For complex Iconfont-selected shapes, the selected `show_svg` is the golden base SVG, not a loose visual reference.1920## Inputs2122Work inside the current DeckKit PPT work folder. The expected files are:2324```txt25manifests/tasks/svg-assets.json26manifests/source-raster-cutouts.json27manifests/native-elements.json28crops/29svg/30```3132Use the task manifest and crop manifest to identify every SVG asset to author. The usual candidates are render elements with routes:3334- `svg-image`35- `editable-vector`36- `drawio-svg`3738Use `native-elements.json` only to understand placeholder slots and replacement ownership. Do not modify native element code in this skill.3940## Output Contract4142Write SVG XML files under:4344```txt45svg/<element-id>.svg46```4748For every selected Iconfont golden base candidate, also preserve a copy of the selected candidate SVG under:4950```txt51references/iconfont-candidates/<element-id>.svg52```5354Write a complete manifest:5556```txt57manifests/svg-assets.json58```5960Suggested manifest shape:6162```json63{64 "taskId": "svg-assets",65 "generatedAt": "YYYY-MM-DDTHH:mm:ss.sssZ",66 "taskManifest": "manifests/tasks/svg-assets.json",67 "sourceRasterCutoutsManifest": "manifests/source-raster-cutouts.json",68 "nativeElementsManifest": "manifests/native-elements.json",69 "assets": [70 {71 "elementId": "example_icon",72 "route": "svg-image",73 "cropPath": "crops/example_icon.png",74 "svgPath": "svg/example_icon.svg",75 "bbox": { "x": 0, "y": 0, "w": 24, "h": 24 },76 "status": "complete",77 "iconfontReferences": ["iconfont:q=云#2:id=123456"],78 "notes": "Iconfont candidate assembled and adapted to source stroke weight."79 }80 ],81 "outputPaths": ["svg/example_icon.svg"],82 "validationGaps": []83}84```8586Keep paths relative to the work folder unless the surrounding tool contract requires absolute paths.8788## SVG Authoring Rules8990Author each SVG as explicit visual code for that element. Do not generate a whole slide's SVG library through one object map plus default style branches such as `directIconRefs[id] ?? ...`, `id.startsWith('sensing') ? BLUE : ...`, or `id.includes('header_icon') ? WHITE : ...`. The problem is not using a script to write files; the problem is forcing different visual groups through the same default style rules.9192The bbox JSON and crop manifest are positioning/reference evidence, not a rendering DSL. Do not implement a generic route/kind/id-driven SVG renderer that loops through elements and dispatches through broad helpers such as `strokeFor(element)`, `fillFor(element)`, `iconFor(element)`, or `id.includes(...)` rules.9394Required approach:9596- Use the source crop as the visual reference for the individual element.97- When crop images are attached to the prompt, treat those attached crop images as the primary visual reference for geometry, colors, stroke weight, gradients, and aspect ratio.98- Make visual decisions visible in the SVG source: viewBox, stroke, fill, opacity, path geometry, text-as-path decisions, grouping, transforms, and layer order.99- Keep helpers limited to file lookup, manifest parsing, XML escaping, and truly repeated primitives whose visual spec has been verified against the source.100- Asset files must have truthful extensions. A `.svg` file must contain SVG XML; do not write SVG text to a `.png` path.101- Insertable assets must be self-contained SVGs with explicit `viewBox`, `width`, `height`, and no dependency on external CSS, fonts, scripts, remote images, or repository-local files.102103## Icon Reconstruction104105For every semantic icon:1061071. Identify the icon's meaning from the source crop, neighboring labels, and task context.1082. Derive the Iconfont search query from the icon's visual semantic meaning, not by blindly copying nearby PPT text. Nearby labels, section titles, and page theme are context clues for disambiguation, but the query should name what the icon depicts or symbolizes. For example:109110 - If the nearby label is `营养管理` but the icon depicts a pancreas or organ, search `胰腺` or `器官`, not `营养管理`.111 - If the nearby label is `血糖监测` and the icon depicts a glucose meter, search `血糖仪`, `血糖检测仪`, or `血糖监测仪`.112 - If the nearby label is `感染预防` but the icon depicts a shield, virus, mask, or disinfectant bottle, search that visual concept such as `盾牌病毒`, `病毒防护`, `口罩`, or `消毒液`.113 - If the nearby label is `管路管理` but the icon depicts an infusion tube, drainage tube, catheter, or IV bag, search `输液管`, `引流管`, `导管`, or `输液袋`.1141153. Search Iconfont through the skill-local helper script. This Iconfont search is mandatory for every semantic icon, including generic symbols and complex domain-specific concepts such as nurse, liver, lung, kidney, stomach, organ, doctor specialty, local industry symbols, or product icons.116117 ```bash118 node "$SKILL_DIR/scripts/iconfont-top20-summary.mjs" \119 --query "护士" \120 --out /tmp/iconfont-nurse \121 --limit 20122 ```123124 Do not run raw `curl` from the session and paste the response into context. The helper script performs the API call, writes `raw-response.json`, `summary.json`, `candidates/*.svg`, `contact-sheet.svg`, and when possible `contact-sheet.svg.png`, then prints only compact paths and candidate metadata. The session should inspect the rendered contact sheet PNG or SVG plus summary, then read only the single selected candidate SVG.125126 Use Chinese query terms when the concept is naturally Chinese or comes from Chinese slide text. If the first query is too broad or misses the concept, try one or two more precise semantic queries, such as `护士`, `护士帽`, `肝脏`, `肝`, `医生`, or `医疗护理`.1274. The helper script encapsulates the Iconfont API request and response parsing. The API response shape, saved in `raw-response.json` for traceability but normally not read into model context, is:128129 ```json130 {131 "code": 200,132 "data": {133 "icons": [134 {135 "id": 3767594,136 "name": "血糖仪",137 "font_class": "xietangyi",138 "width": 1024,139 "height": 1024,140 "fills": 1,141 "preview_image": "t/icon_poster/...",142 "show_svg": "<svg ... viewBox=\"0 0 1024 1024\">...</svg>"143 }144 ],145 "count": 20146 }147 }148 ```1491505. Score Iconfont top-20 candidates before writing the final SVG. Inspect `/tmp/iconfont-*/contact-sheet.svg.png` when the helper reports `renderedPngPath`; otherwise inspect `/tmp/iconfont-*/contact-sheet.svg`, plus `/tmp/iconfont-*/summary.json`. The selection priority is:151152 1. Semantic correctness: the candidate represents the same concept and contains the right domain-specific structure, such as the correct organ/device/tube/bag/nurse form.153 2. Asset quality: prefer the most refined, legible, well-proportioned, and visually polished candidate that can stand as the golden base at PPT icon size.154 3. Adaptability to the slide: prefer candidates whose fill/stroke, color, background, and composition can be adapted with allowed modifications.155156 Do NOT choose a worse candidate merely because it is line art, has the same fill/stroke mode as the source crop, or superficially matches the crop's rendering style. Line-vs-fill and color are normally adjustable. For example, if a filled pancreas candidate is semantically stronger and more polished than a white-line pancreas candidate, choose the filled candidate and adapt its fill color/background instead of selecting the weaker line-art candidate.157158 Only after choosing the best candidate should you read that one candidate file from `/tmp/iconfont-*/candidates/`. Copy that selected file into the work folder at `references/iconfont-candidates/<element-id>.svg`; do not leave the only provenance path in `/tmp`. The selected candidate's `show_svg` becomes the golden base asset for the subject shape. Record the chosen candidate in the manifest, including `candidateSvgPath`, for example:159160 ```json161 {162 "iconfontReferences": ["iconfont:q=护士#3:id=123456"],163 "selectedIconfontCandidate": {164 "query": "护士",165 "rank": 3,166 "id": 123456,167 "name": "护士",168 "candidateSvgPath": "references/iconfont-candidates/nurse.svg",169 "goldenBase": true,170 "reason": "Best semantic and asset-quality match; show_svg used as golden base shape."171 }172 }173 ```1741756. For complex domain-specific shapes from Iconfont, such as organs, nurses, medical devices, drainage/infusion tubes, industrial equipment, or highly specialized pictograms, do NOT redraw the icon from path memory and do NOT author an alternative subject geometry inspired by the candidate. Use the highest-scoring Iconfont candidate's `show_svg` as the golden base SVG for the subject shape. If the selected candidate is missing important subject details, choose a better complete candidate; do not repair it by drawing new subject internals. Only adjust:176177 - foreground color or stroke/fill color178 - scale, crop, centering, and `viewBox` placement179 - background circle/card/badge180 - generic status badges outside the subject shape, such as warning triangles, plus signs, shields, or status dots181 - grouping with other already-selected Iconfont candidate shapes, with each meaningful sub-icon recorded in `iconfontReferences` and copied under `references/iconfont-candidates/`182183 Do not invent a new organ, nurse, tube, device, or other complex silhouette when a top-20 Iconfont candidate is a better shape match. Preserve the selected candidate's core paths/silhouette unless a minimal transform or color normalization is required for the slide style.184 If you need a different color, wrap the candidate paths in groups or change paint attributes; do not replace the subject geometry with hand-authored lookalike geometry.185 Do not add hand-authored subject internals or extensions such as leaves, glucose screens, measurement strips, tube extensions, organ lobes, device panels, or anatomical details. Extra authored geometry may only be simple background/status geometry; it must not change what the chosen Iconfont subject depicts.1867. If the target icon is a composition of multiple meaningful objects, run separate Iconfont searches for each meaningful object and compose the selected candidate SVGs. For example, a glucose monitoring icon that needs a meter plus strip should search/select both `血糖仪` and `试纸` if one candidate does not already include both. A tube-management icon that needs a bag plus tube should search/select both `输液袋` and `输液管` if one candidate does not already include both. Do not search one subject and hand-author the remaining meaningful object.1878. For simple generic symbols, still use Iconfont search first. You may assemble a final icon from multiple selected Iconfont candidates or simple explicit SVG primitives when composition is needed, but record the Iconfont candidate(s) that drove the semantic choice.1889. If Iconfont search fails or network access is blocked, still author the best semantic SVG from crop/context and record the attempted query and failure reason in `validationGaps`.18910. If the icon is a semantic composition, draw it as multiple sub-icons or subgroups in one SVG instead of forcing all paths into one connected shape. For example, a "low-power sensing" icon can be one battery/lightning subgroup plus a separately positioned leaf subgroup:190191 ```svg192 <svg viewBox="0 0 48 72" xmlns="http://www.w3.org/2000/svg">193 <g id="battery-lightning">...</g>194 <g id="leaf" transform="translate(...) scale(...)">...</g>195 </svg>196 ```197198Treat subgroups as independently positioned semantic units. This avoids accidental merged shapes that read as stands, chains, tails, or other unintended objects after scaling.199200## Visual Group Rules201202Treat visual group membership as part of the asset spec. The same semantic icon can require separate SVG code or separate parameters in different regions:203204- A large temperature/humidity icon in a pale circle is not the same visual asset as a small temperature sensor icon in a dense architecture diagram.205- Icons inside the same sensing group may still have local exceptions, such as a green air-quality/leaf icon among blue sensor icons.206- Header icons, footer icons, service icons, scenario icons, and core-innovation icons each have their own color, scale, stroke weight, and background context.207208Do not reuse an icon file, color rule, scale rule, stroke-width rule, or transform just because the semantic meaning is similar. Reuse is allowed only after comparing source crops and confirming that the visual group specifications match. If they do not match, create separate SVG files and separate manifest records.209210## Non-Basic Decorative Shapes211212For decorations that are not simple PPT primitives, such as curved section headers, swooshes, ribbons, asymmetric tabs, custom frame chrome, diagram connectors, or compound badges:2132141. Visually identify the semantic role: header tab, section boundary, motion sweep, brand accent, separator, background skin, connector, or badge.2152. Reconstruct at the semantic level using SVG paths, gradients, masks, groups, and explicit geometry.2163. Match the layout role and visual rhythm of the source crop.2174. Use a viewBox that matches the asset's natural bbox aspect ratio for wide/tall decorative assets instead of forcing `0 0 24 24`.2185. Preserve the crop's silhouette, curvature rhythm, edge treatments, bevel/shadow intent, and layer order well enough that the asset looks usable when placed on the slide.219220Do not reproduce random image-generation artifacts unless they define a boundary, hierarchy, repeated style, or reading order.221222## Pre-Complete Preview QA And Fix Loop223224Before handing off, run a lightweight visual QA loop on the generated SVG assets themselves. This is not final slide-region QA; it catches bad icon choices, tiny render previews, off-center graphics, missing paths, wrong colors, and hand-drawn shapes that clearly do not match the crop.225226Required preview method:2272281. Create a batch contact sheet that places every generated SVG on a white background, centered and enlarged in a fixed cell. Do not rely on default thumbnail behavior where a tiny SVG appears in the top-left of a large white canvas.2292. Use `$SKILL_DIR/scripts/svg-contact-sheet.mjs` when available:230231 ```bash232 node "$SKILL_DIR/scripts/svg-contact-sheet.mjs" \233 --manifest manifests/svg-assets.json \234 --out preview/svg-assets/contact-sheet.svg \235 --columns 2 \236 --cell 500 \237 --icon 310238 ```2392403. Render the contact sheet to an inspectable image. On macOS, `qlmanage` is acceptable:241242 ```bash243 qlmanage -t -s 1000 -o preview/svg-assets preview/svg-assets/contact-sheet.svg244 ```2452464. Inspect the rendered contact sheet at a useful size. If a generated SVG is obviously wrong, too tiny, clipped, off-center, poorly colored, or based on a worse Iconfont candidate than another top-20 result, fix it and regenerate the contact sheet.2475. Repeat until the batch preview is usable enough for downstream composition, or record remaining issues in `validationGaps`.248249Contact sheets should be compact enough to view in one screen. For many assets, create multiple sheets, such as `contact-sheet-1.svg`, `contact-sheet-2.svg`, etc. Each icon should be visibly large in its cell.250251Do not create verbose per-icon `qa.md` files unless explicitly requested. Prefer batch visual evidence and concise manifest notes.252253## Static Validation254255After the preview QA/fix loop, perform static validation:256257- `manifests/svg-assets.json` parses as JSON.258- Every SVG replacement slot owned by `svg-assets` has exactly one asset record.259- Every asset record has a matching `elementId`, original `route`, `cropPath`, and `svgPath`.260- Every `svgPath` is under `svg/`, ends with `.svg`, exists, and contains SVG XML.261- Every authored SVG has a `viewBox` and no external network or filesystem dependency.262- Every complex Iconfont-derived asset records the chosen top-20 candidate in `iconfontReferences` and `selectedIconfontCandidate`, with `candidateSvgPath`.263- Every complex Iconfont-derived SVG should preserve selected candidates as the subject source and should not introduce hand-authored subject internals. Catch this in the batch visual QA loop by comparing the final SVG contact sheet against the selected Iconfont contact sheets/candidates.264- The batch preview contact sheet path is recorded in `validationGaps` or notes only if it exposes a remaining issue; otherwise it can be left as a generated QA artifact.265- `validationGaps` records any asset that could not be reconstructed semantically.266267When running this skill standalone, use the skill-local validator before handoff:268269```bash270node "$SKILL_DIR/scripts/validate-svg-assets.mjs" --workdir .271```272273This does not require running the full replica workflow. It checks manifest shape, SVG files, and Iconfont candidate provenance. The semantic rule that complex subjects must come from selected Iconfont candidates is enforced by the skill workflow and batch visual QA, not by brittle geometric path matching.274275Then stop and report:276277- The path to `manifests/svg-assets.json`.278- The number of SVG assets authored.279- Any static validation gaps.
artifact-kit