$npx -y skills add tkellogg/open-strix --skill uiHow to choose between markdown, HTML messages, and UI plugins in the local web chat — and how to render each well. Use whenever you are about to call send_message to a web-chat channel, especially when the content has structure (rows, columns, statuses, a state machine, multipl
| 1 | # Choosing the right surface |
| 2 | |
| 3 | There are **three** surfaces in the local web UI. Pick by asking *what shape the content has*, not *how long it is*. |
| 4 | |
| 5 | | Surface | When | What it gives you | What it costs | |
| 6 | | --- | --- | --- | --- | |
| 7 | | **Markdown message** | Quick reply, single point, conversational. | Cheap, scrollable with the chat. | Linear — every reply pushes older ones up. | |
| 8 | | **HTML message** | One-off rich artifact: a table, a status card, a small dashboard, a diagram, a labelled diff. The shape is non-linear but the lifetime is "until the next message scrolls it away." | Tables, grids, layered SVG, color/typography, and small scripts under your control. Renders inline in chat. Can use parent-owned `data-strix-action` hooks or `window.strix`. | Ephemeral; sandboxed with no same-origin access. Cream background — see below. | |
| 9 | | **UI plugin** | A *frame of mind* that is not linear like chat. Persistent. Tim wants to see what we're talking about, not just discuss it. Example: chainlink issues — the chat thread talks *about* them, the plugin *shows* them, with detail views, filters, status. | A live, interactive, scrollable side panel that survives across turns. Full JS, can poll, can show fresh state. | Costs a server. Has a contract: see `ui-plugins.md`. | |
| 10 | |
| 11 | **Mental model (from Tim, 2026-05-12):** |
| 12 | |
| 13 | > "I want UI plugins to share a frame of mind that's not linear like chat. With chainlink, I couldn't see any of the chainlink issues — now I can." |
| 14 | |
| 15 | If you find yourself describing state in prose ("here are the 7 open RLS findings, here are their statuses, here's which ones map to PR #X..."), you're papering over a missing UI plugin. Either fire off an HTML message *now* and propose the plugin, or just build the plugin. |
| 16 | |
| 17 | --- |
| 18 | |
| 19 | # Rule of thumb (when in doubt) |
| 20 | |
| 21 | 1. **Quick reply, no shape?** → markdown. |
| 22 | 2. **One artifact you wouldn't want to scroll back to find?** → HTML message. Make it dense and self-contained. |
| 23 | 3. **The user is going to want to see this same thing again tomorrow, with fresh data?** → UI plugin. Read `ui-plugins.md`. |
| 24 | |
| 25 | Bias toward richer surfaces, not less. A markdown wall-of-bullets where an HTML table would do is a missed affordance. |
| 26 | |
| 27 | --- |
| 28 | |
| 29 | # Rendering HTML messages |
| 30 | |
| 31 | HTML messages render inside a sandboxed iframe in the local web UI. They will be *rejected* by Discord — for Discord, fall back to markdown. |
| 32 | |
| 33 | ## The chat surface |
| 34 | |
| 35 | **The chat surface can be light or dark.** HTML message iframes are **transparent** over the current agent-message surface: approximately `rgba(255, 250, 241, 0.84)` in light mode and `rgba(23, 33, 43, 0.9)` in dark mode. |
| 36 | |
| 37 | Safe strategies: |
| 38 | |
| 39 | 1. **Be theme-independent.** Use explicit foreground/background contrast that works in both light and dark themes. |
| 40 | 2. **Paint your own opaque background.** Set `html, body { background: <your color>; }` full-bleed (not just on a card) so contrast is fully under your control. Use this for dashboards, dark-mode mock-ups, or anything image-y. |
| 41 | 3. **Adapt scripted HTML.** If scripts are enabled, listen for `window.message` events of type `strix:theme` with `{ theme, background, text, muted, accent }` and adjust your CSS variables when the user switches theme. The harness pushes the theme once on frame load and again on every toggle. If your listener registers asynchronously (after load), call `window.strix.requestTheme()` right after you attach it — the harness re-sends the current theme so you don't miss the initial state. |
| 42 | |
| 43 | **Do not:** assume a fixed light or dark canvas unless you provide it yourself. Light text can disappear on light surfaces; dark text can disappear on dark surfaces. |
| 44 | |
| 45 | ## Script sandbox |
| 46 | |
| 47 | HTML messages use `sandbox="allow-scripts allow-forms"` — scripts and forms work, but the frame has an opaque origin. Do **not** assume same-origin access. The reply cannot read the parent DOM, and the parent cannot inspect the reply DOM after load. |
| 48 | |
| 49 | For parent-owned interactions, use the HTML action API in `html-actions.md`. The harness injects a tiny bridge that lets links, buttons, forms, and scripts ask the parent app to do controlled things like navigate a widget, send a chat message, or continue from the current HTML reply's agent context. |
| 50 | |
| 51 | If the interaction should persist across turns or act as a reusable app surface, build a UI plugin. |
| 52 | |
| 53 | ## Sizing |
| 54 | |
| 55 | The harness injects a `ResizeObserver` bridge that posts height updates to the parent. Do *not* try to fix a height. Width is capped at `min(42rem, 92%)`. If your script changes layout in an unusual way, call `window.strix.resize()`. |
| 56 | |
| 57 | --- |
| 58 | |
| 59 | # L |