# 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-table skill="rd-prototype">
</hook-table>

## 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.