getdesign
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 design system from a URL", "extract brand tokens", "write a design.md", clone a site's style, or reverse-engineer a design system from a live page. Triggers on phrases like "design spec", "style guide from URL", "brand tokens", or any request that pastes a URL and asks for a design document.
What this skill does
# getdesign
Generate 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.
## When to use
Activate when the user:
- Pastes a URL and asks for a "design system", "design spec", "style guide", `design.md`, or brand tokens.
- Asks to "make this look like <site>", "clone the design of <site>", or "extract the palette/typography from <site>".
- Asks you to reverse-engineer or document a live site's visual design.
Do **not** use this skill for: generating runnable code from a URL, Figma/Sketch export, auth-gated pages, or localhost.
## Output contract
The single deliverable is a markdown file — default name `design.md` — containing **exactly** these 9 H2 sections in this order:
1. Visual Theme & Atmosphere
2. Color Palette & Roles
3. Typography Rules
4. Component Stylings
5. Layout Principles
6. Depth & Elevation
7. Interaction & Motion
8. Responsive Behavior
9. Agent Prompt Guide
Full section schemas, field lists, and a worked example are in [TEMPLATE.md](TEMPLATE.md). Read it before writing the final file.
## Grounding rule (non-negotiable)
Every 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 `<link>`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.
Do not invent palette values. Do not hallucinate Tailwind classes the site does not use. Do not copy defaults from other sites.
## Workflow
Follow this sequence. Copy the checklist into your working notes and tick items as you go.
```
- [ ] 1. Validate URL
- [ ] 2. Fetch HTML + linked CSS
- [ ] 3. Capture at least one screenshot (hero viewport)
- [ ] 4. Extract tokens (colors, type, spacing, radii, shadows, breakpoints)
- [ ] 5. Draft DesignDoc (9 sections) grounded in tokens + screenshot
- [ ] 6. Render design.md from the draft
- [ ] 7. Verify grounding + section order, then write the file
```
### 1. Validate URL
Reject with a one-line explanation if the URL is not `https://`, is a private IP / localhost, or is clearly not a brand/product page.
### 2. Fetch HTML + linked CSS
Use your built-in web fetch tool (`WebFetch`, `web.run`, `fetch`, `curl` via shell — whatever you have).
- Fetch the HTML.
- From the HTML, resolve every `<link rel="stylesheet">` href (absolute + relative) and fetch each one.
- Follow `@import url(...)` chains one level deep.
- Capture any `@font-face` blocks for font family + weight discovery.
- Cap each stylesheet at ~200 KB; prefer files containing `:root`, CSS variables, or utility-class declarations.
- 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 `<html>` / `<body>`.
- If the site supports both modes, collect grounding for both and keep notes on which tokens are shared versus mode-specific.
Record the exact URLs you fetched — you will cite them in the "Sources" section of your draft (internal, not in the final markdown).
### 3. Screenshot the page
If 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.
- If the site exposes a theme toggle, use the browser to capture both modes.
- If there is no explicit toggle, still check browser-emulated `prefers-color-scheme: light` and `prefers-color-scheme: dark` when possible.
- Keep mode labels in your notes so you know which observations came from light mode vs dark mode.
If 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).
### 4. Extract tokens
Deterministically 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.
Produce an internal `DesignTokens` object with:
- `colors`: `primary[]`, `accent[]`, `neutral[]`, `semantic { success, warning, error, info }`, `surfaces[]`, `borders[]`.
- Every entry is `{ hex, role, source }` where `source` is the CSS selector or variable name you found it in.
- If the site supports multiple themes, annotate whether each token is `light`, `dark`, or shared.
- `typography`: `fontFamilies[]` (display / body / mono), `scale[]` (`{ role, px, weightRange, lineHeight, letterSpacing }`).
- `spacing`: the step values actually used (e.g. 4, 8, 12, 16, 24, 32, 48, 64 px).
- `radii`: named scale you can infer (`sm`, `md`, `lg`, `pill`).
- `shadows`: each `box-shadow` you observed, with a role guess.
- `borders`: widths and colors.
- `breakpoints`: min-widths in `@media` queries.
If a CSS value has low frequency (< 2 occurrences) and no variable name, treat it as incidental and exclude it from the palette.
### 5. Draft the DesignDoc
Using 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.
Key per-section reminders:
- **Visual Theme** — 2–4 short paragraphs plus a `keyCharacteristics` bullet list (5–8 items).
- **Color Palette & Roles** — every color as a table row: `| Hex | Role | Where seen |`. Group by primary / accent / semantic / surfaces / borders.
- **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.
- **Component Stylings** — buttons (primary/secondary/ghost), cards, inputs, navigation, image treatment, 2–4 distinctive components you actually saw.
- **Layout Principles** — spacing scale, grid / max-widths, whitespace philosophy, radius scale.
- **Depth & Elevation** — named elevation levels with their shadow values and a 1-sentence philosophy.
- **Interaction & Motion** — hover states, focus states, transition durations/easings you observed or can infer. Mark inferences explicitly.
- **Responsive Behavior** — breakpoint table from the `@media` queries, touch-target minimum, how navigation collapses, image behavior.
- 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.
- **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.
### 6. Render to markdown
Assemble the draft into a single markdown document. Use:
- H1 for the site name (`# <Brand> Design System`).
- H2 for each of the 9 sections in the exact order above.
- GitHub-flavored tables for palette, typography, breakpoints.
- Fenced code blocks only for concrete CSS/token examples, never to wrap prose.
### 7. Verify, then write
Before writing the final file, run this self-check:
- [ ] All 9 H2 section headings are present, in the exact order, spelled as listed.
- [ ] Every hex code in the Color Palette section appears in your internal notes with a CSS source.
- [ ] The font families in Typography appear in the fetched CSS or `@font-face` blocks.
- [ ] Breakpoints match actual `@media (min-width: …)` queries.
- [ ] Light mode and dark mode were both checked whenever the site exposes or implies dual-theme support.
- [ ] A browser screenshot was takenRelated in Ads & Marketing
ads
IncludedMulti-platform paid advertising audit and optimization skill. Analyzes Google, Meta, YouTube, LinkedIn, TikTok, Microsoft, and Apple Ads. 250+ checks with scoring, parallel agents, industry templates, and AI creative generation.
banana
IncludedAI image generation Creative Director powered by Google Gemini Nano Banana models. Use this skill for ANY request involving image creation, editing, visual asset production, or creative direction. Triggers on: generate an image, create a photo, edit this picture, design a logo, make a banner, visual for my anything, and all /banana commands. Handles text-to-image, image editing, multi-turn creative sessions, batch workflows, and brand presets.
rpg-migration-analyzer
IncludedAnalyzes legacy RPG (Report Program Generator) programs from AS/400 and IBM i systems for migration to modern Java applications. Extracts business logic from RPG III/IV/ILE source code, identifies data structures (D-specs), file operations (F-specs), program dependencies (CALLB/CALLP), and converts RPG constructs to Java equivalents. Generates migration reports, complexity estimates, and Java implementation strategies with POJO classes, JPA entities, and service methods. Use when modernizing AS/400 or IBM i legacy systems, analyzing RPG source files (.rpg, .rpgle, .RPGLE), converting RPG to Java, mapping data specifications to Java classes, planning legacy system migration, or when user mentions RPG analysis, Report Program Generator, RPG III/IV/ILE, AS/400 modernization, IBM i migration, packed decimal conversion, or mainframe application rewrite.
brand-library-architect
IncludedBuild a complete brand library for a product — visual asset render pipeline, brand documentation set (BRAND, COPY, MANIFESTO, BIOS, FAQ, GLOSSARY, TONE, PRICING), open-source convention files (README, CONTRIBUTING, SECURITY, CODE_OF_CONDUCT), and a self-contained press kit. This skill should be used when the user asks to "build a brand library / brand kit / press kit / brand assets" for a product, "set up a brand library workflow," "create a positioning manifesto plus visual identity," or any combination of brand documentation + visual asset pipeline. Apply phase-by-phase or run end-to-end. Templates are product-agnostic and use {{TOKEN}} placeholders the skill prompts the user to fill.
writing-tech-post
IncludedAuthors engineering blog posts end-to-end: launch deep-dives, incident postmortems, architecture migrations, performance case studies, tutorials, AI/agent system writeups, security disclosures, and research-to-product translations. Picks the correct archetype, plans the abstraction ladder, enforces an evidence cadence (diagrams, benchmarks, profiles, traces, code, ablations), tunes voice against publisher house styles (Datadog, Vercel, GitHub, AWS, Meta, Cloudflare, Jane Street), and runs a pre-publish gate for narrative momentum and disclosure ethics. Use when drafting a new engineering post, restructuring a draft that feels flat, deciding which evidence form belongs where, validating that depth and product context are balanced, or preparing a postmortem, migration, or performance narrative for external publication. Do not use for API reference documentation, README authoring, marketing copy, release notes, generic SEO content, ghost-written executive thought leadership, or non-engineering long-form essays.
blog-google
IncludedGoogle API integration for blog performance: PageSpeed Insights, CrUX Core Web Vitals with 25-week history, Search Console performance, URL Inspection, Indexing API, GA4 organic traffic, NLP entity analysis for E-E-A-T, YouTube video search for embedding, and Google Ads Keyword Planner. Progressive feature availability based on credential tier (API key, OAuth/service account, GA4, Ads). Shares config with claude-seo at ~/.config/claude-seo/google-api.json. Use when user says "google data", "page speed", "core web vitals", "search console", "indexation", "GA4", "keyword research", "nlp entities", "blog performance", "youtube search", "google api setup".