For robots

retrostrap is designed to be machine-legible. A huge share of pages get built by coding assistants now, and left alone, a model asked for "a retro website" produces a modern layout with Comic Sans on top. Given a closed vocabulary of rs- classes, a legal palette, an easing whitelist, and an auditor, it cannot drift modern, the same constraints that keep humans on-era keep machines on-era. So we publish the whole framework in formats a machine can eat:

C:\> dir

 Volume in drive C is RETROSTRAP
 Directory of C:\

 LLMS.TXT       the entry point, per the llms.txt convention
 CHEATSHT.MD    every class on one page, the file to load into a context window
 MANIFEST.JSN   the full catalog, structured: classes, snippets, themes, laws
 GUARDRLS.JSN   the five laws as data, validate against this, don't parse prose
 PROMPT.TXT     the canonical system prompt, paste it into your assistant

        5 file(s)     copied freely
        0 dir(s)      all of it regenerated per release, never hand-maintained

The system prompt

Paste this into your assistant's instructions and go, it is PROMPT.TXT above, the canonical prompt for the current release, generated from the catalog with everything else so it never drifts:

C:\> type PROMPT.TXT

You are building a web page with retrostrap v0.1.0, a framework that
makes pages look like the 1996-2003 web while staying responsive and
accessible.

Hard rules, violating any of these breaks the page's era-fidelity:
1. Use only documented rs- classes for UI. Do not write custom CSS unless
   asked; if you must, obey: colors from the 216 web-safe + 16 named set
   only; border-radius 0; shadows with 0 blur; easing only linear or
   steps(); fonts only via --rs-font-* tokens.
2. Structure: <body> gets the theme tile; wrap content in
   <div class="rs-page rs-container">. Pick ONE layout recipe
   (rs-layout--sidebar-left, --holy-grail, rs-frames…). Real landmarks:
   header, nav, main, footer. Headings h1-h6 in order.
3. Pick ONE theme via data-rs-theme on <html>. Do not mix theme files.
4. Widgets (the Toybox): at most TWO decorative widgets per page,
   declared via data-rs-widgets="…" on any element, with their
   data-rs-<widget>-<option> attributes. Never add autoplaying audio.
   Never add tracking.
5. Keep text sizes on the rs-font-1..7 scale. Links stay underlined. Use
   rs-pagination, never infinite scroll. Use tables for data with rs-table.
6. Copy tone: enthusiastic 1999 webmaster, no modern marketing speak, no
   emoji (use the smilies widget). Tildes and ASCII dividers welcome.
7. Accessibility is non-negotiable: alt text everywhere, label every
   input, don't remove focus outlines, respect the component snippets' ARIA.

Process: 1) choose theme + layout recipe; 2) compose from cheatsheet
snippets; 3) add up to two widgets; 4) self-check against the rules above
(they mirror Retrostrap.audit()).

The loop

Generation without verification drifts. The loop we support:

Generate against the cheatsheet or the manifest.
Run Retrostrap.audit() in the page, it returns JSON violations, and its hint strings are written to be actionable by a model ("off palette; nearest legal is #FF9966").
Feed the violations back; regenerate. Repeat until the audit reports all lawful.

Everything above is generated from the same catalog that builds the framework, major-pinned CDN URLs (while we are on 0.x that means @0 tracks updates; pin the exact version for production, as get started says), since and stability on every entry, so what a machine copies today still resolves tomorrow.

Or skip the copy-paste

There is an MCP server, retrostrap-mcp on npm, that hands your assistant the catalog as callable tools: search components and widgets, fetch a snippet or a theme, and run the same law-check on the HTML it just wrote, the auditor's actionable hints, without a browser. It reads the manifest above, so it never drifts from the framework. One line to run it, no checkout needed:

C:\> npx retrostrap-mcp

retrostrap-mcp speaks MCP over stdio; the catalog ships inside.
Point any MCP client at it with a command/args stanza:

{
  "mcpServers": {
    "retrostrap": {
      "command": "npx",
      "args": ["retrostrap-mcp"]
    }
  }
}

From a checkout it reads the repo's dist/manifest.json instead; the full setup lives at services/mcp/.

Or keep the rules in your repo

If you build on retrostrap with a coding assistant, drop a template into your project so the laws ride along on every turn, no re-pasting, and it keeps the assistant honest when it starts extending the framework, not just composing pages:

C:\> dir TEMPLATES

 AGENTS.MD      the full rules, Cursor, Windsurf, Zed, Aider… (repo root)
 CLAUDE.MD      Claude Code, a two-line @-import of AGENTS.md (repo root)
 COPILOT.MD     GitHub Copilot, the compact form (.github/copilot-instructions.md)

They teach the stable parts, the five laws, the rs-/rsx- namespaces, the audit loop, and point back at the surfaces above for what changes. Also in the npm package under templates/.

Or lint your own CSS

When your assistant writes custom CSS, the stylelint-retrostrap plugin holds it to the palette, shape, and easing laws at lint time. It reads guardrails.json, the same laws as data, so it never disagrees with the framework: the auditor catches drift in the browser, the plugin catches it before you ship.

This page is best viewed by any user agent.