positron-abstract-svg

Positron Abstract SVG Skill

This skill helps you create clean, on-brand abstract SVG illustrations of the Positron IDE for documentation, walkthroughs, onboarding, and feature previews.

It applies to any part of the Positron IDE -- editor, notebooks, data explorer, console, plots, variables pane, terminal, AI assistant, and so on. The bundled examples and component patterns happen to focus on notebooks (that is what has been built so far), so treat them as a starting library rather than the full scope: the constraints, palette, fonts, layering rules, and icon conventions generalize to any surface. For a surface not yet covered, work from a screenshot and compose new components from the same primitives in the same style.

Critical Constraints

These are static SVGs rendered as plain images (e.g. <img src="...">) in many different contexts -- documentation sites, in-app walkthroughs, READMEs, etc. They cannot rely on the host page's styles or scripts. This means:

• No external CSS / CSS variables -- references like var(--some-token) will NOT resolve. All colors must be self-contained (hardcoded hex values, or an inline <style> block within the SVG itself).
• No JavaScript -- static SVG only.
• Assume a light background by default -- the palette and examples target a light context. Supporting both light and dark themes is a nice-to-have, not a requirement (see below); reach for it when the SVG will appear on surfaces of both kinds.
• Sizing: walkthrough images are commonly width="520" height="260", but pick a size and aspect ratio that suits the surface you are depicting and where the image will appear.

For a light-only image, start with an opaque white background rect:

<rect width="520" height="260" fill="#FFFFFF"/>

To support light and dark, omit the opaque background and either use colors that read on both, or adapt with an inline <style> block inside the SVG (a @media (prefers-color-scheme: dark) rule honored when the SVG carries its own styles). Keep it simple and always preview on both backgrounds.

Color Palette

These images exist to communicate complex UI simply. Clarity comes first -- a color that helps the eye parse the layout is worth using even if it isn't an exact Positron theme color. Matching the Positron theme is a nice-to-have, not a requirement; reach for whatever reads clearly at small sizes.

The palette below is a tested starting point. #447099 is the Positron brand blue; reserve it for the focal point. Treat the grays as a coherent set rather than precise values to match.

Gathering Input Before You Start

The more context you have about the actual UI, the better the abstract image will be. Ask the user for:

• A screenshot of the actual Positron UI being depicted -- this shows exact proportions, which elements are present, and what the focal point should be. If no screenshot is available, describe what you plan to show and confirm with the user.
• Codicon names for any toolbar or action bar icons -- e.g., notebook-execute, debug-alt-small, run-above. Use the ready-made paths in references/codicons.md; these are the curated, consistent set the existing walkthrough images already use. For an icon not listed there, copy the d= from node_modules/@vscode/codicons/src/icons/<name>.svg, then simplify it to match the flat style of the existing set (upstream codicons have evolved, so a fresh pull may not match visually).
• File type icons -- Positron uses the Seti UI file icon theme. It ships only as a font (extensions/theme-seti/icons/seti.woff), so there is no per-file SVG in the repo. Don't hand-draw one and don't fetch from the seti-ui repo over the network -- pull the exact glyph out of the font we ship. See "Extracting a Seti file icon" below.

Workflow

1. Gather input -- screenshot of the UI, icon names, file types (see above).
2. Plan the layout -- decide what panels/components to show and their proportions.
3. Sketch in SVG -- write the SVG, starting with background elements, then building up layers.
4. Preview -- always render a preview before saving to file; this catches layout issues early. In Claude Desktop, use the show_widget tool -- it renders the SVG inline and is the fastest way to iterate. In other environments (CLI, etc.), show_widget is unavailable, so preview by writing the SVG to a temp file and opening it in a browser or image viewer.
5. Iterate -- adjust based on the preview, re-render, repeat until it looks right.
6. Save -- write the final SVG to the correct path in the repository. If you previewed via a renderer (e.g. show_widget in Claude Desktop), strip any cruft it injected before saving: per-element style="fill:rgb(...);..." attributes (the fill="#hex" attribute already carries the color) and any Anthropic Sans / renderer-specific font names. Ship clean SVG with only the font stacks listed below.

SVG Layering (Z-order)

SVG renders elements in document order -- later elements appear on top. The general rule: draw containers before their contents, and floating/overlay elements last. For example:

• Draw a container's border and background before the content inside it (a cell, panel, dialog, etc.).
• Draw floating toolbars and overlays after their parent so they sit on top (e.g. a cell action bar).
• Draw separator/divider lines early so later content overlaps them cleanly.

Fonts

• UI labels, tab names, panel headers: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif
• Code and line numbers: 'Consolas', 'SF Mono', 'Menlo', monospace

Code Representation

Never write real readable text (code, labels, descriptions) in these illustrations unless the content is the focal point of the image. Use placeholder gray rects for any body text instead:

<!-- Good: placeholder code lines -->
<rect x="58" y="90" width="200" height="4" rx="2" fill="#C8C8C8"/>
<rect x="58" y="102" width="80" height="4" rx="2" fill="#C8C8C8"/>
<rect x="58" y="114" width="120" height="4" rx="2" fill="#C8C8C8"/>

When a specific piece of code IS the point (e.g., showing syntax highlighting for a kernel selector image), use <tspan> elements inside a <text> element for multi-color syntax:

<text x="58" y="86" font-family="'Consolas', 'SF Mono', 'Menlo', monospace" font-size="10.5">
  <tspan fill="#447099">x</tspan><tspan fill="#5A5A5A"> = </tspan><tspan fill="#098658">10</tspan>
</text>

Toolbar Icons (Codicons)

All toolbar icons use codicon SVG paths scaled to fit inside a 16x16 coordinate space. See references/codicons.md for the curated, ready-to-use icon paths.

Usage pattern -- scale icons to 16px at translate(x, y):

<g transform="translate(10, 37)" fill="#5A5A5A">
  <path d="...codicon path..."/>
</g>

For smaller contexts (cell action bar at ~11px), scale down:

<g transform="translate(35, 68) scale(0.7)" fill="#5A5A5A">
  <path d="...codicon path..."/>
</g>

The activity bar always gets real icons

The activity bar is the strip down the left edge of Positron (VS Code calls it the activity bar; it is the thing that switches which primary side bar view you see). Draw its icons as the actual codicons Positron shows there -- Explorer, Search, Source Control, Run and Debug, Extensions -- in that order. Never fill it with abstract squares, circles, or alternating shapes.

A row of nameless blobs is the one place in these images where abstraction costs more than it saves. Everywhere else a gray rect clearly stands in for text the reader is meant to skip. In the activity bar it just reads as noise, and it throws away the fastest cue that says "this is an IDE." Real glyphs also anchor the reader: they can find the same icons in their own window.

The rule holds even at small sizes. Explorer, Search, Source Control, and Extensions all stay readable down to about 9px; debug-alt is the first to turn to mush, so drop it before the others if you are showing fewer icons.

Content truncated.