{"id":"733327a8-52cd-46ef-96e7-b355ea79bd7b","shortId":"XD2pYQ","kind":"skill","title":"getdesign","tagline":"Turn any public URL into a production-grade 9-section design.md spec (colors, typography, components, layout, depth, motion, responsive, prompt guide) using the agent's own built-in tools — WebFetch, browser/screenshot, and file writes. Use when the user asks to \"generate a desig","description":"# getdesign\n\nGenerate a grounded, production-grade `design.md` for any public URL using the coding agent's own tools. This skill is the portable twin of the hosted [getdesign.app](https://getdesign.app) agent — same 9-section output, no sandbox required.\n\n## When to use\n\nActivate when the user:\n\n- Pastes a URL and asks for a \"design system\", \"design spec\", \"style guide\", `design.md`, or brand tokens.\n- Asks to \"make this look like \", \"clone the design of \", or \"extract the palette/typography from \".\n- Asks you to reverse-engineer or document a live site's visual design.\n\nDo **not** use this skill for: generating runnable code from a URL, Figma/Sketch export, auth-gated pages, or localhost.\n\n## Output contract\n\nThe single deliverable is a markdown file — default name `design.md` — containing **exactly** these 9 H2 sections in this order:\n\n1. Visual Theme & Atmosphere\n2. Color Palette & Roles\n3. Typography Rules\n4. Component Stylings\n5. Layout Principles\n6. Depth & Elevation\n7. Interaction & Motion\n8. Responsive Behavior\n9. Agent Prompt Guide\n\nFull section schemas, field lists, and a worked example are in [TEMPLATE.md](TEMPLATE.md). Read it before writing the final file.\n\n## Grounding rule (non-negotiable)\n\nEvery concrete value — hex color, font family, font size, spacing number, radius, shadow, breakpoint — **must** be traceable to something you actually fetched: a CSS rule, a computed style, a ``ed stylesheet, a `:root` variable, or a visible pixel in a screenshot. If you cannot ground a value, describe the role qualitatively (\"neutral warm gray\") instead of fabricating a hex.\n\nDo not invent palette values. Do not hallucinate Tailwind classes the site does not use. Do not copy defaults from other sites.\n\n## Workflow\n\nFollow this sequence. Copy the checklist into your working notes and tick items as you go.\n\n```\n- [ ] 1. Validate URL\n- [ ] 2. Fetch HTML + linked CSS\n- [ ] 3. Capture at least one screenshot (hero viewport)\n- [ ] 4. Extract tokens (colors, type, spacing, radii, shadows, breakpoints)\n- [ ] 5. Draft DesignDoc (9 sections) grounded in tokens + screenshot\n- [ ] 6. Render design.md from the draft\n- [ ] 7. Verify grounding + section order, then write the file\n```\n\n### 1. Validate URL\n\nReject with a one-line explanation if the URL is not `https://`, is a private IP / localhost, or is clearly not a brand/product page.\n\n### 2. Fetch HTML + linked CSS\n\nUse your built-in web fetch tool (`WebFetch`, `web.run`, `fetch`, `curl` via shell — whatever you have).\n\n- Fetch the HTML.\n- From the HTML, resolve every `` href (absolute + relative) and fetch each one.\n- Follow `@import url(...)` chains one level deep.\n- Capture any `@font-face` blocks for font family + weight discovery.\n- Cap each stylesheet at ~200 KB; prefer files containing `:root`, CSS variables, or utility-class declarations.\n- Always check for both light and dark mode support while fetching. Look for `prefers-color-scheme`, `.dark`, `[data-theme]`, theme toggle controls, alternate theme stylesheets, or server-rendered theme classes on `` / ``.\n- If the site supports both modes, collect grounding for both and keep notes on which tokens are shared versus mode-specific.\n\nRecord the exact URLs you fetched — you will cite them in the \"Sources\" section of your draft (internal, not in the final markdown).\n\n### 3. Screenshot the page\n\nIf your agent runtime has a browser tool (Playwright, Chrome DevTools, `agent-browser`, Antigravity browser, Codex web browser, a `screenshot` tool, etc.), you **must** use it. Open the URL at **1440×900** and capture screenshots for every available theme mode you can verify, starting with light mode and dark mode. Prefer a full-page scroll-and-stitch if available.\n\n- If the site exposes a theme toggle, use the browser to capture both modes.\n- If there is no explicit toggle, still check browser-emulated `prefers-color-scheme: light` and `prefers-color-scheme: dark` when possible.\n- Keep mode labels in your notes so you know which observations came from light mode vs dark mode.\n\nIf you have no browser tool, skip this step — continue with CSS-only grounding — and note the limitation in your internal planning (the \"Visual Theme\" prose will be slightly thinner without a screenshot).\n\n### 4. Extract tokens\n\nDeterministically parse the CSS. Prefer CSS variables (`--color-primary`, `--radius-lg`) and `:root` blocks as the source of truth. Fall back to frequency analysis of literal values.\n\nProduce an internal `DesignTokens` object with:\n\n- `colors`: `primary[]`, `accent[]`, `neutral[]`, `semantic { success, warning, error, info }`, `surfaces[]`, `borders[]`.\n - Every entry is `{ hex, role, source }` where `source` is the CSS selector or variable name you found it in.\n - If the site supports multiple themes, annotate whether each token is `light`, `dark`, or shared.\n- `typography`: `fontFamilies[]` (display / body / mono), `scale[]` (`{ role, px, weightRange, lineHeight, letterSpacing }`).\n- `spacing`: the step values actually used (e.g. 4, 8, 12, 16, 24, 32, 48, 64 px).\n- `radii`: named scale you can infer (`sm`, `md`, `lg`, `pill`).\n- `shadows`: each `box-shadow` you observed, with a role guess.\n- `borders`: widths and colors.\n- `breakpoints`: min-widths in `@media` queries.\n\nIf a CSS value has low frequency (< 2 occurrences) and no variable name, treat it as incidental and exclude it from the palette.\n\n### 5. Draft the DesignDoc\n\nUsing tokens + screenshot + your reading of the HTML structure, draft each of the 9 sections. Structure matters more than prose length. Read [TEMPLATE.md](TEMPLATE.md) for field-by-field requirements.\n\nKey per-section reminders:\n\n- **Visual Theme** — 2–4 short paragraphs plus a `keyCharacteristics` bullet list (5–8 items).\n- **Color Palette & Roles** — every color as a table row: `| Hex | Role | Where seen |`. Group by primary / accent / semantic / surfaces / borders.\n- **Typography Rules** — one `fontFamily` summary paragraph, then a hierarchy table: `| Role | Font | Size | Weight | Line height | Letter spacing |` with roles at least for Display, H1, H2, H3, Body, Small, Mono.\n- **Component Stylings** — buttons (primary/secondary/ghost), cards, inputs, navigation, image treatment, 2–4 distinctive components you actually saw.\n- **Layout Principles** — spacing scale, grid / max-widths, whitespace philosophy, radius scale.\n- **Depth & Elevation** — named elevation levels with their shadow values and a 1-sentence philosophy.\n- **Interaction & Motion** — hover states, focus states, transition durations/easings you observed or can infer. Mark inferences explicitly.\n- **Responsive Behavior** — breakpoint table from the `@media` queries, touch-target minimum, how navigation collapses, image behavior.\n- If both light and dark mode exist, call out the major theme differences in the relevant sections instead of silently collapsing them into one palette.\n- **Agent Prompt Guide** — a quick color reference (just the key hexes), 3 example prompts another AI could use to replicate this style, and 4–6 iteration tips.\n\n### 6. Render to markdown\n\nAssemble the draft into a single markdown document. Use:\n\n- H1 for the site name (`# Design System`).\n- H2 for each of the 9 sections in the exact order above.\n- GitHub-flavored tables for palette, typography, breakpoints.\n- Fenced code blocks only for concrete CSS/token examples, never to wrap prose.\n\n### 7. Verify, then write\n\nBefore writing the final file, run this self-check:\n\n- [ ] All 9 H2 section headings are present, in the exact order, spelled as listed.\n- [ ] Every hex code in the Color Palette section appears in your internal notes with a CSS source.\n- [ ] The font families in Typography appear in the fetched CSS or `@font-face` blocks.\n- [ ] Breakpoints match actual `@media (min-width: …)` queries.\n- [ ] Light mode and dark mode were both checked whenever the site exposes or implies dual-theme support.\n- [ ] A browser screenshot was taken whenever a browser tool was available.\n- [ ] No placeholder text like \"TBD\", \"(example)\", or \"Lorem ipsum\".\n\nIf any check fails, fix before writing. Then write the file to `design.md` (or the path the user requested). Report a one-paragraph summary plus the absolute file path.\n\n## Handling missing capabilities\n\n| Missing tool | Degrade to |\n| --- | --- |\n| No browser / screenshot | CSS-only grounding; keep the Visual Theme brief and fact-based. Skip pixel-level observations. If dual themes exist, still inspect fetched CSS for both light and dark mode selectors. |\n| Fetch blocked (403 / Cloudflare) | Report the failure, try the site's `/` and `/about` as alternates, otherwise stop and surface the error to the user. No guessing. |\n| CSS-in-JS only, no stylesheets | Parse inline `