boron

What A skill in that lets any coding agent (Claude Code, Codex, Cursor, …) make a Boron image from terminal output or code, save it as PNG/SVG/JPEG/WebP, and hand back a link that reopens the picture in the editor. It is agent-agnostic (plain , no tool-specific calls) and needs no npm install: only Node 22+ and whatever browser tool the agent already has (a Chrome extension or DevTools MCP server, Playwright, Puppeteer, …). It needs no change to the app. How it works The agent's browser tool opens the link, evaluates and decodes the data URL into the file. If the agent has no browser tool, the skill hands the user the link and tells them to click Save. One finding: in a link does not color the content A link's is taken literally, and only decides what the next paste does. So a link made from plain code arrives uncolored. takes a option and drives the Syntax select ( first, then the language, so a link that already names it still recolors). The address bar is then rewritten with the colored ANSI, and that is the the skill reports. Might be worth deciding whether a link naming a language should highlight on open. Why not html-to-image (the ray.so approach) The ray.so skill injects and rasterizes the preview DOM. That is correct for ray.so, whose DOM is the image. For Boron it is the wrong source: 1. It captures the preview, which is the one renderer allowed to drift. Per , the live flows glyphs with the browser instead of placing them at measured , and its frame, chrome, traffic lights and shadow are a second description of what emits. The Save button's output is what users get, so that is what an agent should get. 2. Fonts would silently fall back. Boron Mono is loaded through the API, not stylesheet . html-to-image only embeds fonts it finds in stylesheets, and the foreignObject image cannot see document fonts, so the output would be in a generic mono unless the skill rebuilt itself. 3. The node needs surgery first. carries , and contains the resize handles, the caret/selection and the box-selection overlay. Each would have to be undone or filtered out, and each is a new coupling to the DOM. 4. SVG would not be the real SVG. html-to-image's SVG is HTML wrapped in , not the vector export from with embedded, subset fonts. WebP/JPEG need an extra canvas pass. 5. A third-party script from a CDN at capture time, with its own version drift and a network dependency. Clicking the real button avoids all five: the pixels come from , exactly as a person would get them. Suggestion: a small export hook (would make this robust) The current capture couples to three UI details: the button text, the class names, and the select label. Scale is fixed at 2×. A tiny, documented hook would remove all of it: shrinks to , and falls back to the button click on older builds. Arbitrary scale (1×, 3×, 4×) for free, since already takes it. It is also the natural seam for the server-side card in . Happy to follow up with that as a separate PR if you want it. Tested Against live boron.sh, headless Chrome on macOS, with evaluated through Playwright and through agent-browser: PNG, default settings, colored output PNG with and (syntax colors present) WebP from the returned link (colors survive the round trip) JPEG with A fresh agent with no prior context, given only , produced a correct image on the first try An unknown format fails with an error that lists the valid values

This PR updates several user-facing flash messages to make export and clipboard actions clearer and more descriptive. Changes Updated “Saved ” to “Exported and Saved ” for more accurate feedback. Updated “Image copied” to “Copied Image to clipboard” for consistency with other clipboard messages. Improved clarity around clipboard operations to better reflect what the app is doing. These changes do not modify any logic—only the displayed messages. They improve overall UX by giving users more precise feedback during export and clipboard actions. Side Note: If you want this project to be OSS, you may wanna consider adding a LICENSE file.