Agent skills

rd-prototype

Build one self-contained clickable HTML file from a plan or an issue, and attach it so reviewers click a Preview URL instead of reading a description.

rd-prototype builds one HTML file showing every screen and state a plan names, opens it locally, and attaches it to the Radial parent so the Preview URL can be shared. It is throwaway by design: real copy, fake data, no dependencies, nothing that survives into production.

Build one self-contained clickable HTML prototype from a plan or from a Radial issue, then attach it to the issue so reviewers click a Preview URL instead of reading a wireframe description.

When to use it

A change with a visible surface, before anyone writes the real component. Also on an existing issue, when a reviewer says they cannot picture it. Skip it for a change with no screen, and say why rather than skipping silently.

What it asks you

Almost nothing up front, and one thing at the end: a reaction. It reads the plan or the issue for **UX:** lines and browse checks, then reads your repo for the visual language it should copy: the theme file, the type scale, the spacing rhythm, one shipped screen to take the chrome from. If the repo has no visual language yet it picks one deliberately and tells you which.

What it writes

.radial/prototypes/<slug>.html, one file. When the tree exists it attaches it to the parent and adds a **Prototype:** line with the Preview URL to the parent body, deleting the previous attachment first so the newest file is unambiguous. When the tree does not exist yet it leaves the file for /rd-issues to attach. It changes no status, assignee or label.

The constraints, and why

The file has no external URL in it: no CDN, no web font, no image host. A prototype that needs the network renders blank in a reviewer's sandbox, which is exactly where Preview URLs are opened. Every screen the plan names is reachable from an index at the top, because a reviewer who has to guess how to reach screen four will review screens one to three. Every state is shown (empty, loading, error, denied) because states are where designs actually fail, and real copy is used, because placeholder text hides the hardest layout problem, which is always the long string.

Extension points

Hook	What a section here adds
`extra-craft`	Design-system specifics: token names, a component to mimic, a density rule, an accessibility floor
`extra-screens`	More required screens or states: a print view, an RTL pass, a specific breakpoint
`save-bar`	Raise the bar before it is attached: a contrast ratio, a screenshot of every screen, a second reviewer
`extra-notes`	Extra recording after attaching: a design-doc link, a comment on the issue, a note in the parent body
`extra-checks`	Final checks stated in the report: who must react, and by when

A worked wrapper

markdown

---
name: design-system-prototype
description: Our design-system rules on top of rd-prototype.
extends: rd-prototype
---

Read rd-prototype first, then apply the sections below at their hooks.

## extra-craft

- Copy the tokens from `src/styles/tokens.css` verbatim into the `<style>`
  block. Never invent a colour.
- Controls are 36px tall and 8px-rounded, matching the shipped app.

## extra-screens

- Always include a 1280px screen and a 390px screen for every flow.
- Include a keyboard-focus state for every interactive element.

## save-bar

- Body text must clear 4.5:1 against its background; state the measured ratio.

## extra-notes

- Post the Preview URL in #design-review and paste the thread link into the
  issue as a comment.

## extra-checks

- Name the designer who has to react, and say the prototype is parked until
  they do.

What it never does

It never fetches anything at runtime. Nothing in it is copied into src/ without being rewritten: it is a drawing, not a component. It never leaves two attachments both claiming to be the current prototype, and it never touches an issue's status, assignee or labels.