hostinger-api-mcp 3.17.2 → 3.17.3

package/CHANGELOG.md

@@ -4,6 +4,13 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.17.3 — 2026-10-28
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/05-design/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.17.2 — 2026-10-27
 
 ### Also in this release

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.17.2",
+  "version": "3.17.3",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.17.2",
+  "version": "3.17.3",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.17.2",
+  "version": "3.17.3",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.17.2",
+      "version": "3.17.3",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/steps/05-design/SKILL.md

@@ -301,6 +301,27 @@ package names. The **display** family must also resolve as a static package
 (`npm view @fontsource/<slug> version`): the static packages ship `.woff` files the logo kit can
 read; the variable ones ship only `.woff2`.
 
+### 5.5 The header fits on one line
+
+The header is where a cramped width shows first: the logo, every nav item and the call-to-action
+button share one row, and when they run out of room they wrap mid-phrase ("Services &" over
+"Pricing", "Book" over "Appointment"). That always looks broken. Decide it here so the frontend
+can't build it that way.
+
+- **Labels never break mid-phrase.** Nav links and the header button get `white-space: nowrap`, so a
+  two-word label stays on one line or not at all.
+- **Collapse before it wraps — not at 320 px.** The inline nav is replaced by a menu (hamburger)
+  button at the width where the logo, all nav items and the button stop fitting on one line, which is
+  usually wider than the mobile breakpoint. Estimate that width from the number of nav items and their
+  label lengths, round up to a multiple of 8, and make it the header's own breakpoint. Below it, only
+  the logo and the menu button show; the nav items and the CTA move into the opened menu.
+- **Keep header labels short.** A nav label is one or two short words; a button label is a two-word
+  verb phrase at most ("Book now", not "Book an Appointment"). When the content model gives a long
+  navigation label, the header may show a shorter form ("Contact & Booking" → "Contact") while the
+  page keeps its full name — note the shortened label in the **Header + nav** row.
+- Record the header breakpoint in *Grid, shape & motion* and the `nowrap` + collapse rule in the
+  **Header + nav** component row (and its `≤ 320 px` cell).
+
 ## Step 6 — Design the logo
 
 **The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and
@@ -525,7 +546,7 @@ prefers-reduced-motion".>
 ## Components
 | Component | Renders (from content model) | Look | ≤ 320 px |
 |---|---|---|---|
-| Header + nav | Navigation items | … | … |
+| Header + nav | Navigation items | … Nav links and the button never wrap (`white-space: nowrap`); the inline nav collapses to a menu button at <px> (the width it stops fitting one line). | Logo + menu button only; nav items and CTA inside the menu |
 | Post card | Article: image, category, title, excerpt | … | … |
 | … | | | |
 
@@ -549,6 +570,9 @@ duotone…); alt text written from what the photo shows.>
   exemptions.
 - **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand
   colours keep their hue but only appear in roles where they pass.
+- **The header never wraps.** Nav labels and the header button stay on one line (`white-space:
+  nowrap`); the inline nav collapses to a menu button at the width it stops fitting, not only at the
+  mobile breakpoint (5.5).
 - **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.
 - **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,
   emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no

package/src/core/skills.js

@@ -218,10 +218,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/05-design/SKILL.md",
-        "digest": "sha256:77fae3ed1e68f8634ee667a5d5d0a6c202b5f9e109d14c9cb34a717c77a47b80",
-        "size": 37794,
+        "digest": "sha256:688891726ec9d42e6a69c53fbdd855fb3b8c046927c622948f23e79ebd7ffea4",
+        "size": 39762,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-design\ndescription: \"Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend.\"\n---\n\n# headless-step-design\n\nTurn the brief into a look the user has chosen, and write it down so the frontend can't drift from\nit. **One question, three options, one spec.** The output is **files** (`design.md` plus the logo),\nnot a conversation: the frontend step implements `design.md`, not the chat.\n\n**In:** `brief.md` (required), `content-model.md` (if it exists yet), reference sites and assets the\nuser gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in\n`~/.hostinger/<domain>/brand/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? This step defers to the user\n> Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the\n> design — **do not generate three directions or write a prescriptive `design.md` over their project.**\n> The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*\n> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when\n> **Design direction** keeps the look of the app in this folder: their own code already carries it.\n> Either write nothing, or capture only what the user explicitly asks for (a short note of their\n> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow\n> moves on to frontend. The logo and token work here apply only when **Build mode is \"Agent designs\n> and builds\"**.\n\nThis is **prepare work**: it runs while provision settles (see *Background provision & the instance\nbarrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.\n\n**Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user\n**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three\ndirections (Step 4), never both. \"You decide\" is a valid answer.\n\n**Talk like a person, not a designer.** Everything the user reads describes how the site will\n**look and feel**: colours by name (\"hot pink, butter yellow\"), lettering by feel (\"big chunky\nrounded headlines\"), and the details they'll notice (\"photos tilted like stickers on a scrapbook\").\nNo hex codes, font names, or design and tech words (palette, accent, tokens, shape language,\ncontrast, favicon, wordmark, lockup, WCAG, 8-point grid, Next.js, SSR, `state.json`), even when\nthe owner's own brand guide names them. This covers every message until the step ends, including\nthe keep/change question, your one-line confirmation after the pick and the message you hand off\nwith.\n\n**Two hard rules apply to every direction, however loud or quiet it is:**\n\n- **The 8-point grid.** Every spacing, sizing and layout value is a multiple of 8 px (details in\n  5.2).\n- **WCAG 2.2 Level AA.** Colour, focus, motion, target size and reflow are decided here, so the\n  frontend can't build them wrong (details in 5.1 and 5.3).\n\nThese rules are for you, not the user. **Never mention them**: no grid, contrast, WCAG or\naccessibility talk in anything the user reads, and no \"all options follow…\" reassurances. The user\njudges the look in the preview; the rules just make sure it works.\n\n---\n\n## Step 1 — Read the workspace, then the resume check\n\nRead `brief.md`, `state.json`, and `content-model.md` if it exists.\n\n- **`design.md` already exists and this is not a redesign** → don't overwrite it. Describe the\n  current look in two or three plain sentences and ask: *keep it, or change something?* That is this\n  step's one question.\n  - **Keep** → leave the file alone and go straight to the `state.json` update at the end of Step 7.\n  - **Change** → edit only what they asked for, re-run the 5.x checks on what changed, then save.\n- **The site is already deployed** (`deploy.json` exists, or `state.json` has `deployed_at`) and the\n  user asked for a different look → this is a **redesign**. Tell them plainly: their content stays\n  as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7\n  as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user\n  wants to keep and move away from the rest.\n- **The brief says to keep the current look** (*Design direction* says so in the owner's words:\n  \"keep the look we have\", \"same look, new platform\") → follow *Keep the current look* below instead\n  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone\n  are signals for Step 2, not a request to keep.\n\n### Keep the current look\n\n1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method\n   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its\n   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save\n   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;\n   a logo seen only in a screenshot counts as no logo file, so list \"logo file needed\" under gaps in\n   the final report. The app in this folder (the path under `brief.md` → **Existing project**):\n   read its source; no build or browser needed.\n   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,\n     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with\n     the page background and body text taken from the root layout or `body`.\n   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or\n     `@import`, and the `font-family` on `body` and headings.\n   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;\n     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon\n     declared by `<link rel=\"icon\">` in `index.html` or the root layout's `metadata.icons`. Copy them\n     unchanged into `brand/`.\n\n   Files or exact colours and fonts the owner supplied win over anything you read.\n2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or\n   change something?* \"Keep the look we have\" still gets this question; skip it only when the brief\n   says to change nothing at all (\"keep it exactly as it is\"). A skipped tool result is not Keep; see\n   *When you ask the user* in the top-level `SKILL.md`. Change →\n   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.\n3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a\n   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font\n   without an `@fontsource` package swaps to the closest one that resolves (5.4).\n4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no\n   existing logo, the header shows the site name as text in the kept display font, and no logo is\n   designed.\n5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:\n   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say \"No favicon kept\".\n   - *Built from* says \"Kept, not rebuilt\". *Measured* still gives the width at `--logo-h-sm`\n     (≤ 192 px; else lower `--logo-h-sm` or show the name as text on small screens), and the header\n     link has `alt` = the site name and a target of at least 24 px (as in Step 6).\n   - With no logo: *Files* says \"None\", *Use* says the header link holds the site name as text in\n     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.\n\n## Step 2 — Collect the signals\n\nBefore inventing anything, gather what already constrains the design:\n\n| Signal | Where | How it constrains |\n|---|---|---|\n| Tone, purpose, audience | `brief.md` → *Tone*, *Purpose*, *Audience* | Sets the mood all three directions must fit |\n| Brand assets | `brief.md` → *Assets* | Logo, brand colours and fonts are **fixed** in every direction. Never recolour a supplied logo; Step 6 uses it instead of designing one |\n| Pages and entities | `content-model.md` → *Navigation*, *Pages*, *Articles*; if it doesn't exist yet, `brief.md` → *Pages* | Drives the component inventory and page composition |\n| Reference sites | URLs in the brief or the conversation | Cues to borrow (see below) |\n| Images already sourced | `content-model.md` → the image lines under *Articles* (skip if none yet) | Glance at a few at small size; keep accents from clashing with their dominant colours |\n| Current design (redesign only) | existing `design.md` | What to keep, what to move away from |\n\n**Reference sites.** Open each one in a real browser if you have one. Static fetches are often\nblocked or rate-limited; without a browser, fetch the HTML and its linked CSS instead. If neither\nworks, say so in one line and continue from the brief alone. Pull **cues**:\n\n- **Fonts:** the computed `font-family` of `h1`/`h2` and of body `p`.\n- **Colours:** background colours weighted by painted area (element width × height), the top 5–8.\n  Skip transparent and semi-transparent backgrounds and overlays (cookie banners, modals, chat\n  widgets). Text colours come from headings, paragraphs and links.\n- **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in\n  the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.\n\n**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).\nDon't use its logo, copy, images or exact layout. **The brief wins** over the live site when they\ndisagree (the user's words are what they want). Note the mismatch in the direction.\n\n**Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand\nyellow can be a background band or a large decorative shape, never body text. Say so in the\ndirection.\n\n## Step 3 — Derive three directions\n\nWrite three directions that **all fit the brief** but are **genuinely different**. Vary at least two\nof: palette (temperature, saturation, light vs. dark), type personality (geometric, grotesk, serif,\ndisplay), and shape language (sharp vs. round, flat vs. outlined, airy vs. dense). Three shades of\none idea is not a choice. Neither is a wildcard that ignores the brief.\n\nOrder them: **A is the recommendation**, the closest reading of the brief and references. B and C\npush in different directions.\n\nEach direction carries exactly this:\n\n- **Name** — 2–3 evocative words (\"Sticker-book maximal\", \"Quiet gallery\").\n- **Mood** — one line on how the site feels.\n- **Palette** — 5–7 hex colours with roles (base, text, primary accent, secondary accents, surface).\n  These are the core colours the user sees; Step 5 may add derived shades (link, muted, error,\n  focus) as tokens.\n- **Type** — a display font and a body font, both self-hostable through `@fontsource`.\n- **Shape language** — corners, borders, shadows and density in one phrase (\"chunky 3 px ink\n  outlines, hard 8 px offset shadows, tilted cards\").\n- **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,\n  a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).\n- **Logo idea** — one line on how the name becomes a logo, using a move from Step 6 (\"letters\n  bounce in different colours and the O is a smiley\"). When the brief carries a logo wish (*Design\n  direction* or *Assets*), every direction's logo idea is that wish in its own style. A wish is words\n  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).\n\n**Only offer what can pass.** Before asking, run two quick gates on **all three**:\n\n1. **Contrast gate.** Every colour that will carry text (base, surfaces, and any accent used as a\n   text block) has a palette text colour reaching **4.5:1** on it. Two text colours are fine (dark on\n   light blocks, light on dark ones). Accents that only ever hold large text need 3:1.\n2. **Font gate.** Each font resolves on npm, and the display font also has a static `@fontsource`\n   package, because the logo is built from it (5.4).\n\nA direction that fails either gate gets adjusted, not offered as-is. Don't offer a look that only\nworks by breaking the rules, such as body text on a neon accent or a marquee that can't be stopped.\nLoud is fine; inaccessible is not.\n\n**Avoid the template look** unless the brief asks for neutral: Inter or Roboto everywhere, a\nblue-to-purple gradient hero, centred hero with three feature cards, grey cards on white. Every\ndirection should look like *this* site, not a starter theme.\n\n## Step 4 — Ask once\n\nAsk **one** question, with A marked as the recommendation. With a structured question UI (multiple\nchoice plus an \"other\" field), each option's **label** is the direction's name and its\n**description** is one or two plain sentences, under ~160 characters. Without one, write each\noption as one line in the same shape.\n\nThe description says what the site would feel like, the main colours by name, what the lettering\nis like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your\nnotes. The question may end with one plain clause saying they can add a logo idea to their pick, but\nnever suggest one or give an example: that idea would end up in the logo.\n\n> **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,\n> chunky headlines, tilted sticker photos and a bouncy logo with a smiley O.\n\n> **Midnight disco** — A dark, glowing night-out feel: deep purple with neon pink, yellow and\n> turquoise, heavy rounded headlines and a logo like a neon sign.\n\nThen:\n\n- **Pick** → use it as written, and confirm the look in one line.\n- **\"You decide\"** → use A, and tell them in one line which look you went with.\n- **Skipped tool result** → not an answer: write the three directions as plain lines\n  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).\n- **A mix** (\"A's colours with C's fonts\") → merge them. Don't ask again.\n- **Something else** → build a direction from what they said, run Step 5, and use it. Don't send\n  three new options.\n\n**Logo wish.** An answer can carry a logo idea next to the pick (\"A, and make the logo a little\nteapot\"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.\nWhenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms\nthe pick: *\"The logo follows your idea: a little teapot.\"* If the kit can't draw it as said (a\ndetailed illustration, a photo), build its closest kit version and name what you simplified in that\nsame line. Don't ask a follow-up.\n\nDon't ask about anything else in this step.\n\n## Step 5 — Check the chosen direction\n\nFix any problem found here by adjusting the direction, not by asking the user. Don't report these\nchecks or their fixes; the user sees the result in the preview.\n\n### 5.1 Contrast — WCAG 2.2 SC 1.4.3 and 1.4.11\n\n**Which pairs count:** walk the component inventory you're about to write (Components table). For\neach component, list every foreground/background combination in every state: default, hover,\nfocus, active, error. Include text on coloured bands (footer links on dark, marquee text, chips),\nplaceholder text and photo credits. Compute the WCAG contrast ratio for each:\n\n| Kind | Examples | Minimum |\n|---|---|---|\n| Body text | paragraphs, links, footer text, input text, placeholder text, captions | **4.5:1** |\n| Large text | ≥ 24 px regular, or ≥ 18.66 px (14 pt) bold | **3:1** |\n| Non-text | input and button boundaries (when the outline is the only edge), focus indicator against each adjacent colour, icons that carry meaning, chip outlines | **3:1** |\n\nA pair that fails gets a darker or lighter shade of the **same hue**; never drop a brand colour. A\nnew shade becomes a token (for example `--color-link` or `--color-muted`). Disabled controls and\npure decoration are exempt, but say which elements those are. **Text on photos** needs a scrim or\nsolid backing that gets the text to 4.5:1 against the lightest part of the image. If you can't\nguarantee that, don't put text on photos. Record every pair and its ratio in `design.md`.\n\n```js\n// node -e: relative luminance + contrast ratio, hex in → ratio out\nconst L = h => { const c = h.match(/\\w\\w/g).map(x => parseInt(x, 16) / 255)\n  .map(v => v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);\n  return 0.2126 * c[0] + 0.7152 * c[1] + 0.0722 * c[2]; };\nconst ratio = (a, b) => { const [x, y] = [L(a), L(b)].sort((m, n) => n - m); return (x + 0.05) / (y + 0.05); };\n```\n\n### 5.2 The 8-point grid\n\nValues are checked in px at the default 16 px root (`0.5rem` = 8 px).\n\n| What | Rule |\n|---|---|\n| Spacing (padding, margin, gap) | Multiples of 8: `8 16 24 32 48 64 96 128`. **4 px** is the only half-step, and only inside small components (chip padding, icon-to-label gap) |\n| Component sizes | Heights and fixed widths are multiples of 8. Buttons, nav items and inputs are **48 px** tall minimum |\n| Radii | `8 16 24 32`, or `999px` for pills. 4 px only on elements under 32 px tall |\n| Line heights | Fixed-size text: multiples of 8 (16/24, 18/32, 24/32), or of 4 for text ≤ 14 px (12/16, 14/20). Fluid headings (`clamp()` sizes) use a unitless line-height (1.0–1.2) and are exempt, because their line box can't stay on the grid at every size |\n| Fluid spacing | `clamp()` for spacing or sizes uses grid values at both ends. Fluid **font sizes** are exempt |\n| Shadow offsets | 4 or 8 multiples |\n| Layout | Content width, gutters and breakpoints are multiples of 8 (e.g. `1200`, `768`, `1024`, `1280`) |\n| Exempt | Border and outline widths (1–4 px), focus offset, font sizes, the `999px` pill radius, the 4-multiple line heights above, and anything that isn't a length (angles like a `-2deg` tilt, durations, opacity) |\n\nEvery value in the **Tokens** block must pass this table.\n\n### 5.3 WCAG 2.2 AA — what the design must decide\n\nThese criteria are settled at design time. Write each answer into the **Accessibility** section of\n`design.md`.\n\n| Criterion | The design must specify |\n|---|---|\n| 1.4.1 Use of colour | Links in running text are underlined, not colour-only. States (active nav, selected, error) also change shape, weight or an icon, not only colour |\n| 1.4.4 Resize text | Font sizes in `rem`; nothing breaks at 200 % zoom |\n| 1.4.10 Reflow | Works at **320 CSS px** wide with no horizontal scroll. Every component has a stated ≤ 320 px behaviour; decorative pieces never widen the page |\n| 1.4.12 Text spacing | No fixed-height boxes around text, so nothing clips when a user overrides spacing (line-height 1.5, paragraph spacing 2×, letter-spacing 0.12 em, word-spacing 0.16 em). Fixed line-height tokens are fine; clipping is not |\n| 2.2.2 Pause, Stop, Hide | Anything that moves on its own for more than 5 s (marquee, carousel, animated sticker) has a **visible pause control**, and doesn't move at all under `prefers-reduced-motion`. Hover-to-pause alone doesn't count |\n| 2.3.1 Three flashes | Nothing flashes more than 3 times a second |\n| 2.4.7 Focus visible | One focus style (e.g. 3 px outline, 2 px offset) whose colour reaches 3:1 against **every** surface it can appear on. Name a second colour for surfaces where the first fails |\n| 2.4.11 Focus not obscured *(new in 2.2)* | Sticky headers, cookie bars and chat bubbles never cover the focused element. Either the header isn't sticky, or `scroll-padding-top: var(--header-h)` |\n| 2.5.8 Target size *(new in 2.2)* | Interactive targets ≥ 24 × 24 px with spacing. On this grid: **48 px** for buttons, nav and inputs, ≥ 24 px for inline icon buttons |\n| 3.2.6 Consistent help *(new in 2.2)* | The contact or help link sits in the same place on every page (e.g. last nav item and footer) |\n| 3.3.2 Labels | Every form field has a visible label; placeholders are never the only label |\n| 1.1.1 Text alternatives | Content images get alt text describing what they show; purely decorative images and shapes get empty alt or `aria-hidden` |\n\n### 5.4 Fonts resolve\n\nFor each family, prefer the variable package and fall back to the static one:\n`npm view @fontsource-variable/<slug> version`, then `npm view @fontsource/<slug> version`. One must\nanswer with a version. If neither does, swap to the closest family that does. Record the exact\npackage names. The **display** family must also resolve as a static package\n(`npm view @fontsource/<slug> version`): the static packages ship `.woff` files the logo kit can\nread; the variable ones ship only `.woff2`.\n\n## Step 6 — Design the logo\n\n**The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and\nskip the rest of this step. Never redraw or recolour it.\n\nOtherwise, turn the name into a **designed** logo: shaped, coloured and composed. Typing the name in\nthe display font with an emoji or symbol next to it doesn't count. Build the chosen direction's **logo\nidea** (as replaced by any logo wish, Step 4) with one or two of these moves:\n\n| Move | What it is | Suits |\n|---|---|---|\n| **Letter swap** | One letter becomes a simple shape tied to the subject: O → smiley, sun, loaf, plate, eye; I → candle, pencil, brush; A → roof, tent. Swap **one character** only, even if the letter appears twice, and the word must still read | Playful, friendly brands |\n| **Bounce** | Letters tilt ±3–6° and bob off the baseline, each in a palette colour, with an ink outline and hard shadow | Loud, maximal directions |\n| **Stack** | The name split over 2–3 lines on coloured tiles, or set as a tight block | Long names, bold directions |\n| **Tag** | The main word large; a short second word on a pill, ribbon or tab | Two-part names (\"Dopamine Den\") |\n| **Seal** | The name around a ring, with a monogram or symbol in the middle | A secondary mark (footer, hero sticker, social avatar), never the header logo |\n| **Typographic contrast** | Weight, style or case contrast between words (a light italic word next to a heavy upright one), custom tight spacing, one shared stroke or cut between letters | Quiet, refined, editorial directions |\n\nNo emoji, clip-art, gradients, or details that vanish at small sizes. Colours come only from the\npalette (base and surface colours count).\n\n### Build it with the logo kit\n\nThe kit (`logo-kit.mjs`, next to this file) does the error-prone parts: it outlines letters into\nvector paths, sets text on a circle, draws the outline-and-shadow treatment, measures, validates\nthe output, checks the sizes and renders a preview. You write the composition. Copy the kit into\n`brand/` so the build is self-contained and a redesign can re-run it:\n\n```bash\nmkdir -p ~/.hostinger/<domain>/brand && cd ~/.hostinger/<domain>/brand\ncp <the folder this SKILL.md is in>/logo-kit.mjs .\nnpm init -y >/dev/null && npm i opentype.js @resvg/resvg-js @fontsource/<display-slug>\n```\n\nWrite `brand/logo-build.mjs`, import from `./logo-kit.mjs`, and always run it from `brand/`\n(packages resolve from the working directory):\n\n| Kit function | Use |\n|---|---|\n| `loadFont(slug, weight, style)` | Loads a static `@fontsource` weight across all its subsets (`latin`, `latin-ext`, …), so accented letters like Ė or Ł resolve; `style` is `'normal'` or `'italic'`. Throws if that weight or style isn't in the package, so pick another |\n| `layout(font, text, size)` | Kerned glyph positions, total width, `capHeight`, `xHeight`; place letters one by one for bounce or swap. Throws if a character isn't in the font |\n| `glyphPath(glyph, x, baselineY, size)` / `textPath(font, text, x, baselineY, size)` | Outlined path data for one letter or a whole word. For typographic contrast, load two weights or styles and set each word with `textPath` |\n| `pathBox(font, text, x, baselineY, size)` | Tight box around a word's outlines; size the viewBox from it plus room for outlines, shadows and tilt |\n| `arcText(font, text, { cx, cy, r, size })` | Letters around a circle, for seals |\n| `sticker(d, { fill, ink, strokeWidth, shadow, shadowColor, transform })` | Ink outline + hard offset shadow, for outlined directions. On dark backgrounds give the outline and shadow a palette colour that shows (`shadowColor` defaults to `ink`) |\n| `svgDoc({ width, height, title, body })` | Root SVG with `role=\"img\"` and a `<title>` |\n| `check(svg)` | Throws on `NaN`, live `<text>`, a missing title or viewBox, or an `&` that isn't an XML entity. Run it on every file before writing |\n| `tile(size, fill)` | The rounded tile for the mark and favicon; draw the symbol after it |\n| `widthBudget(letterHeight, height)` | The widest viewBox that still fits 192 px on small screens, for a logo of that height; see below |\n| `checkLogo({ logo, mark, favicon, letterHeight, background })` | Runs `check()` on all three files, checks their sizes and renders `brand/logo-preview.png`; see below |\n\nWrap every file in `svgDoc()`, never a hand-written `<svg>` or `<title>`: it escapes the site name,\nand one bare `&` (as in \"Salt & Pepper\") makes the browser show nothing.\n\nNever call opentype's `path.toPathData()` directly; the kit's serializer exists because opentype.js\n2.0 writes `NaN` into some paths, and browsers silently stop drawing at the first `NaN`.\n\n### Deliver four files\n\n| File | What | Must read clearly at |\n|---|---|---|\n| `brand/logo.svg` | The primary, mostly horizontal logo for the header | Its header display heights (desktop and small screens) |\n| `brand/logo-mark.svg` | A square icon from the same idea (initial, monogram or the swapped symbol) on a `tile()` in a palette colour | 32 px |\n| `brand/favicon.svg` | The simplest form of the mark: same tile, no shadow, no thin details, outlines thickened if it has any | 16 px, on both light and dark browser tab bars |\n| `brand/logo-build.mjs` | The script that built them, with `package.json`, kept so a redesign can adjust it | — |\n\nAdd `brand/logo-seal.svg` only if the direction uses a seal as a secondary mark. Delete\n`brand/node_modules` when you're done; a redesign runs `npm i` in `brand/` first.\n\n**Compose within the budget, so the first build passes.** The small-screen logo is at most 192 px\nwide with letters at least 16 px tall, so the whole logo can be only about 10–12 times as wide as\nits smallest letters are tall, whatever its height. On one line that's about ten letters plus a\nsymbol; a longer name stacks or tags, and a second word set at half size halves the room. Size the\nviewBox in `logo-build.mjs` against `widthBudget(letterHeight, viewBoxHeight)`, the exact limit at\nthe heights the kit picks; with your own `heights`, the FAIL line gives the limit. Draw the mark's\nsymbol from simple, recognisable shapes that still read at 32 px; fine natural forms like petals or\nleaves turn to mush.\n\n**Check the sizes and look at it after every build.** `letterHeight` is in viewBox units: the\n`xHeight` from `layout()` when the logo is mostly lowercase, `capHeight` when it's mostly capitals;\nfor mixed fonts, the smaller word's. End `logo-build.mjs` with:\n\n```js\ncheckLogo({ logo, mark, favicon, letterHeight, background: '<page background colour>' });\n```\n\nIt picks the header heights for you: `--logo-h-sm` is the smallest multiple of 8 that makes the\nletters 16 px, and `--logo-h` the same but at least 48 px, both at most 80 px, so a stacked lockup\nkeeps its words large or sets the mark beside them. Pass `heights: { desktop, small }` only when the\ndirection needs a larger header logo. It first prints `--logo-h`, `--logo-h-sm` and the **Measured**\nline for `design.md`, then PASS or FAIL for the logo's letters ≥ 16 px at both\nheights, width ≤ 192 px on small screens, headroom around everything drawn and heights in multiples\nof 8; for the mark and favicon sitting on a `tile()` with nothing clipped and room around\nthe symbol; and for no shadow on the favicon. Every FAIL names its fixes and the number to reach. It\nthen renders `logo-preview.png` (the logo at both heights on the page background, the mark at 32 px\nand favicon at 16 px on light and dark strips, each also enlarged), and throws if anything failed.\n\nThen read `logo-preview.png`; don't search for another renderer or read the SVG source. Rebuild only\nfor a FAIL line or something in the preview that reads wrong, such as collisions, a clipped or\nclearly off-centre mark, or a favicon detail that turns to mush, and fix everything you saw in one\nrebuild. Optical nudges of a few pixels and the header height aren't reasons to rebuild. A symbol\ngets one redraw: if it still reads wrong, replace it with a simpler form of the idea, such as the\ninitial, in the next build. If the kit says \"preview not rendered\", rely on the size check and list\n\"logo not visually checked\" under gaps in the final report.\n\nThe logo is exempt from text-contrast minimums, but the header link around it needs `alt` = the site\nname and a target of at least 24 px.\n\nDon't show the logo to the user in this step; they see it in the preview.\n\n## Step 7 — Write `design.md` and hand off\n\nWrite `design.md` from the template below. Fill every section. The **Tokens** block is copied\nverbatim into the frontend's global stylesheet, so it must be valid CSS. Every colour, font, type\nsize, line height, space, radius and shadow used elsewhere in the file must exist in it as a token.\nThe template's token list is the **minimum**: add what the design needs (`--color-error`,\n`--color-on-accent`, `--leading-h3`…) under the same naming scheme.\n**Breakpoints are the one exception**: CSS custom properties don't work inside `@media`, so they are\nlisted in *Grid, shape & motion* as plain px values.\n\nThen update `state.json`: set `\"stage\": \"frontend\"` (also for a redesign: restyle, then validate and\ndeploy) and `updated_at` to the current UTC time (ISO 8601). Don't touch `provision`, `run` or\n`history` (`run-log.mjs` owns those), or add other keys.\n\nIf content prepare hasn't sourced images yet, it now follows `design.md` → **Imagery** (see\n`04-content-model/SKILL.md`).\n\nHand off in one or two plain sentences, as *Talk like a person* says: \"The look is set: warm cream,\nbrown lettering, berry buttons and your loaf logo.\" Nothing after it: no font names, file names or\nstages, and gaps such as a missing icon file or a font that may not load go in the final report.\n\n## `design.md` template\n\n````markdown\n# Design — <domain>\n\n> Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,\n> <C name>). <\"Picked by the user.\" | \"User said 'you decide'; recommendation A used.\" |\n> \"Merged by the user: <what>.\"> — or, when kept: \"Kept the owner's current look from <site URL |\n> screenshots | brand guide>, confirmed on <YYYY-MM-DD>.\"\n\n## Direction\n<2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),\nthe signature element.>\n\n## Stack\n**<chosen by the frontend step>** — design doesn't decide the stack. The frontend step (06) picks and\nconfirms the framework (default Next.js SSR; ecommerce must be SSR) and records it in\n`state.json → frontend`. Leave this as a placeholder for the frontend step to fill in.\n\n## Tokens\n```css\n:root {\n  /* colour — semantic names, never \"--pink-2\" */\n  --color-base: #…;      --color-text: #…;      --color-surface: #…;    --color-muted: #…;\n  --color-primary: #…;   --color-accent-1: #…;  --color-accent-2: #…;   --color-link: #…;\n  --color-focus: #…;     --color-focus-alt: #…; /* for surfaces where --color-focus is < 3:1 */\n  /* type */\n  --font-display: '<Family> Variable', <fallback stack>;\n  --font-body: '<Family> Variable', <fallback stack>;\n  --text-body: …rem;   --leading-body: …rem;    /* 8-multiple in px */\n  --text-small: …rem;  --leading-small: …rem;   /* 4-multiple in px */\n  --text-h1: clamp(…rem, …, …rem);  --text-h2: clamp(…);  --text-h3: …rem;\n  --leading-display: 1.05;          /* unitless; fluid headings are grid-exempt */\n  /* 8-point grid */\n  --space-half: 4px;  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;  --space-4: 32px;\n  --space-6: 48px;    --space-8: 64px;  --space-12: 96px; --space-16: 128px;\n  --target-min: 48px;\n  /* shape */\n  --radius-sm: 8px;  --radius-card: …;  --radius-pill: 999px;\n  --border: …;  --shadow: …;  --shadow-hover: …;\n  --focus-ring: 3px solid var(--color-focus);  --focus-offset: 2px;\n  /* layout */\n  --content-max: …px;  /* multiple of 8 */\n  --header-h: …px;     /* header band height, multiple of 8; scroll-padding-top uses it if sticky */\n  --logo-h: …px;       /* header logo height on desktop, multiple of 8 */\n  --logo-h-sm: …px;    /* on small screens; logo ≤ 192 px wide at this height */\n}\n```\n\n## Palette roles\n| Token | Hex | Used for |\n|---|---|---|\n\n## Contrast\n| Foreground | Background | Kind (body text / large text / non-text) | Ratio | Needs | Passes |\n|---|---|---|---|---|---|\n\n## Type\n- **Display:** <family> (`@fontsource-variable/<slug>@<version>`), weights …, tracking …; sizes `--text-h1…h3`, `--leading-display`\n- **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch\n\n## Logo\n- **Concept:** <the move(s), and what any swapped letter or symbol stands for, plus \"From the owner:\n  '<their words>'\" only when it follows their wish | \"Supplied by the user\" | \"Kept from <source>\" |\n  \"No logo: owner kept the current look\" (header shows the site name as text in `--font-display`)>\n- **Built from:** `@fontsource/<display-slug>@<version>`, weight(s)/style(s) …\n- **Files:** `brand/logo.svg` (header, `--logo-h` desktop / `--logo-h-sm` small screens),\n  `brand/logo-mark.svg`, `brand/favicon.svg`<, `brand/logo-seal.svg`>; source `brand/logo-build.mjs`\n- **Measured:** letters … px tall at `--logo-h-sm`; width … px at `--logo-h-sm`\n- **Use:** the frontend copies `brand/*.svg` into `public/`. Header: `<a href=\"/\"><img src=\"/logo.svg\"\n  alt=\"<Site name>\" style=\"height: var(--logo-h)\"></a>` (switch to `--logo-h-sm` on small screens).\n  Favicon: `<link rel=\"icon\" href=\"/favicon.svg\" type=\"image/svg+xml\">`\n- **Don't:** recolour, stretch, add effects, or retype the logo as live text.\n\n## Grid, shape & motion\n<section padding desktop/mobile (space tokens), gutters, breakpoints in px (multiples of 8), borders,\nradii, shadows, hover behaviour, every animation and its pause control, and \"no motion under\nprefers-reduced-motion\".>\n\n## Accessibility (WCAG 2.2 AA)\n- **Focus:** <style; which colour on which surface>\n- **Targets:** <48 px controls; inline exceptions>\n- **Links & states:** <underline rule; how active/error states differ beyond colour>\n- **Motion:** <what moves, where its pause control is>\n- **Sticky elements:** <none | header uses --header-h + scroll-padding-top>\n- **Help:** <where the contact link sits on every page>\n- **Text on images:** <none | scrim spec and resulting ratio>\n- **Reflow:** <anything special at 320 px>\n- **Exempt from contrast:** <disabled controls / decorative shapes, named>\n\n## Components\n| Component | Renders (from content model) | Look | ≤ 320 px |\n|---|---|---|---|\n| Header + nav | Navigation items | … | … |\n| Post card | Article: image, category, title, excerpt | … | … |\n| … | | | |\n\n## Page composition\n- **<Page>** — <sections top to bottom, each naming its component and band colour>\n- …\n\n## Imagery\n<subjects, mood and colour fit for photos; search keywords; treatment (frame, crop ratio, radius,\nduotone…); alt text written from what the photo shows.>\n\n## Don'ts\n- <3–6 site-specific rules, e.g. \"no grey cards\", \"never put body text on the primary accent\">\n````\n\n## Invariants\n\n- **One question.** Refine owns discovery; this step only chooses among directions (or keeps the\n  existing look).\n- **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed\n  exemptions.\n- **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand\n  colours keep their hue but only appear in roles where they pass.\n- **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.\n- **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,\n  emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no\n  logo shows the site name as text and gets no new logo.\n- **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.\n- **The tokens block is the only source of values** (breakpoints excepted). Components and pages\n  reference tokens, never raw hex codes, pixel values or font names.\n- **No backend calls.** Design never waits on provision and never writes to the instance.\n- **Never overwrite an existing `design.md` silently.** Keep or change, as in Step 1.\n"
+        "text": "---\nname: headless-step-design\ndescription: \"Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend.\"\n---\n\n# headless-step-design\n\nTurn the brief into a look the user has chosen, and write it down so the frontend can't drift from\nit. **One question, three options, one spec.** The output is **files** (`design.md` plus the logo),\nnot a conversation: the frontend step implements `design.md`, not the chat.\n\n**In:** `brief.md` (required), `content-model.md` (if it exists yet), reference sites and assets the\nuser gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in\n`~/.hostinger/<domain>/brand/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? This step defers to the user\n> Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the\n> design — **do not generate three directions or write a prescriptive `design.md` over their project.**\n> The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*\n> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when\n> **Design direction** keeps the look of the app in this folder: their own code already carries it.\n> Either write nothing, or capture only what the user explicitly asks for (a short note of their\n> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow\n> moves on to frontend. The logo and token work here apply only when **Build mode is \"Agent designs\n> and builds\"**.\n\nThis is **prepare work**: it runs while provision settles (see *Background provision & the instance\nbarrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.\n\n**Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user\n**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three\ndirections (Step 4), never both. \"You decide\" is a valid answer.\n\n**Talk like a person, not a designer.** Everything the user reads describes how the site will\n**look and feel**: colours by name (\"hot pink, butter yellow\"), lettering by feel (\"big chunky\nrounded headlines\"), and the details they'll notice (\"photos tilted like stickers on a scrapbook\").\nNo hex codes, font names, or design and tech words (palette, accent, tokens, shape language,\ncontrast, favicon, wordmark, lockup, WCAG, 8-point grid, Next.js, SSR, `state.json`), even when\nthe owner's own brand guide names them. This covers every message until the step ends, including\nthe keep/change question, your one-line confirmation after the pick and the message you hand off\nwith.\n\n**Two hard rules apply to every direction, however loud or quiet it is:**\n\n- **The 8-point grid.** Every spacing, sizing and layout value is a multiple of 8 px (details in\n  5.2).\n- **WCAG 2.2 Level AA.** Colour, focus, motion, target size and reflow are decided here, so the\n  frontend can't build them wrong (details in 5.1 and 5.3).\n\nThese rules are for you, not the user. **Never mention them**: no grid, contrast, WCAG or\naccessibility talk in anything the user reads, and no \"all options follow…\" reassurances. The user\njudges the look in the preview; the rules just make sure it works.\n\n---\n\n## Step 1 — Read the workspace, then the resume check\n\nRead `brief.md`, `state.json`, and `content-model.md` if it exists.\n\n- **`design.md` already exists and this is not a redesign** → don't overwrite it. Describe the\n  current look in two or three plain sentences and ask: *keep it, or change something?* That is this\n  step's one question.\n  - **Keep** → leave the file alone and go straight to the `state.json` update at the end of Step 7.\n  - **Change** → edit only what they asked for, re-run the 5.x checks on what changed, then save.\n- **The site is already deployed** (`deploy.json` exists, or `state.json` has `deployed_at`) and the\n  user asked for a different look → this is a **redesign**. Tell them plainly: their content stays\n  as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7\n  as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user\n  wants to keep and move away from the rest.\n- **The brief says to keep the current look** (*Design direction* says so in the owner's words:\n  \"keep the look we have\", \"same look, new platform\") → follow *Keep the current look* below instead\n  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone\n  are signals for Step 2, not a request to keep.\n\n### Keep the current look\n\n1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method\n   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its\n   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save\n   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;\n   a logo seen only in a screenshot counts as no logo file, so list \"logo file needed\" under gaps in\n   the final report. The app in this folder (the path under `brief.md` → **Existing project**):\n   read its source; no build or browser needed.\n   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,\n     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with\n     the page background and body text taken from the root layout or `body`.\n   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or\n     `@import`, and the `font-family` on `body` and headings.\n   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;\n     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon\n     declared by `<link rel=\"icon\">` in `index.html` or the root layout's `metadata.icons`. Copy them\n     unchanged into `brand/`.\n\n   Files or exact colours and fonts the owner supplied win over anything you read.\n2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or\n   change something?* \"Keep the look we have\" still gets this question; skip it only when the brief\n   says to change nothing at all (\"keep it exactly as it is\"). A skipped tool result is not Keep; see\n   *When you ask the user* in the top-level `SKILL.md`. Change →\n   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.\n3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a\n   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font\n   without an `@fontsource` package swaps to the closest one that resolves (5.4).\n4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no\n   existing logo, the header shows the site name as text in the kept display font, and no logo is\n   designed.\n5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:\n   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say \"No favicon kept\".\n   - *Built from* says \"Kept, not rebuilt\". *Measured* still gives the width at `--logo-h-sm`\n     (≤ 192 px; else lower `--logo-h-sm` or show the name as text on small screens), and the header\n     link has `alt` = the site name and a target of at least 24 px (as in Step 6).\n   - With no logo: *Files* says \"None\", *Use* says the header link holds the site name as text in\n     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.\n\n## Step 2 — Collect the signals\n\nBefore inventing anything, gather what already constrains the design:\n\n| Signal | Where | How it constrains |\n|---|---|---|\n| Tone, purpose, audience | `brief.md` → *Tone*, *Purpose*, *Audience* | Sets the mood all three directions must fit |\n| Brand assets | `brief.md` → *Assets* | Logo, brand colours and fonts are **fixed** in every direction. Never recolour a supplied logo; Step 6 uses it instead of designing one |\n| Pages and entities | `content-model.md` → *Navigation*, *Pages*, *Articles*; if it doesn't exist yet, `brief.md` → *Pages* | Drives the component inventory and page composition |\n| Reference sites | URLs in the brief or the conversation | Cues to borrow (see below) |\n| Images already sourced | `content-model.md` → the image lines under *Articles* (skip if none yet) | Glance at a few at small size; keep accents from clashing with their dominant colours |\n| Current design (redesign only) | existing `design.md` | What to keep, what to move away from |\n\n**Reference sites.** Open each one in a real browser if you have one. Static fetches are often\nblocked or rate-limited; without a browser, fetch the HTML and its linked CSS instead. If neither\nworks, say so in one line and continue from the brief alone. Pull **cues**:\n\n- **Fonts:** the computed `font-family` of `h1`/`h2` and of body `p`.\n- **Colours:** background colours weighted by painted area (element width × height), the top 5–8.\n  Skip transparent and semi-transparent backgrounds and overlays (cookie banners, modals, chat\n  widgets). Text colours come from headings, paragraphs and links.\n- **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in\n  the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.\n\n**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).\nDon't use its logo, copy, images or exact layout. **The brief wins** over the live site when they\ndisagree (the user's words are what they want). Note the mismatch in the direction.\n\n**Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand\nyellow can be a background band or a large decorative shape, never body text. Say so in the\ndirection.\n\n## Step 3 — Derive three directions\n\nWrite three directions that **all fit the brief** but are **genuinely different**. Vary at least two\nof: palette (temperature, saturation, light vs. dark), type personality (geometric, grotesk, serif,\ndisplay), and shape language (sharp vs. round, flat vs. outlined, airy vs. dense). Three shades of\none idea is not a choice. Neither is a wildcard that ignores the brief.\n\nOrder them: **A is the recommendation**, the closest reading of the brief and references. B and C\npush in different directions.\n\nEach direction carries exactly this:\n\n- **Name** — 2–3 evocative words (\"Sticker-book maximal\", \"Quiet gallery\").\n- **Mood** — one line on how the site feels.\n- **Palette** — 5–7 hex colours with roles (base, text, primary accent, secondary accents, surface).\n  These are the core colours the user sees; Step 5 may add derived shades (link, muted, error,\n  focus) as tokens.\n- **Type** — a display font and a body font, both self-hostable through `@fontsource`.\n- **Shape language** — corners, borders, shadows and density in one phrase (\"chunky 3 px ink\n  outlines, hard 8 px offset shadows, tilted cards\").\n- **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,\n  a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).\n- **Logo idea** — one line on how the name becomes a logo, using a move from Step 6 (\"letters\n  bounce in different colours and the O is a smiley\"). When the brief carries a logo wish (*Design\n  direction* or *Assets*), every direction's logo idea is that wish in its own style. A wish is words\n  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).\n\n**Only offer what can pass.** Before asking, run two quick gates on **all three**:\n\n1. **Contrast gate.** Every colour that will carry text (base, surfaces, and any accent used as a\n   text block) has a palette text colour reaching **4.5:1** on it. Two text colours are fine (dark on\n   light blocks, light on dark ones). Accents that only ever hold large text need 3:1.\n2. **Font gate.** Each font resolves on npm, and the display font also has a static `@fontsource`\n   package, because the logo is built from it (5.4).\n\nA direction that fails either gate gets adjusted, not offered as-is. Don't offer a look that only\nworks by breaking the rules, such as body text on a neon accent or a marquee that can't be stopped.\nLoud is fine; inaccessible is not.\n\n**Avoid the template look** unless the brief asks for neutral: Inter or Roboto everywhere, a\nblue-to-purple gradient hero, centred hero with three feature cards, grey cards on white. Every\ndirection should look like *this* site, not a starter theme.\n\n## Step 4 — Ask once\n\nAsk **one** question, with A marked as the recommendation. With a structured question UI (multiple\nchoice plus an \"other\" field), each option's **label** is the direction's name and its\n**description** is one or two plain sentences, under ~160 characters. Without one, write each\noption as one line in the same shape.\n\nThe description says what the site would feel like, the main colours by name, what the lettering\nis like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your\nnotes. The question may end with one plain clause saying they can add a logo idea to their pick, but\nnever suggest one or give an example: that idea would end up in the logo.\n\n> **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,\n> chunky headlines, tilted sticker photos and a bouncy logo with a smiley O.\n\n> **Midnight disco** — A dark, glowing night-out feel: deep purple with neon pink, yellow and\n> turquoise, heavy rounded headlines and a logo like a neon sign.\n\nThen:\n\n- **Pick** → use it as written, and confirm the look in one line.\n- **\"You decide\"** → use A, and tell them in one line which look you went with.\n- **Skipped tool result** → not an answer: write the three directions as plain lines\n  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).\n- **A mix** (\"A's colours with C's fonts\") → merge them. Don't ask again.\n- **Something else** → build a direction from what they said, run Step 5, and use it. Don't send\n  three new options.\n\n**Logo wish.** An answer can carry a logo idea next to the pick (\"A, and make the logo a little\nteapot\"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.\nWhenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms\nthe pick: *\"The logo follows your idea: a little teapot.\"* If the kit can't draw it as said (a\ndetailed illustration, a photo), build its closest kit version and name what you simplified in that\nsame line. Don't ask a follow-up.\n\nDon't ask about anything else in this step.\n\n## Step 5 — Check the chosen direction\n\nFix any problem found here by adjusting the direction, not by asking the user. Don't report these\nchecks or their fixes; the user sees the result in the preview.\n\n### 5.1 Contrast — WCAG 2.2 SC 1.4.3 and 1.4.11\n\n**Which pairs count:** walk the component inventory you're about to write (Components table). For\neach component, list every foreground/background combination in every state: default, hover,\nfocus, active, error. Include text on coloured bands (footer links on dark, marquee text, chips),\nplaceholder text and photo credits. Compute the WCAG contrast ratio for each:\n\n| Kind | Examples | Minimum |\n|---|---|---|\n| Body text | paragraphs, links, footer text, input text, placeholder text, captions | **4.5:1** |\n| Large text | ≥ 24 px regular, or ≥ 18.66 px (14 pt) bold | **3:1** |\n| Non-text | input and button boundaries (when the outline is the only edge), focus indicator against each adjacent colour, icons that carry meaning, chip outlines | **3:1** |\n\nA pair that fails gets a darker or lighter shade of the **same hue**; never drop a brand colour. A\nnew shade becomes a token (for example `--color-link` or `--color-muted`). Disabled controls and\npure decoration are exempt, but say which elements those are. **Text on photos** needs a scrim or\nsolid backing that gets the text to 4.5:1 against the lightest part of the image. If you can't\nguarantee that, don't put text on photos. Record every pair and its ratio in `design.md`.\n\n```js\n// node -e: relative luminance + contrast ratio, hex in → ratio out\nconst L = h => { const c = h.match(/\\w\\w/g).map(x => parseInt(x, 16) / 255)\n  .map(v => v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);\n  return 0.2126 * c[0] + 0.7152 * c[1] + 0.0722 * c[2]; };\nconst ratio = (a, b) => { const [x, y] = [L(a), L(b)].sort((m, n) => n - m); return (x + 0.05) / (y + 0.05); };\n```\n\n### 5.2 The 8-point grid\n\nValues are checked in px at the default 16 px root (`0.5rem` = 8 px).\n\n| What | Rule |\n|---|---|\n| Spacing (padding, margin, gap) | Multiples of 8: `8 16 24 32 48 64 96 128`. **4 px** is the only half-step, and only inside small components (chip padding, icon-to-label gap) |\n| Component sizes | Heights and fixed widths are multiples of 8. Buttons, nav items and inputs are **48 px** tall minimum |\n| Radii | `8 16 24 32`, or `999px` for pills. 4 px only on elements under 32 px tall |\n| Line heights | Fixed-size text: multiples of 8 (16/24, 18/32, 24/32), or of 4 for text ≤ 14 px (12/16, 14/20). Fluid headings (`clamp()` sizes) use a unitless line-height (1.0–1.2) and are exempt, because their line box can't stay on the grid at every size |\n| Fluid spacing | `clamp()` for spacing or sizes uses grid values at both ends. Fluid **font sizes** are exempt |\n| Shadow offsets | 4 or 8 multiples |\n| Layout | Content width, gutters and breakpoints are multiples of 8 (e.g. `1200`, `768`, `1024`, `1280`) |\n| Exempt | Border and outline widths (1–4 px), focus offset, font sizes, the `999px` pill radius, the 4-multiple line heights above, and anything that isn't a length (angles like a `-2deg` tilt, durations, opacity) |\n\nEvery value in the **Tokens** block must pass this table.\n\n### 5.3 WCAG 2.2 AA — what the design must decide\n\nThese criteria are settled at design time. Write each answer into the **Accessibility** section of\n`design.md`.\n\n| Criterion | The design must specify |\n|---|---|\n| 1.4.1 Use of colour | Links in running text are underlined, not colour-only. States (active nav, selected, error) also change shape, weight or an icon, not only colour |\n| 1.4.4 Resize text | Font sizes in `rem`; nothing breaks at 200 % zoom |\n| 1.4.10 Reflow | Works at **320 CSS px** wide with no horizontal scroll. Every component has a stated ≤ 320 px behaviour; decorative pieces never widen the page |\n| 1.4.12 Text spacing | No fixed-height boxes around text, so nothing clips when a user overrides spacing (line-height 1.5, paragraph spacing 2×, letter-spacing 0.12 em, word-spacing 0.16 em). Fixed line-height tokens are fine; clipping is not |\n| 2.2.2 Pause, Stop, Hide | Anything that moves on its own for more than 5 s (marquee, carousel, animated sticker) has a **visible pause control**, and doesn't move at all under `prefers-reduced-motion`. Hover-to-pause alone doesn't count |\n| 2.3.1 Three flashes | Nothing flashes more than 3 times a second |\n| 2.4.7 Focus visible | One focus style (e.g. 3 px outline, 2 px offset) whose colour reaches 3:1 against **every** surface it can appear on. Name a second colour for surfaces where the first fails |\n| 2.4.11 Focus not obscured *(new in 2.2)* | Sticky headers, cookie bars and chat bubbles never cover the focused element. Either the header isn't sticky, or `scroll-padding-top: var(--header-h)` |\n| 2.5.8 Target size *(new in 2.2)* | Interactive targets ≥ 24 × 24 px with spacing. On this grid: **48 px** for buttons, nav and inputs, ≥ 24 px for inline icon buttons |\n| 3.2.6 Consistent help *(new in 2.2)* | The contact or help link sits in the same place on every page (e.g. last nav item and footer) |\n| 3.3.2 Labels | Every form field has a visible label; placeholders are never the only label |\n| 1.1.1 Text alternatives | Content images get alt text describing what they show; purely decorative images and shapes get empty alt or `aria-hidden` |\n\n### 5.4 Fonts resolve\n\nFor each family, prefer the variable package and fall back to the static one:\n`npm view @fontsource-variable/<slug> version`, then `npm view @fontsource/<slug> version`. One must\nanswer with a version. If neither does, swap to the closest family that does. Record the exact\npackage names. The **display** family must also resolve as a static package\n(`npm view @fontsource/<slug> version`): the static packages ship `.woff` files the logo kit can\nread; the variable ones ship only `.woff2`.\n\n### 5.5 The header fits on one line\n\nThe header is where a cramped width shows first: the logo, every nav item and the call-to-action\nbutton share one row, and when they run out of room they wrap mid-phrase (\"Services &\" over\n\"Pricing\", \"Book\" over \"Appointment\"). That always looks broken. Decide it here so the frontend\ncan't build it that way.\n\n- **Labels never break mid-phrase.** Nav links and the header button get `white-space: nowrap`, so a\n  two-word label stays on one line or not at all.\n- **Collapse before it wraps — not at 320 px.** The inline nav is replaced by a menu (hamburger)\n  button at the width where the logo, all nav items and the button stop fitting on one line, which is\n  usually wider than the mobile breakpoint. Estimate that width from the number of nav items and their\n  label lengths, round up to a multiple of 8, and make it the header's own breakpoint. Below it, only\n  the logo and the menu button show; the nav items and the CTA move into the opened menu.\n- **Keep header labels short.** A nav label is one or two short words; a button label is a two-word\n  verb phrase at most (\"Book now\", not \"Book an Appointment\"). When the content model gives a long\n  navigation label, the header may show a shorter form (\"Contact & Booking\" → \"Contact\") while the\n  page keeps its full name — note the shortened label in the **Header + nav** row.\n- Record the header breakpoint in *Grid, shape & motion* and the `nowrap` + collapse rule in the\n  **Header + nav** component row (and its `≤ 320 px` cell).\n\n## Step 6 — Design the logo\n\n**The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and\nskip the rest of this step. Never redraw or recolour it.\n\nOtherwise, turn the name into a **designed** logo: shaped, coloured and composed. Typing the name in\nthe display font with an emoji or symbol next to it doesn't count. Build the chosen direction's **logo\nidea** (as replaced by any logo wish, Step 4) with one or two of these moves:\n\n| Move | What it is | Suits |\n|---|---|---|\n| **Letter swap** | One letter becomes a simple shape tied to the subject: O → smiley, sun, loaf, plate, eye; I → candle, pencil, brush; A → roof, tent. Swap **one character** only, even if the letter appears twice, and the word must still read | Playful, friendly brands |\n| **Bounce** | Letters tilt ±3–6° and bob off the baseline, each in a palette colour, with an ink outline and hard shadow | Loud, maximal directions |\n| **Stack** | The name split over 2–3 lines on coloured tiles, or set as a tight block | Long names, bold directions |\n| **Tag** | The main word large; a short second word on a pill, ribbon or tab | Two-part names (\"Dopamine Den\") |\n| **Seal** | The name around a ring, with a monogram or symbol in the middle | A secondary mark (footer, hero sticker, social avatar), never the header logo |\n| **Typographic contrast** | Weight, style or case contrast between words (a light italic word next to a heavy upright one), custom tight spacing, one shared stroke or cut between letters | Quiet, refined, editorial directions |\n\nNo emoji, clip-art, gradients, or details that vanish at small sizes. Colours come only from the\npalette (base and surface colours count).\n\n### Build it with the logo kit\n\nThe kit (`logo-kit.mjs`, next to this file) does the error-prone parts: it outlines letters into\nvector paths, sets text on a circle, draws the outline-and-shadow treatment, measures, validates\nthe output, checks the sizes and renders a preview. You write the composition. Copy the kit into\n`brand/` so the build is self-contained and a redesign can re-run it:\n\n```bash\nmkdir -p ~/.hostinger/<domain>/brand && cd ~/.hostinger/<domain>/brand\ncp <the folder this SKILL.md is in>/logo-kit.mjs .\nnpm init -y >/dev/null && npm i opentype.js @resvg/resvg-js @fontsource/<display-slug>\n```\n\nWrite `brand/logo-build.mjs`, import from `./logo-kit.mjs`, and always run it from `brand/`\n(packages resolve from the working directory):\n\n| Kit function | Use |\n|---|---|\n| `loadFont(slug, weight, style)` | Loads a static `@fontsource` weight across all its subsets (`latin`, `latin-ext`, …), so accented letters like Ė or Ł resolve; `style` is `'normal'` or `'italic'`. Throws if that weight or style isn't in the package, so pick another |\n| `layout(font, text, size)` | Kerned glyph positions, total width, `capHeight`, `xHeight`; place letters one by one for bounce or swap. Throws if a character isn't in the font |\n| `glyphPath(glyph, x, baselineY, size)` / `textPath(font, text, x, baselineY, size)` | Outlined path data for one letter or a whole word. For typographic contrast, load two weights or styles and set each word with `textPath` |\n| `pathBox(font, text, x, baselineY, size)` | Tight box around a word's outlines; size the viewBox from it plus room for outlines, shadows and tilt |\n| `arcText(font, text, { cx, cy, r, size })` | Letters around a circle, for seals |\n| `sticker(d, { fill, ink, strokeWidth, shadow, shadowColor, transform })` | Ink outline + hard offset shadow, for outlined directions. On dark backgrounds give the outline and shadow a palette colour that shows (`shadowColor` defaults to `ink`) |\n| `svgDoc({ width, height, title, body })` | Root SVG with `role=\"img\"` and a `<title>` |\n| `check(svg)` | Throws on `NaN`, live `<text>`, a missing title or viewBox, or an `&` that isn't an XML entity. Run it on every file before writing |\n| `tile(size, fill)` | The rounded tile for the mark and favicon; draw the symbol after it |\n| `widthBudget(letterHeight, height)` | The widest viewBox that still fits 192 px on small screens, for a logo of that height; see below |\n| `checkLogo({ logo, mark, favicon, letterHeight, background })` | Runs `check()` on all three files, checks their sizes and renders `brand/logo-preview.png`; see below |\n\nWrap every file in `svgDoc()`, never a hand-written `<svg>` or `<title>`: it escapes the site name,\nand one bare `&` (as in \"Salt & Pepper\") makes the browser show nothing.\n\nNever call opentype's `path.toPathData()` directly; the kit's serializer exists because opentype.js\n2.0 writes `NaN` into some paths, and browsers silently stop drawing at the first `NaN`.\n\n### Deliver four files\n\n| File | What | Must read clearly at |\n|---|---|---|\n| `brand/logo.svg` | The primary, mostly horizontal logo for the header | Its header display heights (desktop and small screens) |\n| `brand/logo-mark.svg` | A square icon from the same idea (initial, monogram or the swapped symbol) on a `tile()` in a palette colour | 32 px |\n| `brand/favicon.svg` | The simplest form of the mark: same tile, no shadow, no thin details, outlines thickened if it has any | 16 px, on both light and dark browser tab bars |\n| `brand/logo-build.mjs` | The script that built them, with `package.json`, kept so a redesign can adjust it | — |\n\nAdd `brand/logo-seal.svg` only if the direction uses a seal as a secondary mark. Delete\n`brand/node_modules` when you're done; a redesign runs `npm i` in `brand/` first.\n\n**Compose within the budget, so the first build passes.** The small-screen logo is at most 192 px\nwide with letters at least 16 px tall, so the whole logo can be only about 10–12 times as wide as\nits smallest letters are tall, whatever its height. On one line that's about ten letters plus a\nsymbol; a longer name stacks or tags, and a second word set at half size halves the room. Size the\nviewBox in `logo-build.mjs` against `widthBudget(letterHeight, viewBoxHeight)`, the exact limit at\nthe heights the kit picks; with your own `heights`, the FAIL line gives the limit. Draw the mark's\nsymbol from simple, recognisable shapes that still read at 32 px; fine natural forms like petals or\nleaves turn to mush.\n\n**Check the sizes and look at it after every build.** `letterHeight` is in viewBox units: the\n`xHeight` from `layout()` when the logo is mostly lowercase, `capHeight` when it's mostly capitals;\nfor mixed fonts, the smaller word's. End `logo-build.mjs` with:\n\n```js\ncheckLogo({ logo, mark, favicon, letterHeight, background: '<page background colour>' });\n```\n\nIt picks the header heights for you: `--logo-h-sm` is the smallest multiple of 8 that makes the\nletters 16 px, and `--logo-h` the same but at least 48 px, both at most 80 px, so a stacked lockup\nkeeps its words large or sets the mark beside them. Pass `heights: { desktop, small }` only when the\ndirection needs a larger header logo. It first prints `--logo-h`, `--logo-h-sm` and the **Measured**\nline for `design.md`, then PASS or FAIL for the logo's letters ≥ 16 px at both\nheights, width ≤ 192 px on small screens, headroom around everything drawn and heights in multiples\nof 8; for the mark and favicon sitting on a `tile()` with nothing clipped and room around\nthe symbol; and for no shadow on the favicon. Every FAIL names its fixes and the number to reach. It\nthen renders `logo-preview.png` (the logo at both heights on the page background, the mark at 32 px\nand favicon at 16 px on light and dark strips, each also enlarged), and throws if anything failed.\n\nThen read `logo-preview.png`; don't search for another renderer or read the SVG source. Rebuild only\nfor a FAIL line or something in the preview that reads wrong, such as collisions, a clipped or\nclearly off-centre mark, or a favicon detail that turns to mush, and fix everything you saw in one\nrebuild. Optical nudges of a few pixels and the header height aren't reasons to rebuild. A symbol\ngets one redraw: if it still reads wrong, replace it with a simpler form of the idea, such as the\ninitial, in the next build. If the kit says \"preview not rendered\", rely on the size check and list\n\"logo not visually checked\" under gaps in the final report.\n\nThe logo is exempt from text-contrast minimums, but the header link around it needs `alt` = the site\nname and a target of at least 24 px.\n\nDon't show the logo to the user in this step; they see it in the preview.\n\n## Step 7 — Write `design.md` and hand off\n\nWrite `design.md` from the template below. Fill every section. The **Tokens** block is copied\nverbatim into the frontend's global stylesheet, so it must be valid CSS. Every colour, font, type\nsize, line height, space, radius and shadow used elsewhere in the file must exist in it as a token.\nThe template's token list is the **minimum**: add what the design needs (`--color-error`,\n`--color-on-accent`, `--leading-h3`…) under the same naming scheme.\n**Breakpoints are the one exception**: CSS custom properties don't work inside `@media`, so they are\nlisted in *Grid, shape & motion* as plain px values.\n\nThen update `state.json`: set `\"stage\": \"frontend\"` (also for a redesign: restyle, then validate and\ndeploy) and `updated_at` to the current UTC time (ISO 8601). Don't touch `provision`, `run` or\n`history` (`run-log.mjs` owns those), or add other keys.\n\nIf content prepare hasn't sourced images yet, it now follows `design.md` → **Imagery** (see\n`04-content-model/SKILL.md`).\n\nHand off in one or two plain sentences, as *Talk like a person* says: \"The look is set: warm cream,\nbrown lettering, berry buttons and your loaf logo.\" Nothing after it: no font names, file names or\nstages, and gaps such as a missing icon file or a font that may not load go in the final report.\n\n## `design.md` template\n\n````markdown\n# Design — <domain>\n\n> Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,\n> <C name>). <\"Picked by the user.\" | \"User said 'you decide'; recommendation A used.\" |\n> \"Merged by the user: <what>.\"> — or, when kept: \"Kept the owner's current look from <site URL |\n> screenshots | brand guide>, confirmed on <YYYY-MM-DD>.\"\n\n## Direction\n<2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),\nthe signature element.>\n\n## Stack\n**<chosen by the frontend step>** — design doesn't decide the stack. The frontend step (06) picks and\nconfirms the framework (default Next.js SSR; ecommerce must be SSR) and records it in\n`state.json → frontend`. Leave this as a placeholder for the frontend step to fill in.\n\n## Tokens\n```css\n:root {\n  /* colour — semantic names, never \"--pink-2\" */\n  --color-base: #…;      --color-text: #…;      --color-surface: #…;    --color-muted: #…;\n  --color-primary: #…;   --color-accent-1: #…;  --color-accent-2: #…;   --color-link: #…;\n  --color-focus: #…;     --color-focus-alt: #…; /* for surfaces where --color-focus is < 3:1 */\n  /* type */\n  --font-display: '<Family> Variable', <fallback stack>;\n  --font-body: '<Family> Variable', <fallback stack>;\n  --text-body: …rem;   --leading-body: …rem;    /* 8-multiple in px */\n  --text-small: …rem;  --leading-small: …rem;   /* 4-multiple in px */\n  --text-h1: clamp(…rem, …, …rem);  --text-h2: clamp(…);  --text-h3: …rem;\n  --leading-display: 1.05;          /* unitless; fluid headings are grid-exempt */\n  /* 8-point grid */\n  --space-half: 4px;  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;  --space-4: 32px;\n  --space-6: 48px;    --space-8: 64px;  --space-12: 96px; --space-16: 128px;\n  --target-min: 48px;\n  /* shape */\n  --radius-sm: 8px;  --radius-card: …;  --radius-pill: 999px;\n  --border: …;  --shadow: …;  --shadow-hover: …;\n  --focus-ring: 3px solid var(--color-focus);  --focus-offset: 2px;\n  /* layout */\n  --content-max: …px;  /* multiple of 8 */\n  --header-h: …px;     /* header band height, multiple of 8; scroll-padding-top uses it if sticky */\n  --logo-h: …px;       /* header logo height on desktop, multiple of 8 */\n  --logo-h-sm: …px;    /* on small screens; logo ≤ 192 px wide at this height */\n}\n```\n\n## Palette roles\n| Token | Hex | Used for |\n|---|---|---|\n\n## Contrast\n| Foreground | Background | Kind (body text / large text / non-text) | Ratio | Needs | Passes |\n|---|---|---|---|---|---|\n\n## Type\n- **Display:** <family> (`@fontsource-variable/<slug>@<version>`), weights …, tracking …; sizes `--text-h1…h3`, `--leading-display`\n- **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch\n\n## Logo\n- **Concept:** <the move(s), and what any swapped letter or symbol stands for, plus \"From the owner:\n  '<their words>'\" only when it follows their wish | \"Supplied by the user\" | \"Kept from <source>\" |\n  \"No logo: owner kept the current look\" (header shows the site name as text in `--font-display`)>\n- **Built from:** `@fontsource/<display-slug>@<version>`, weight(s)/style(s) …\n- **Files:** `brand/logo.svg` (header, `--logo-h` desktop / `--logo-h-sm` small screens),\n  `brand/logo-mark.svg`, `brand/favicon.svg`<, `brand/logo-seal.svg`>; source `brand/logo-build.mjs`\n- **Measured:** letters … px tall at `--logo-h-sm`; width … px at `--logo-h-sm`\n- **Use:** the frontend copies `brand/*.svg` into `public/`. Header: `<a href=\"/\"><img src=\"/logo.svg\"\n  alt=\"<Site name>\" style=\"height: var(--logo-h)\"></a>` (switch to `--logo-h-sm` on small screens).\n  Favicon: `<link rel=\"icon\" href=\"/favicon.svg\" type=\"image/svg+xml\">`\n- **Don't:** recolour, stretch, add effects, or retype the logo as live text.\n\n## Grid, shape & motion\n<section padding desktop/mobile (space tokens), gutters, breakpoints in px (multiples of 8), borders,\nradii, shadows, hover behaviour, every animation and its pause control, and \"no motion under\nprefers-reduced-motion\".>\n\n## Accessibility (WCAG 2.2 AA)\n- **Focus:** <style; which colour on which surface>\n- **Targets:** <48 px controls; inline exceptions>\n- **Links & states:** <underline rule; how active/error states differ beyond colour>\n- **Motion:** <what moves, where its pause control is>\n- **Sticky elements:** <none | header uses --header-h + scroll-padding-top>\n- **Help:** <where the contact link sits on every page>\n- **Text on images:** <none | scrim spec and resulting ratio>\n- **Reflow:** <anything special at 320 px>\n- **Exempt from contrast:** <disabled controls / decorative shapes, named>\n\n## Components\n| Component | Renders (from content model) | Look | ≤ 320 px |\n|---|---|---|---|\n| Header + nav | Navigation items | … Nav links and the button never wrap (`white-space: nowrap`); the inline nav collapses to a menu button at <px> (the width it stops fitting one line). | Logo + menu button only; nav items and CTA inside the menu |\n| Post card | Article: image, category, title, excerpt | … | … |\n| … | | | |\n\n## Page composition\n- **<Page>** — <sections top to bottom, each naming its component and band colour>\n- …\n\n## Imagery\n<subjects, mood and colour fit for photos; search keywords; treatment (frame, crop ratio, radius,\nduotone…); alt text written from what the photo shows.>\n\n## Don'ts\n- <3–6 site-specific rules, e.g. \"no grey cards\", \"never put body text on the primary accent\">\n````\n\n## Invariants\n\n- **One question.** Refine owns discovery; this step only chooses among directions (or keeps the\n  existing look).\n- **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed\n  exemptions.\n- **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand\n  colours keep their hue but only appear in roles where they pass.\n- **The header never wraps.** Nav labels and the header button stay on one line (`white-space:\n  nowrap`); the inline nav collapses to a menu button at the width it stops fitting, not only at the\n  mobile breakpoint (5.5).\n- **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.\n- **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,\n  emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no\n  logo shows the site name as text and gets no new logo.\n- **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.\n- **The tokens block is the only source of values** (breakpoints excepted). Components and pages\n  reference tokens, never raw hex codes, pixel values or font names.\n- **No backend calls.** Design never waits on provision and never writes to the instance.\n- **Never overwrite an existing `design.md` silently.** Keep or change, as in Step 1.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/05-design/logo-kit.mjs",

package/src/core/skills.ts

@@ -232,10 +232,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/05-design/SKILL.md",
-        "digest": "sha256:77fae3ed1e68f8634ee667a5d5d0a6c202b5f9e109d14c9cb34a717c77a47b80",
-        "size": 37794,
+        "digest": "sha256:688891726ec9d42e6a69c53fbdd855fb3b8c046927c622948f23e79ebd7ffea4",
+        "size": 39762,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-design\ndescription: \"Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend.\"\n---\n\n# headless-step-design\n\nTurn the brief into a look the user has chosen, and write it down so the frontend can't drift from\nit. **One question, three options, one spec.** The output is **files** (`design.md` plus the logo),\nnot a conversation: the frontend step implements `design.md`, not the chat.\n\n**In:** `brief.md` (required), `content-model.md` (if it exists yet), reference sites and assets the\nuser gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in\n`~/.hostinger/<domain>/brand/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? This step defers to the user\n> Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the\n> design — **do not generate three directions or write a prescriptive `design.md` over their project.**\n> The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*\n> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when\n> **Design direction** keeps the look of the app in this folder: their own code already carries it.\n> Either write nothing, or capture only what the user explicitly asks for (a short note of their\n> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow\n> moves on to frontend. The logo and token work here apply only when **Build mode is \"Agent designs\n> and builds\"**.\n\nThis is **prepare work**: it runs while provision settles (see *Background provision & the instance\nbarrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.\n\n**Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user\n**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three\ndirections (Step 4), never both. \"You decide\" is a valid answer.\n\n**Talk like a person, not a designer.** Everything the user reads describes how the site will\n**look and feel**: colours by name (\"hot pink, butter yellow\"), lettering by feel (\"big chunky\nrounded headlines\"), and the details they'll notice (\"photos tilted like stickers on a scrapbook\").\nNo hex codes, font names, or design and tech words (palette, accent, tokens, shape language,\ncontrast, favicon, wordmark, lockup, WCAG, 8-point grid, Next.js, SSR, `state.json`), even when\nthe owner's own brand guide names them. This covers every message until the step ends, including\nthe keep/change question, your one-line confirmation after the pick and the message you hand off\nwith.\n\n**Two hard rules apply to every direction, however loud or quiet it is:**\n\n- **The 8-point grid.** Every spacing, sizing and layout value is a multiple of 8 px (details in\n  5.2).\n- **WCAG 2.2 Level AA.** Colour, focus, motion, target size and reflow are decided here, so the\n  frontend can't build them wrong (details in 5.1 and 5.3).\n\nThese rules are for you, not the user. **Never mention them**: no grid, contrast, WCAG or\naccessibility talk in anything the user reads, and no \"all options follow…\" reassurances. The user\njudges the look in the preview; the rules just make sure it works.\n\n---\n\n## Step 1 — Read the workspace, then the resume check\n\nRead `brief.md`, `state.json`, and `content-model.md` if it exists.\n\n- **`design.md` already exists and this is not a redesign** → don't overwrite it. Describe the\n  current look in two or three plain sentences and ask: *keep it, or change something?* That is this\n  step's one question.\n  - **Keep** → leave the file alone and go straight to the `state.json` update at the end of Step 7.\n  - **Change** → edit only what they asked for, re-run the 5.x checks on what changed, then save.\n- **The site is already deployed** (`deploy.json` exists, or `state.json` has `deployed_at`) and the\n  user asked for a different look → this is a **redesign**. Tell them plainly: their content stays\n  as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7\n  as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user\n  wants to keep and move away from the rest.\n- **The brief says to keep the current look** (*Design direction* says so in the owner's words:\n  \"keep the look we have\", \"same look, new platform\") → follow *Keep the current look* below instead\n  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone\n  are signals for Step 2, not a request to keep.\n\n### Keep the current look\n\n1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method\n   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its\n   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save\n   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;\n   a logo seen only in a screenshot counts as no logo file, so list \"logo file needed\" under gaps in\n   the final report. The app in this folder (the path under `brief.md` → **Existing project**):\n   read its source; no build or browser needed.\n   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,\n     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with\n     the page background and body text taken from the root layout or `body`.\n   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or\n     `@import`, and the `font-family` on `body` and headings.\n   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;\n     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon\n     declared by `<link rel=\"icon\">` in `index.html` or the root layout's `metadata.icons`. Copy them\n     unchanged into `brand/`.\n\n   Files or exact colours and fonts the owner supplied win over anything you read.\n2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or\n   change something?* \"Keep the look we have\" still gets this question; skip it only when the brief\n   says to change nothing at all (\"keep it exactly as it is\"). A skipped tool result is not Keep; see\n   *When you ask the user* in the top-level `SKILL.md`. Change →\n   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.\n3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a\n   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font\n   without an `@fontsource` package swaps to the closest one that resolves (5.4).\n4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no\n   existing logo, the header shows the site name as text in the kept display font, and no logo is\n   designed.\n5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:\n   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say \"No favicon kept\".\n   - *Built from* says \"Kept, not rebuilt\". *Measured* still gives the width at `--logo-h-sm`\n     (≤ 192 px; else lower `--logo-h-sm` or show the name as text on small screens), and the header\n     link has `alt` = the site name and a target of at least 24 px (as in Step 6).\n   - With no logo: *Files* says \"None\", *Use* says the header link holds the site name as text in\n     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.\n\n## Step 2 — Collect the signals\n\nBefore inventing anything, gather what already constrains the design:\n\n| Signal | Where | How it constrains |\n|---|---|---|\n| Tone, purpose, audience | `brief.md` → *Tone*, *Purpose*, *Audience* | Sets the mood all three directions must fit |\n| Brand assets | `brief.md` → *Assets* | Logo, brand colours and fonts are **fixed** in every direction. Never recolour a supplied logo; Step 6 uses it instead of designing one |\n| Pages and entities | `content-model.md` → *Navigation*, *Pages*, *Articles*; if it doesn't exist yet, `brief.md` → *Pages* | Drives the component inventory and page composition |\n| Reference sites | URLs in the brief or the conversation | Cues to borrow (see below) |\n| Images already sourced | `content-model.md` → the image lines under *Articles* (skip if none yet) | Glance at a few at small size; keep accents from clashing with their dominant colours |\n| Current design (redesign only) | existing `design.md` | What to keep, what to move away from |\n\n**Reference sites.** Open each one in a real browser if you have one. Static fetches are often\nblocked or rate-limited; without a browser, fetch the HTML and its linked CSS instead. If neither\nworks, say so in one line and continue from the brief alone. Pull **cues**:\n\n- **Fonts:** the computed `font-family` of `h1`/`h2` and of body `p`.\n- **Colours:** background colours weighted by painted area (element width × height), the top 5–8.\n  Skip transparent and semi-transparent backgrounds and overlays (cookie banners, modals, chat\n  widgets). Text colours come from headings, paragraphs and links.\n- **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in\n  the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.\n\n**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).\nDon't use its logo, copy, images or exact layout. **The brief wins** over the live site when they\ndisagree (the user's words are what they want). Note the mismatch in the direction.\n\n**Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand\nyellow can be a background band or a large decorative shape, never body text. Say so in the\ndirection.\n\n## Step 3 — Derive three directions\n\nWrite three directions that **all fit the brief** but are **genuinely different**. Vary at least two\nof: palette (temperature, saturation, light vs. dark), type personality (geometric, grotesk, serif,\ndisplay), and shape language (sharp vs. round, flat vs. outlined, airy vs. dense). Three shades of\none idea is not a choice. Neither is a wildcard that ignores the brief.\n\nOrder them: **A is the recommendation**, the closest reading of the brief and references. B and C\npush in different directions.\n\nEach direction carries exactly this:\n\n- **Name** — 2–3 evocative words (\"Sticker-book maximal\", \"Quiet gallery\").\n- **Mood** — one line on how the site feels.\n- **Palette** — 5–7 hex colours with roles (base, text, primary accent, secondary accents, surface).\n  These are the core colours the user sees; Step 5 may add derived shades (link, muted, error,\n  focus) as tokens.\n- **Type** — a display font and a body font, both self-hostable through `@fontsource`.\n- **Shape language** — corners, borders, shadows and density in one phrase (\"chunky 3 px ink\n  outlines, hard 8 px offset shadows, tilted cards\").\n- **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,\n  a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).\n- **Logo idea** — one line on how the name becomes a logo, using a move from Step 6 (\"letters\n  bounce in different colours and the O is a smiley\"). When the brief carries a logo wish (*Design\n  direction* or *Assets*), every direction's logo idea is that wish in its own style. A wish is words\n  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).\n\n**Only offer what can pass.** Before asking, run two quick gates on **all three**:\n\n1. **Contrast gate.** Every colour that will carry text (base, surfaces, and any accent used as a\n   text block) has a palette text colour reaching **4.5:1** on it. Two text colours are fine (dark on\n   light blocks, light on dark ones). Accents that only ever hold large text need 3:1.\n2. **Font gate.** Each font resolves on npm, and the display font also has a static `@fontsource`\n   package, because the logo is built from it (5.4).\n\nA direction that fails either gate gets adjusted, not offered as-is. Don't offer a look that only\nworks by breaking the rules, such as body text on a neon accent or a marquee that can't be stopped.\nLoud is fine; inaccessible is not.\n\n**Avoid the template look** unless the brief asks for neutral: Inter or Roboto everywhere, a\nblue-to-purple gradient hero, centred hero with three feature cards, grey cards on white. Every\ndirection should look like *this* site, not a starter theme.\n\n## Step 4 — Ask once\n\nAsk **one** question, with A marked as the recommendation. With a structured question UI (multiple\nchoice plus an \"other\" field), each option's **label** is the direction's name and its\n**description** is one or two plain sentences, under ~160 characters. Without one, write each\noption as one line in the same shape.\n\nThe description says what the site would feel like, the main colours by name, what the lettering\nis like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your\nnotes. The question may end with one plain clause saying they can add a logo idea to their pick, but\nnever suggest one or give an example: that idea would end up in the logo.\n\n> **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,\n> chunky headlines, tilted sticker photos and a bouncy logo with a smiley O.\n\n> **Midnight disco** — A dark, glowing night-out feel: deep purple with neon pink, yellow and\n> turquoise, heavy rounded headlines and a logo like a neon sign.\n\nThen:\n\n- **Pick** → use it as written, and confirm the look in one line.\n- **\"You decide\"** → use A, and tell them in one line which look you went with.\n- **Skipped tool result** → not an answer: write the three directions as plain lines\n  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).\n- **A mix** (\"A's colours with C's fonts\") → merge them. Don't ask again.\n- **Something else** → build a direction from what they said, run Step 5, and use it. Don't send\n  three new options.\n\n**Logo wish.** An answer can carry a logo idea next to the pick (\"A, and make the logo a little\nteapot\"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.\nWhenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms\nthe pick: *\"The logo follows your idea: a little teapot.\"* If the kit can't draw it as said (a\ndetailed illustration, a photo), build its closest kit version and name what you simplified in that\nsame line. Don't ask a follow-up.\n\nDon't ask about anything else in this step.\n\n## Step 5 — Check the chosen direction\n\nFix any problem found here by adjusting the direction, not by asking the user. Don't report these\nchecks or their fixes; the user sees the result in the preview.\n\n### 5.1 Contrast — WCAG 2.2 SC 1.4.3 and 1.4.11\n\n**Which pairs count:** walk the component inventory you're about to write (Components table). For\neach component, list every foreground/background combination in every state: default, hover,\nfocus, active, error. Include text on coloured bands (footer links on dark, marquee text, chips),\nplaceholder text and photo credits. Compute the WCAG contrast ratio for each:\n\n| Kind | Examples | Minimum |\n|---|---|---|\n| Body text | paragraphs, links, footer text, input text, placeholder text, captions | **4.5:1** |\n| Large text | ≥ 24 px regular, or ≥ 18.66 px (14 pt) bold | **3:1** |\n| Non-text | input and button boundaries (when the outline is the only edge), focus indicator against each adjacent colour, icons that carry meaning, chip outlines | **3:1** |\n\nA pair that fails gets a darker or lighter shade of the **same hue**; never drop a brand colour. A\nnew shade becomes a token (for example `--color-link` or `--color-muted`). Disabled controls and\npure decoration are exempt, but say which elements those are. **Text on photos** needs a scrim or\nsolid backing that gets the text to 4.5:1 against the lightest part of the image. If you can't\nguarantee that, don't put text on photos. Record every pair and its ratio in `design.md`.\n\n```js\n// node -e: relative luminance + contrast ratio, hex in → ratio out\nconst L = h => { const c = h.match(/\\w\\w/g).map(x => parseInt(x, 16) / 255)\n  .map(v => v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);\n  return 0.2126 * c[0] + 0.7152 * c[1] + 0.0722 * c[2]; };\nconst ratio = (a, b) => { const [x, y] = [L(a), L(b)].sort((m, n) => n - m); return (x + 0.05) / (y + 0.05); };\n```\n\n### 5.2 The 8-point grid\n\nValues are checked in px at the default 16 px root (`0.5rem` = 8 px).\n\n| What | Rule |\n|---|---|\n| Spacing (padding, margin, gap) | Multiples of 8: `8 16 24 32 48 64 96 128`. **4 px** is the only half-step, and only inside small components (chip padding, icon-to-label gap) |\n| Component sizes | Heights and fixed widths are multiples of 8. Buttons, nav items and inputs are **48 px** tall minimum |\n| Radii | `8 16 24 32`, or `999px` for pills. 4 px only on elements under 32 px tall |\n| Line heights | Fixed-size text: multiples of 8 (16/24, 18/32, 24/32), or of 4 for text ≤ 14 px (12/16, 14/20). Fluid headings (`clamp()` sizes) use a unitless line-height (1.0–1.2) and are exempt, because their line box can't stay on the grid at every size |\n| Fluid spacing | `clamp()` for spacing or sizes uses grid values at both ends. Fluid **font sizes** are exempt |\n| Shadow offsets | 4 or 8 multiples |\n| Layout | Content width, gutters and breakpoints are multiples of 8 (e.g. `1200`, `768`, `1024`, `1280`) |\n| Exempt | Border and outline widths (1–4 px), focus offset, font sizes, the `999px` pill radius, the 4-multiple line heights above, and anything that isn't a length (angles like a `-2deg` tilt, durations, opacity) |\n\nEvery value in the **Tokens** block must pass this table.\n\n### 5.3 WCAG 2.2 AA — what the design must decide\n\nThese criteria are settled at design time. Write each answer into the **Accessibility** section of\n`design.md`.\n\n| Criterion | The design must specify |\n|---|---|\n| 1.4.1 Use of colour | Links in running text are underlined, not colour-only. States (active nav, selected, error) also change shape, weight or an icon, not only colour |\n| 1.4.4 Resize text | Font sizes in `rem`; nothing breaks at 200 % zoom |\n| 1.4.10 Reflow | Works at **320 CSS px** wide with no horizontal scroll. Every component has a stated ≤ 320 px behaviour; decorative pieces never widen the page |\n| 1.4.12 Text spacing | No fixed-height boxes around text, so nothing clips when a user overrides spacing (line-height 1.5, paragraph spacing 2×, letter-spacing 0.12 em, word-spacing 0.16 em). Fixed line-height tokens are fine; clipping is not |\n| 2.2.2 Pause, Stop, Hide | Anything that moves on its own for more than 5 s (marquee, carousel, animated sticker) has a **visible pause control**, and doesn't move at all under `prefers-reduced-motion`. Hover-to-pause alone doesn't count |\n| 2.3.1 Three flashes | Nothing flashes more than 3 times a second |\n| 2.4.7 Focus visible | One focus style (e.g. 3 px outline, 2 px offset) whose colour reaches 3:1 against **every** surface it can appear on. Name a second colour for surfaces where the first fails |\n| 2.4.11 Focus not obscured *(new in 2.2)* | Sticky headers, cookie bars and chat bubbles never cover the focused element. Either the header isn't sticky, or `scroll-padding-top: var(--header-h)` |\n| 2.5.8 Target size *(new in 2.2)* | Interactive targets ≥ 24 × 24 px with spacing. On this grid: **48 px** for buttons, nav and inputs, ≥ 24 px for inline icon buttons |\n| 3.2.6 Consistent help *(new in 2.2)* | The contact or help link sits in the same place on every page (e.g. last nav item and footer) |\n| 3.3.2 Labels | Every form field has a visible label; placeholders are never the only label |\n| 1.1.1 Text alternatives | Content images get alt text describing what they show; purely decorative images and shapes get empty alt or `aria-hidden` |\n\n### 5.4 Fonts resolve\n\nFor each family, prefer the variable package and fall back to the static one:\n`npm view @fontsource-variable/<slug> version`, then `npm view @fontsource/<slug> version`. One must\nanswer with a version. If neither does, swap to the closest family that does. Record the exact\npackage names. The **display** family must also resolve as a static package\n(`npm view @fontsource/<slug> version`): the static packages ship `.woff` files the logo kit can\nread; the variable ones ship only `.woff2`.\n\n## Step 6 — Design the logo\n\n**The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and\nskip the rest of this step. Never redraw or recolour it.\n\nOtherwise, turn the name into a **designed** logo: shaped, coloured and composed. Typing the name in\nthe display font with an emoji or symbol next to it doesn't count. Build the chosen direction's **logo\nidea** (as replaced by any logo wish, Step 4) with one or two of these moves:\n\n| Move | What it is | Suits |\n|---|---|---|\n| **Letter swap** | One letter becomes a simple shape tied to the subject: O → smiley, sun, loaf, plate, eye; I → candle, pencil, brush; A → roof, tent. Swap **one character** only, even if the letter appears twice, and the word must still read | Playful, friendly brands |\n| **Bounce** | Letters tilt ±3–6° and bob off the baseline, each in a palette colour, with an ink outline and hard shadow | Loud, maximal directions |\n| **Stack** | The name split over 2–3 lines on coloured tiles, or set as a tight block | Long names, bold directions |\n| **Tag** | The main word large; a short second word on a pill, ribbon or tab | Two-part names (\"Dopamine Den\") |\n| **Seal** | The name around a ring, with a monogram or symbol in the middle | A secondary mark (footer, hero sticker, social avatar), never the header logo |\n| **Typographic contrast** | Weight, style or case contrast between words (a light italic word next to a heavy upright one), custom tight spacing, one shared stroke or cut between letters | Quiet, refined, editorial directions |\n\nNo emoji, clip-art, gradients, or details that vanish at small sizes. Colours come only from the\npalette (base and surface colours count).\n\n### Build it with the logo kit\n\nThe kit (`logo-kit.mjs`, next to this file) does the error-prone parts: it outlines letters into\nvector paths, sets text on a circle, draws the outline-and-shadow treatment, measures, validates\nthe output, checks the sizes and renders a preview. You write the composition. Copy the kit into\n`brand/` so the build is self-contained and a redesign can re-run it:\n\n```bash\nmkdir -p ~/.hostinger/<domain>/brand && cd ~/.hostinger/<domain>/brand\ncp <the folder this SKILL.md is in>/logo-kit.mjs .\nnpm init -y >/dev/null && npm i opentype.js @resvg/resvg-js @fontsource/<display-slug>\n```\n\nWrite `brand/logo-build.mjs`, import from `./logo-kit.mjs`, and always run it from `brand/`\n(packages resolve from the working directory):\n\n| Kit function | Use |\n|---|---|\n| `loadFont(slug, weight, style)` | Loads a static `@fontsource` weight across all its subsets (`latin`, `latin-ext`, …), so accented letters like Ė or Ł resolve; `style` is `'normal'` or `'italic'`. Throws if that weight or style isn't in the package, so pick another |\n| `layout(font, text, size)` | Kerned glyph positions, total width, `capHeight`, `xHeight`; place letters one by one for bounce or swap. Throws if a character isn't in the font |\n| `glyphPath(glyph, x, baselineY, size)` / `textPath(font, text, x, baselineY, size)` | Outlined path data for one letter or a whole word. For typographic contrast, load two weights or styles and set each word with `textPath` |\n| `pathBox(font, text, x, baselineY, size)` | Tight box around a word's outlines; size the viewBox from it plus room for outlines, shadows and tilt |\n| `arcText(font, text, { cx, cy, r, size })` | Letters around a circle, for seals |\n| `sticker(d, { fill, ink, strokeWidth, shadow, shadowColor, transform })` | Ink outline + hard offset shadow, for outlined directions. On dark backgrounds give the outline and shadow a palette colour that shows (`shadowColor` defaults to `ink`) |\n| `svgDoc({ width, height, title, body })` | Root SVG with `role=\"img\"` and a `<title>` |\n| `check(svg)` | Throws on `NaN`, live `<text>`, a missing title or viewBox, or an `&` that isn't an XML entity. Run it on every file before writing |\n| `tile(size, fill)` | The rounded tile for the mark and favicon; draw the symbol after it |\n| `widthBudget(letterHeight, height)` | The widest viewBox that still fits 192 px on small screens, for a logo of that height; see below |\n| `checkLogo({ logo, mark, favicon, letterHeight, background })` | Runs `check()` on all three files, checks their sizes and renders `brand/logo-preview.png`; see below |\n\nWrap every file in `svgDoc()`, never a hand-written `<svg>` or `<title>`: it escapes the site name,\nand one bare `&` (as in \"Salt & Pepper\") makes the browser show nothing.\n\nNever call opentype's `path.toPathData()` directly; the kit's serializer exists because opentype.js\n2.0 writes `NaN` into some paths, and browsers silently stop drawing at the first `NaN`.\n\n### Deliver four files\n\n| File | What | Must read clearly at |\n|---|---|---|\n| `brand/logo.svg` | The primary, mostly horizontal logo for the header | Its header display heights (desktop and small screens) |\n| `brand/logo-mark.svg` | A square icon from the same idea (initial, monogram or the swapped symbol) on a `tile()` in a palette colour | 32 px |\n| `brand/favicon.svg` | The simplest form of the mark: same tile, no shadow, no thin details, outlines thickened if it has any | 16 px, on both light and dark browser tab bars |\n| `brand/logo-build.mjs` | The script that built them, with `package.json`, kept so a redesign can adjust it | — |\n\nAdd `brand/logo-seal.svg` only if the direction uses a seal as a secondary mark. Delete\n`brand/node_modules` when you're done; a redesign runs `npm i` in `brand/` first.\n\n**Compose within the budget, so the first build passes.** The small-screen logo is at most 192 px\nwide with letters at least 16 px tall, so the whole logo can be only about 10–12 times as wide as\nits smallest letters are tall, whatever its height. On one line that's about ten letters plus a\nsymbol; a longer name stacks or tags, and a second word set at half size halves the room. Size the\nviewBox in `logo-build.mjs` against `widthBudget(letterHeight, viewBoxHeight)`, the exact limit at\nthe heights the kit picks; with your own `heights`, the FAIL line gives the limit. Draw the mark's\nsymbol from simple, recognisable shapes that still read at 32 px; fine natural forms like petals or\nleaves turn to mush.\n\n**Check the sizes and look at it after every build.** `letterHeight` is in viewBox units: the\n`xHeight` from `layout()` when the logo is mostly lowercase, `capHeight` when it's mostly capitals;\nfor mixed fonts, the smaller word's. End `logo-build.mjs` with:\n\n```js\ncheckLogo({ logo, mark, favicon, letterHeight, background: '<page background colour>' });\n```\n\nIt picks the header heights for you: `--logo-h-sm` is the smallest multiple of 8 that makes the\nletters 16 px, and `--logo-h` the same but at least 48 px, both at most 80 px, so a stacked lockup\nkeeps its words large or sets the mark beside them. Pass `heights: { desktop, small }` only when the\ndirection needs a larger header logo. It first prints `--logo-h`, `--logo-h-sm` and the **Measured**\nline for `design.md`, then PASS or FAIL for the logo's letters ≥ 16 px at both\nheights, width ≤ 192 px on small screens, headroom around everything drawn and heights in multiples\nof 8; for the mark and favicon sitting on a `tile()` with nothing clipped and room around\nthe symbol; and for no shadow on the favicon. Every FAIL names its fixes and the number to reach. It\nthen renders `logo-preview.png` (the logo at both heights on the page background, the mark at 32 px\nand favicon at 16 px on light and dark strips, each also enlarged), and throws if anything failed.\n\nThen read `logo-preview.png`; don't search for another renderer or read the SVG source. Rebuild only\nfor a FAIL line or something in the preview that reads wrong, such as collisions, a clipped or\nclearly off-centre mark, or a favicon detail that turns to mush, and fix everything you saw in one\nrebuild. Optical nudges of a few pixels and the header height aren't reasons to rebuild. A symbol\ngets one redraw: if it still reads wrong, replace it with a simpler form of the idea, such as the\ninitial, in the next build. If the kit says \"preview not rendered\", rely on the size check and list\n\"logo not visually checked\" under gaps in the final report.\n\nThe logo is exempt from text-contrast minimums, but the header link around it needs `alt` = the site\nname and a target of at least 24 px.\n\nDon't show the logo to the user in this step; they see it in the preview.\n\n## Step 7 — Write `design.md` and hand off\n\nWrite `design.md` from the template below. Fill every section. The **Tokens** block is copied\nverbatim into the frontend's global stylesheet, so it must be valid CSS. Every colour, font, type\nsize, line height, space, radius and shadow used elsewhere in the file must exist in it as a token.\nThe template's token list is the **minimum**: add what the design needs (`--color-error`,\n`--color-on-accent`, `--leading-h3`…) under the same naming scheme.\n**Breakpoints are the one exception**: CSS custom properties don't work inside `@media`, so they are\nlisted in *Grid, shape & motion* as plain px values.\n\nThen update `state.json`: set `\"stage\": \"frontend\"` (also for a redesign: restyle, then validate and\ndeploy) and `updated_at` to the current UTC time (ISO 8601). Don't touch `provision`, `run` or\n`history` (`run-log.mjs` owns those), or add other keys.\n\nIf content prepare hasn't sourced images yet, it now follows `design.md` → **Imagery** (see\n`04-content-model/SKILL.md`).\n\nHand off in one or two plain sentences, as *Talk like a person* says: \"The look is set: warm cream,\nbrown lettering, berry buttons and your loaf logo.\" Nothing after it: no font names, file names or\nstages, and gaps such as a missing icon file or a font that may not load go in the final report.\n\n## `design.md` template\n\n````markdown\n# Design — <domain>\n\n> Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,\n> <C name>). <\"Picked by the user.\" | \"User said 'you decide'; recommendation A used.\" |\n> \"Merged by the user: <what>.\"> — or, when kept: \"Kept the owner's current look from <site URL |\n> screenshots | brand guide>, confirmed on <YYYY-MM-DD>.\"\n\n## Direction\n<2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),\nthe signature element.>\n\n## Stack\n**<chosen by the frontend step>** — design doesn't decide the stack. The frontend step (06) picks and\nconfirms the framework (default Next.js SSR; ecommerce must be SSR) and records it in\n`state.json → frontend`. Leave this as a placeholder for the frontend step to fill in.\n\n## Tokens\n```css\n:root {\n  /* colour — semantic names, never \"--pink-2\" */\n  --color-base: #…;      --color-text: #…;      --color-surface: #…;    --color-muted: #…;\n  --color-primary: #…;   --color-accent-1: #…;  --color-accent-2: #…;   --color-link: #…;\n  --color-focus: #…;     --color-focus-alt: #…; /* for surfaces where --color-focus is < 3:1 */\n  /* type */\n  --font-display: '<Family> Variable', <fallback stack>;\n  --font-body: '<Family> Variable', <fallback stack>;\n  --text-body: …rem;   --leading-body: …rem;    /* 8-multiple in px */\n  --text-small: …rem;  --leading-small: …rem;   /* 4-multiple in px */\n  --text-h1: clamp(…rem, …, …rem);  --text-h2: clamp(…);  --text-h3: …rem;\n  --leading-display: 1.05;          /* unitless; fluid headings are grid-exempt */\n  /* 8-point grid */\n  --space-half: 4px;  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;  --space-4: 32px;\n  --space-6: 48px;    --space-8: 64px;  --space-12: 96px; --space-16: 128px;\n  --target-min: 48px;\n  /* shape */\n  --radius-sm: 8px;  --radius-card: …;  --radius-pill: 999px;\n  --border: …;  --shadow: …;  --shadow-hover: …;\n  --focus-ring: 3px solid var(--color-focus);  --focus-offset: 2px;\n  /* layout */\n  --content-max: …px;  /* multiple of 8 */\n  --header-h: …px;     /* header band height, multiple of 8; scroll-padding-top uses it if sticky */\n  --logo-h: …px;       /* header logo height on desktop, multiple of 8 */\n  --logo-h-sm: …px;    /* on small screens; logo ≤ 192 px wide at this height */\n}\n```\n\n## Palette roles\n| Token | Hex | Used for |\n|---|---|---|\n\n## Contrast\n| Foreground | Background | Kind (body text / large text / non-text) | Ratio | Needs | Passes |\n|---|---|---|---|---|---|\n\n## Type\n- **Display:** <family> (`@fontsource-variable/<slug>@<version>`), weights …, tracking …; sizes `--text-h1…h3`, `--leading-display`\n- **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch\n\n## Logo\n- **Concept:** <the move(s), and what any swapped letter or symbol stands for, plus \"From the owner:\n  '<their words>'\" only when it follows their wish | \"Supplied by the user\" | \"Kept from <source>\" |\n  \"No logo: owner kept the current look\" (header shows the site name as text in `--font-display`)>\n- **Built from:** `@fontsource/<display-slug>@<version>`, weight(s)/style(s) …\n- **Files:** `brand/logo.svg` (header, `--logo-h` desktop / `--logo-h-sm` small screens),\n  `brand/logo-mark.svg`, `brand/favicon.svg`<, `brand/logo-seal.svg`>; source `brand/logo-build.mjs`\n- **Measured:** letters … px tall at `--logo-h-sm`; width … px at `--logo-h-sm`\n- **Use:** the frontend copies `brand/*.svg` into `public/`. Header: `<a href=\"/\"><img src=\"/logo.svg\"\n  alt=\"<Site name>\" style=\"height: var(--logo-h)\"></a>` (switch to `--logo-h-sm` on small screens).\n  Favicon: `<link rel=\"icon\" href=\"/favicon.svg\" type=\"image/svg+xml\">`\n- **Don't:** recolour, stretch, add effects, or retype the logo as live text.\n\n## Grid, shape & motion\n<section padding desktop/mobile (space tokens), gutters, breakpoints in px (multiples of 8), borders,\nradii, shadows, hover behaviour, every animation and its pause control, and \"no motion under\nprefers-reduced-motion\".>\n\n## Accessibility (WCAG 2.2 AA)\n- **Focus:** <style; which colour on which surface>\n- **Targets:** <48 px controls; inline exceptions>\n- **Links & states:** <underline rule; how active/error states differ beyond colour>\n- **Motion:** <what moves, where its pause control is>\n- **Sticky elements:** <none | header uses --header-h + scroll-padding-top>\n- **Help:** <where the contact link sits on every page>\n- **Text on images:** <none | scrim spec and resulting ratio>\n- **Reflow:** <anything special at 320 px>\n- **Exempt from contrast:** <disabled controls / decorative shapes, named>\n\n## Components\n| Component | Renders (from content model) | Look | ≤ 320 px |\n|---|---|---|---|\n| Header + nav | Navigation items | … | … |\n| Post card | Article: image, category, title, excerpt | … | … |\n| … | | | |\n\n## Page composition\n- **<Page>** — <sections top to bottom, each naming its component and band colour>\n- …\n\n## Imagery\n<subjects, mood and colour fit for photos; search keywords; treatment (frame, crop ratio, radius,\nduotone…); alt text written from what the photo shows.>\n\n## Don'ts\n- <3–6 site-specific rules, e.g. \"no grey cards\", \"never put body text on the primary accent\">\n````\n\n## Invariants\n\n- **One question.** Refine owns discovery; this step only chooses among directions (or keeps the\n  existing look).\n- **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed\n  exemptions.\n- **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand\n  colours keep their hue but only appear in roles where they pass.\n- **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.\n- **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,\n  emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no\n  logo shows the site name as text and gets no new logo.\n- **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.\n- **The tokens block is the only source of values** (breakpoints excepted). Components and pages\n  reference tokens, never raw hex codes, pixel values or font names.\n- **No backend calls.** Design never waits on provision and never writes to the instance.\n- **Never overwrite an existing `design.md` silently.** Keep or change, as in Step 1.\n"
+        "text": "---\nname: headless-step-design\ndescription: \"Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend.\"\n---\n\n# headless-step-design\n\nTurn the brief into a look the user has chosen, and write it down so the frontend can't drift from\nit. **One question, three options, one spec.** The output is **files** (`design.md` plus the logo),\nnot a conversation: the frontend step implements `design.md`, not the chat.\n\n**In:** `brief.md` (required), `content-model.md` (if it exists yet), reference sites and assets the\nuser gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in\n`~/.hostinger/<domain>/brand/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? This step defers to the user\n> Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the\n> design — **do not generate three directions or write a prescriptive `design.md` over their project.**\n> The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*\n> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when\n> **Design direction** keeps the look of the app in this folder: their own code already carries it.\n> Either write nothing, or capture only what the user explicitly asks for (a short note of their\n> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow\n> moves on to frontend. The logo and token work here apply only when **Build mode is \"Agent designs\n> and builds\"**.\n\nThis is **prepare work**: it runs while provision settles (see *Background provision & the instance\nbarrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.\n\n**Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user\n**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three\ndirections (Step 4), never both. \"You decide\" is a valid answer.\n\n**Talk like a person, not a designer.** Everything the user reads describes how the site will\n**look and feel**: colours by name (\"hot pink, butter yellow\"), lettering by feel (\"big chunky\nrounded headlines\"), and the details they'll notice (\"photos tilted like stickers on a scrapbook\").\nNo hex codes, font names, or design and tech words (palette, accent, tokens, shape language,\ncontrast, favicon, wordmark, lockup, WCAG, 8-point grid, Next.js, SSR, `state.json`), even when\nthe owner's own brand guide names them. This covers every message until the step ends, including\nthe keep/change question, your one-line confirmation after the pick and the message you hand off\nwith.\n\n**Two hard rules apply to every direction, however loud or quiet it is:**\n\n- **The 8-point grid.** Every spacing, sizing and layout value is a multiple of 8 px (details in\n  5.2).\n- **WCAG 2.2 Level AA.** Colour, focus, motion, target size and reflow are decided here, so the\n  frontend can't build them wrong (details in 5.1 and 5.3).\n\nThese rules are for you, not the user. **Never mention them**: no grid, contrast, WCAG or\naccessibility talk in anything the user reads, and no \"all options follow…\" reassurances. The user\njudges the look in the preview; the rules just make sure it works.\n\n---\n\n## Step 1 — Read the workspace, then the resume check\n\nRead `brief.md`, `state.json`, and `content-model.md` if it exists.\n\n- **`design.md` already exists and this is not a redesign** → don't overwrite it. Describe the\n  current look in two or three plain sentences and ask: *keep it, or change something?* That is this\n  step's one question.\n  - **Keep** → leave the file alone and go straight to the `state.json` update at the end of Step 7.\n  - **Change** → edit only what they asked for, re-run the 5.x checks on what changed, then save.\n- **The site is already deployed** (`deploy.json` exists, or `state.json` has `deployed_at`) and the\n  user asked for a different look → this is a **redesign**. Tell them plainly: their content stays\n  as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7\n  as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user\n  wants to keep and move away from the rest.\n- **The brief says to keep the current look** (*Design direction* says so in the owner's words:\n  \"keep the look we have\", \"same look, new platform\") → follow *Keep the current look* below instead\n  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone\n  are signals for Step 2, not a request to keep.\n\n### Keep the current look\n\n1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method\n   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its\n   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save\n   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;\n   a logo seen only in a screenshot counts as no logo file, so list \"logo file needed\" under gaps in\n   the final report. The app in this folder (the path under `brief.md` → **Existing project**):\n   read its source; no build or browser needed.\n   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,\n     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with\n     the page background and body text taken from the root layout or `body`.\n   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or\n     `@import`, and the `font-family` on `body` and headings.\n   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;\n     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon\n     declared by `<link rel=\"icon\">` in `index.html` or the root layout's `metadata.icons`. Copy them\n     unchanged into `brand/`.\n\n   Files or exact colours and fonts the owner supplied win over anything you read.\n2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or\n   change something?* \"Keep the look we have\" still gets this question; skip it only when the brief\n   says to change nothing at all (\"keep it exactly as it is\"). A skipped tool result is not Keep; see\n   *When you ask the user* in the top-level `SKILL.md`. Change →\n   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.\n3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a\n   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font\n   without an `@fontsource` package swaps to the closest one that resolves (5.4).\n4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no\n   existing logo, the header shows the site name as text in the kept display font, and no logo is\n   designed.\n5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:\n   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say \"No favicon kept\".\n   - *Built from* says \"Kept, not rebuilt\". *Measured* still gives the width at `--logo-h-sm`\n     (≤ 192 px; else lower `--logo-h-sm` or show the name as text on small screens), and the header\n     link has `alt` = the site name and a target of at least 24 px (as in Step 6).\n   - With no logo: *Files* says \"None\", *Use* says the header link holds the site name as text in\n     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.\n\n## Step 2 — Collect the signals\n\nBefore inventing anything, gather what already constrains the design:\n\n| Signal | Where | How it constrains |\n|---|---|---|\n| Tone, purpose, audience | `brief.md` → *Tone*, *Purpose*, *Audience* | Sets the mood all three directions must fit |\n| Brand assets | `brief.md` → *Assets* | Logo, brand colours and fonts are **fixed** in every direction. Never recolour a supplied logo; Step 6 uses it instead of designing one |\n| Pages and entities | `content-model.md` → *Navigation*, *Pages*, *Articles*; if it doesn't exist yet, `brief.md` → *Pages* | Drives the component inventory and page composition |\n| Reference sites | URLs in the brief or the conversation | Cues to borrow (see below) |\n| Images already sourced | `content-model.md` → the image lines under *Articles* (skip if none yet) | Glance at a few at small size; keep accents from clashing with their dominant colours |\n| Current design (redesign only) | existing `design.md` | What to keep, what to move away from |\n\n**Reference sites.** Open each one in a real browser if you have one. Static fetches are often\nblocked or rate-limited; without a browser, fetch the HTML and its linked CSS instead. If neither\nworks, say so in one line and continue from the brief alone. Pull **cues**:\n\n- **Fonts:** the computed `font-family` of `h1`/`h2` and of body `p`.\n- **Colours:** background colours weighted by painted area (element width × height), the top 5–8.\n  Skip transparent and semi-transparent backgrounds and overlays (cookie banners, modals, chat\n  widgets). Text colours come from headings, paragraphs and links.\n- **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in\n  the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.\n\n**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).\nDon't use its logo, copy, images or exact layout. **The brief wins** over the live site when they\ndisagree (the user's words are what they want). Note the mismatch in the direction.\n\n**Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand\nyellow can be a background band or a large decorative shape, never body text. Say so in the\ndirection.\n\n## Step 3 — Derive three directions\n\nWrite three directions that **all fit the brief** but are **genuinely different**. Vary at least two\nof: palette (temperature, saturation, light vs. dark), type personality (geometric, grotesk, serif,\ndisplay), and shape language (sharp vs. round, flat vs. outlined, airy vs. dense). Three shades of\none idea is not a choice. Neither is a wildcard that ignores the brief.\n\nOrder them: **A is the recommendation**, the closest reading of the brief and references. B and C\npush in different directions.\n\nEach direction carries exactly this:\n\n- **Name** — 2–3 evocative words (\"Sticker-book maximal\", \"Quiet gallery\").\n- **Mood** — one line on how the site feels.\n- **Palette** — 5–7 hex colours with roles (base, text, primary accent, secondary accents, surface).\n  These are the core colours the user sees; Step 5 may add derived shades (link, muted, error,\n  focus) as tokens.\n- **Type** — a display font and a body font, both self-hostable through `@fontsource`.\n- **Shape language** — corners, borders, shadows and density in one phrase (\"chunky 3 px ink\n  outlines, hard 8 px offset shadows, tilted cards\").\n- **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,\n  a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).\n- **Logo idea** — one line on how the name becomes a logo, using a move from Step 6 (\"letters\n  bounce in different colours and the O is a smiley\"). When the brief carries a logo wish (*Design\n  direction* or *Assets*), every direction's logo idea is that wish in its own style. A wish is words\n  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).\n\n**Only offer what can pass.** Before asking, run two quick gates on **all three**:\n\n1. **Contrast gate.** Every colour that will carry text (base, surfaces, and any accent used as a\n   text block) has a palette text colour reaching **4.5:1** on it. Two text colours are fine (dark on\n   light blocks, light on dark ones). Accents that only ever hold large text need 3:1.\n2. **Font gate.** Each font resolves on npm, and the display font also has a static `@fontsource`\n   package, because the logo is built from it (5.4).\n\nA direction that fails either gate gets adjusted, not offered as-is. Don't offer a look that only\nworks by breaking the rules, such as body text on a neon accent or a marquee that can't be stopped.\nLoud is fine; inaccessible is not.\n\n**Avoid the template look** unless the brief asks for neutral: Inter or Roboto everywhere, a\nblue-to-purple gradient hero, centred hero with three feature cards, grey cards on white. Every\ndirection should look like *this* site, not a starter theme.\n\n## Step 4 — Ask once\n\nAsk **one** question, with A marked as the recommendation. With a structured question UI (multiple\nchoice plus an \"other\" field), each option's **label** is the direction's name and its\n**description** is one or two plain sentences, under ~160 characters. Without one, write each\noption as one line in the same shape.\n\nThe description says what the site would feel like, the main colours by name, what the lettering\nis like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your\nnotes. The question may end with one plain clause saying they can add a logo idea to their pick, but\nnever suggest one or give an example: that idea would end up in the logo.\n\n> **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,\n> chunky headlines, tilted sticker photos and a bouncy logo with a smiley O.\n\n> **Midnight disco** — A dark, glowing night-out feel: deep purple with neon pink, yellow and\n> turquoise, heavy rounded headlines and a logo like a neon sign.\n\nThen:\n\n- **Pick** → use it as written, and confirm the look in one line.\n- **\"You decide\"** → use A, and tell them in one line which look you went with.\n- **Skipped tool result** → not an answer: write the three directions as plain lines\n  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).\n- **A mix** (\"A's colours with C's fonts\") → merge them. Don't ask again.\n- **Something else** → build a direction from what they said, run Step 5, and use it. Don't send\n  three new options.\n\n**Logo wish.** An answer can carry a logo idea next to the pick (\"A, and make the logo a little\nteapot\"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.\nWhenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms\nthe pick: *\"The logo follows your idea: a little teapot.\"* If the kit can't draw it as said (a\ndetailed illustration, a photo), build its closest kit version and name what you simplified in that\nsame line. Don't ask a follow-up.\n\nDon't ask about anything else in this step.\n\n## Step 5 — Check the chosen direction\n\nFix any problem found here by adjusting the direction, not by asking the user. Don't report these\nchecks or their fixes; the user sees the result in the preview.\n\n### 5.1 Contrast — WCAG 2.2 SC 1.4.3 and 1.4.11\n\n**Which pairs count:** walk the component inventory you're about to write (Components table). For\neach component, list every foreground/background combination in every state: default, hover,\nfocus, active, error. Include text on coloured bands (footer links on dark, marquee text, chips),\nplaceholder text and photo credits. Compute the WCAG contrast ratio for each:\n\n| Kind | Examples | Minimum |\n|---|---|---|\n| Body text | paragraphs, links, footer text, input text, placeholder text, captions | **4.5:1** |\n| Large text | ≥ 24 px regular, or ≥ 18.66 px (14 pt) bold | **3:1** |\n| Non-text | input and button boundaries (when the outline is the only edge), focus indicator against each adjacent colour, icons that carry meaning, chip outlines | **3:1** |\n\nA pair that fails gets a darker or lighter shade of the **same hue**; never drop a brand colour. A\nnew shade becomes a token (for example `--color-link` or `--color-muted`). Disabled controls and\npure decoration are exempt, but say which elements those are. **Text on photos** needs a scrim or\nsolid backing that gets the text to 4.5:1 against the lightest part of the image. If you can't\nguarantee that, don't put text on photos. Record every pair and its ratio in `design.md`.\n\n```js\n// node -e: relative luminance + contrast ratio, hex in → ratio out\nconst L = h => { const c = h.match(/\\w\\w/g).map(x => parseInt(x, 16) / 255)\n  .map(v => v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);\n  return 0.2126 * c[0] + 0.7152 * c[1] + 0.0722 * c[2]; };\nconst ratio = (a, b) => { const [x, y] = [L(a), L(b)].sort((m, n) => n - m); return (x + 0.05) / (y + 0.05); };\n```\n\n### 5.2 The 8-point grid\n\nValues are checked in px at the default 16 px root (`0.5rem` = 8 px).\n\n| What | Rule |\n|---|---|\n| Spacing (padding, margin, gap) | Multiples of 8: `8 16 24 32 48 64 96 128`. **4 px** is the only half-step, and only inside small components (chip padding, icon-to-label gap) |\n| Component sizes | Heights and fixed widths are multiples of 8. Buttons, nav items and inputs are **48 px** tall minimum |\n| Radii | `8 16 24 32`, or `999px` for pills. 4 px only on elements under 32 px tall |\n| Line heights | Fixed-size text: multiples of 8 (16/24, 18/32, 24/32), or of 4 for text ≤ 14 px (12/16, 14/20). Fluid headings (`clamp()` sizes) use a unitless line-height (1.0–1.2) and are exempt, because their line box can't stay on the grid at every size |\n| Fluid spacing | `clamp()` for spacing or sizes uses grid values at both ends. Fluid **font sizes** are exempt |\n| Shadow offsets | 4 or 8 multiples |\n| Layout | Content width, gutters and breakpoints are multiples of 8 (e.g. `1200`, `768`, `1024`, `1280`) |\n| Exempt | Border and outline widths (1–4 px), focus offset, font sizes, the `999px` pill radius, the 4-multiple line heights above, and anything that isn't a length (angles like a `-2deg` tilt, durations, opacity) |\n\nEvery value in the **Tokens** block must pass this table.\n\n### 5.3 WCAG 2.2 AA — what the design must decide\n\nThese criteria are settled at design time. Write each answer into the **Accessibility** section of\n`design.md`.\n\n| Criterion | The design must specify |\n|---|---|\n| 1.4.1 Use of colour | Links in running text are underlined, not colour-only. States (active nav, selected, error) also change shape, weight or an icon, not only colour |\n| 1.4.4 Resize text | Font sizes in `rem`; nothing breaks at 200 % zoom |\n| 1.4.10 Reflow | Works at **320 CSS px** wide with no horizontal scroll. Every component has a stated ≤ 320 px behaviour; decorative pieces never widen the page |\n| 1.4.12 Text spacing | No fixed-height boxes around text, so nothing clips when a user overrides spacing (line-height 1.5, paragraph spacing 2×, letter-spacing 0.12 em, word-spacing 0.16 em). Fixed line-height tokens are fine; clipping is not |\n| 2.2.2 Pause, Stop, Hide | Anything that moves on its own for more than 5 s (marquee, carousel, animated sticker) has a **visible pause control**, and doesn't move at all under `prefers-reduced-motion`. Hover-to-pause alone doesn't count |\n| 2.3.1 Three flashes | Nothing flashes more than 3 times a second |\n| 2.4.7 Focus visible | One focus style (e.g. 3 px outline, 2 px offset) whose colour reaches 3:1 against **every** surface it can appear on. Name a second colour for surfaces where the first fails |\n| 2.4.11 Focus not obscured *(new in 2.2)* | Sticky headers, cookie bars and chat bubbles never cover the focused element. Either the header isn't sticky, or `scroll-padding-top: var(--header-h)` |\n| 2.5.8 Target size *(new in 2.2)* | Interactive targets ≥ 24 × 24 px with spacing. On this grid: **48 px** for buttons, nav and inputs, ≥ 24 px for inline icon buttons |\n| 3.2.6 Consistent help *(new in 2.2)* | The contact or help link sits in the same place on every page (e.g. last nav item and footer) |\n| 3.3.2 Labels | Every form field has a visible label; placeholders are never the only label |\n| 1.1.1 Text alternatives | Content images get alt text describing what they show; purely decorative images and shapes get empty alt or `aria-hidden` |\n\n### 5.4 Fonts resolve\n\nFor each family, prefer the variable package and fall back to the static one:\n`npm view @fontsource-variable/<slug> version`, then `npm view @fontsource/<slug> version`. One must\nanswer with a version. If neither does, swap to the closest family that does. Record the exact\npackage names. The **display** family must also resolve as a static package\n(`npm view @fontsource/<slug> version`): the static packages ship `.woff` files the logo kit can\nread; the variable ones ship only `.woff2`.\n\n### 5.5 The header fits on one line\n\nThe header is where a cramped width shows first: the logo, every nav item and the call-to-action\nbutton share one row, and when they run out of room they wrap mid-phrase (\"Services &\" over\n\"Pricing\", \"Book\" over \"Appointment\"). That always looks broken. Decide it here so the frontend\ncan't build it that way.\n\n- **Labels never break mid-phrase.** Nav links and the header button get `white-space: nowrap`, so a\n  two-word label stays on one line or not at all.\n- **Collapse before it wraps — not at 320 px.** The inline nav is replaced by a menu (hamburger)\n  button at the width where the logo, all nav items and the button stop fitting on one line, which is\n  usually wider than the mobile breakpoint. Estimate that width from the number of nav items and their\n  label lengths, round up to a multiple of 8, and make it the header's own breakpoint. Below it, only\n  the logo and the menu button show; the nav items and the CTA move into the opened menu.\n- **Keep header labels short.** A nav label is one or two short words; a button label is a two-word\n  verb phrase at most (\"Book now\", not \"Book an Appointment\"). When the content model gives a long\n  navigation label, the header may show a shorter form (\"Contact & Booking\" → \"Contact\") while the\n  page keeps its full name — note the shortened label in the **Header + nav** row.\n- Record the header breakpoint in *Grid, shape & motion* and the `nowrap` + collapse rule in the\n  **Header + nav** component row (and its `≤ 320 px` cell).\n\n## Step 6 — Design the logo\n\n**The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and\nskip the rest of this step. Never redraw or recolour it.\n\nOtherwise, turn the name into a **designed** logo: shaped, coloured and composed. Typing the name in\nthe display font with an emoji or symbol next to it doesn't count. Build the chosen direction's **logo\nidea** (as replaced by any logo wish, Step 4) with one or two of these moves:\n\n| Move | What it is | Suits |\n|---|---|---|\n| **Letter swap** | One letter becomes a simple shape tied to the subject: O → smiley, sun, loaf, plate, eye; I → candle, pencil, brush; A → roof, tent. Swap **one character** only, even if the letter appears twice, and the word must still read | Playful, friendly brands |\n| **Bounce** | Letters tilt ±3–6° and bob off the baseline, each in a palette colour, with an ink outline and hard shadow | Loud, maximal directions |\n| **Stack** | The name split over 2–3 lines on coloured tiles, or set as a tight block | Long names, bold directions |\n| **Tag** | The main word large; a short second word on a pill, ribbon or tab | Two-part names (\"Dopamine Den\") |\n| **Seal** | The name around a ring, with a monogram or symbol in the middle | A secondary mark (footer, hero sticker, social avatar), never the header logo |\n| **Typographic contrast** | Weight, style or case contrast between words (a light italic word next to a heavy upright one), custom tight spacing, one shared stroke or cut between letters | Quiet, refined, editorial directions |\n\nNo emoji, clip-art, gradients, or details that vanish at small sizes. Colours come only from the\npalette (base and surface colours count).\n\n### Build it with the logo kit\n\nThe kit (`logo-kit.mjs`, next to this file) does the error-prone parts: it outlines letters into\nvector paths, sets text on a circle, draws the outline-and-shadow treatment, measures, validates\nthe output, checks the sizes and renders a preview. You write the composition. Copy the kit into\n`brand/` so the build is self-contained and a redesign can re-run it:\n\n```bash\nmkdir -p ~/.hostinger/<domain>/brand && cd ~/.hostinger/<domain>/brand\ncp <the folder this SKILL.md is in>/logo-kit.mjs .\nnpm init -y >/dev/null && npm i opentype.js @resvg/resvg-js @fontsource/<display-slug>\n```\n\nWrite `brand/logo-build.mjs`, import from `./logo-kit.mjs`, and always run it from `brand/`\n(packages resolve from the working directory):\n\n| Kit function | Use |\n|---|---|\n| `loadFont(slug, weight, style)` | Loads a static `@fontsource` weight across all its subsets (`latin`, `latin-ext`, …), so accented letters like Ė or Ł resolve; `style` is `'normal'` or `'italic'`. Throws if that weight or style isn't in the package, so pick another |\n| `layout(font, text, size)` | Kerned glyph positions, total width, `capHeight`, `xHeight`; place letters one by one for bounce or swap. Throws if a character isn't in the font |\n| `glyphPath(glyph, x, baselineY, size)` / `textPath(font, text, x, baselineY, size)` | Outlined path data for one letter or a whole word. For typographic contrast, load two weights or styles and set each word with `textPath` |\n| `pathBox(font, text, x, baselineY, size)` | Tight box around a word's outlines; size the viewBox from it plus room for outlines, shadows and tilt |\n| `arcText(font, text, { cx, cy, r, size })` | Letters around a circle, for seals |\n| `sticker(d, { fill, ink, strokeWidth, shadow, shadowColor, transform })` | Ink outline + hard offset shadow, for outlined directions. On dark backgrounds give the outline and shadow a palette colour that shows (`shadowColor` defaults to `ink`) |\n| `svgDoc({ width, height, title, body })` | Root SVG with `role=\"img\"` and a `<title>` |\n| `check(svg)` | Throws on `NaN`, live `<text>`, a missing title or viewBox, or an `&` that isn't an XML entity. Run it on every file before writing |\n| `tile(size, fill)` | The rounded tile for the mark and favicon; draw the symbol after it |\n| `widthBudget(letterHeight, height)` | The widest viewBox that still fits 192 px on small screens, for a logo of that height; see below |\n| `checkLogo({ logo, mark, favicon, letterHeight, background })` | Runs `check()` on all three files, checks their sizes and renders `brand/logo-preview.png`; see below |\n\nWrap every file in `svgDoc()`, never a hand-written `<svg>` or `<title>`: it escapes the site name,\nand one bare `&` (as in \"Salt & Pepper\") makes the browser show nothing.\n\nNever call opentype's `path.toPathData()` directly; the kit's serializer exists because opentype.js\n2.0 writes `NaN` into some paths, and browsers silently stop drawing at the first `NaN`.\n\n### Deliver four files\n\n| File | What | Must read clearly at |\n|---|---|---|\n| `brand/logo.svg` | The primary, mostly horizontal logo for the header | Its header display heights (desktop and small screens) |\n| `brand/logo-mark.svg` | A square icon from the same idea (initial, monogram or the swapped symbol) on a `tile()` in a palette colour | 32 px |\n| `brand/favicon.svg` | The simplest form of the mark: same tile, no shadow, no thin details, outlines thickened if it has any | 16 px, on both light and dark browser tab bars |\n| `brand/logo-build.mjs` | The script that built them, with `package.json`, kept so a redesign can adjust it | — |\n\nAdd `brand/logo-seal.svg` only if the direction uses a seal as a secondary mark. Delete\n`brand/node_modules` when you're done; a redesign runs `npm i` in `brand/` first.\n\n**Compose within the budget, so the first build passes.** The small-screen logo is at most 192 px\nwide with letters at least 16 px tall, so the whole logo can be only about 10–12 times as wide as\nits smallest letters are tall, whatever its height. On one line that's about ten letters plus a\nsymbol; a longer name stacks or tags, and a second word set at half size halves the room. Size the\nviewBox in `logo-build.mjs` against `widthBudget(letterHeight, viewBoxHeight)`, the exact limit at\nthe heights the kit picks; with your own `heights`, the FAIL line gives the limit. Draw the mark's\nsymbol from simple, recognisable shapes that still read at 32 px; fine natural forms like petals or\nleaves turn to mush.\n\n**Check the sizes and look at it after every build.** `letterHeight` is in viewBox units: the\n`xHeight` from `layout()` when the logo is mostly lowercase, `capHeight` when it's mostly capitals;\nfor mixed fonts, the smaller word's. End `logo-build.mjs` with:\n\n```js\ncheckLogo({ logo, mark, favicon, letterHeight, background: '<page background colour>' });\n```\n\nIt picks the header heights for you: `--logo-h-sm` is the smallest multiple of 8 that makes the\nletters 16 px, and `--logo-h` the same but at least 48 px, both at most 80 px, so a stacked lockup\nkeeps its words large or sets the mark beside them. Pass `heights: { desktop, small }` only when the\ndirection needs a larger header logo. It first prints `--logo-h`, `--logo-h-sm` and the **Measured**\nline for `design.md`, then PASS or FAIL for the logo's letters ≥ 16 px at both\nheights, width ≤ 192 px on small screens, headroom around everything drawn and heights in multiples\nof 8; for the mark and favicon sitting on a `tile()` with nothing clipped and room around\nthe symbol; and for no shadow on the favicon. Every FAIL names its fixes and the number to reach. It\nthen renders `logo-preview.png` (the logo at both heights on the page background, the mark at 32 px\nand favicon at 16 px on light and dark strips, each also enlarged), and throws if anything failed.\n\nThen read `logo-preview.png`; don't search for another renderer or read the SVG source. Rebuild only\nfor a FAIL line or something in the preview that reads wrong, such as collisions, a clipped or\nclearly off-centre mark, or a favicon detail that turns to mush, and fix everything you saw in one\nrebuild. Optical nudges of a few pixels and the header height aren't reasons to rebuild. A symbol\ngets one redraw: if it still reads wrong, replace it with a simpler form of the idea, such as the\ninitial, in the next build. If the kit says \"preview not rendered\", rely on the size check and list\n\"logo not visually checked\" under gaps in the final report.\n\nThe logo is exempt from text-contrast minimums, but the header link around it needs `alt` = the site\nname and a target of at least 24 px.\n\nDon't show the logo to the user in this step; they see it in the preview.\n\n## Step 7 — Write `design.md` and hand off\n\nWrite `design.md` from the template below. Fill every section. The **Tokens** block is copied\nverbatim into the frontend's global stylesheet, so it must be valid CSS. Every colour, font, type\nsize, line height, space, radius and shadow used elsewhere in the file must exist in it as a token.\nThe template's token list is the **minimum**: add what the design needs (`--color-error`,\n`--color-on-accent`, `--leading-h3`…) under the same naming scheme.\n**Breakpoints are the one exception**: CSS custom properties don't work inside `@media`, so they are\nlisted in *Grid, shape & motion* as plain px values.\n\nThen update `state.json`: set `\"stage\": \"frontend\"` (also for a redesign: restyle, then validate and\ndeploy) and `updated_at` to the current UTC time (ISO 8601). Don't touch `provision`, `run` or\n`history` (`run-log.mjs` owns those), or add other keys.\n\nIf content prepare hasn't sourced images yet, it now follows `design.md` → **Imagery** (see\n`04-content-model/SKILL.md`).\n\nHand off in one or two plain sentences, as *Talk like a person* says: \"The look is set: warm cream,\nbrown lettering, berry buttons and your loaf logo.\" Nothing after it: no font names, file names or\nstages, and gaps such as a missing icon file or a font that may not load go in the final report.\n\n## `design.md` template\n\n````markdown\n# Design — <domain>\n\n> Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,\n> <C name>). <\"Picked by the user.\" | \"User said 'you decide'; recommendation A used.\" |\n> \"Merged by the user: <what>.\"> — or, when kept: \"Kept the owner's current look from <site URL |\n> screenshots | brand guide>, confirmed on <YYYY-MM-DD>.\"\n\n## Direction\n<2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),\nthe signature element.>\n\n## Stack\n**<chosen by the frontend step>** — design doesn't decide the stack. The frontend step (06) picks and\nconfirms the framework (default Next.js SSR; ecommerce must be SSR) and records it in\n`state.json → frontend`. Leave this as a placeholder for the frontend step to fill in.\n\n## Tokens\n```css\n:root {\n  /* colour — semantic names, never \"--pink-2\" */\n  --color-base: #…;      --color-text: #…;      --color-surface: #…;    --color-muted: #…;\n  --color-primary: #…;   --color-accent-1: #…;  --color-accent-2: #…;   --color-link: #…;\n  --color-focus: #…;     --color-focus-alt: #…; /* for surfaces where --color-focus is < 3:1 */\n  /* type */\n  --font-display: '<Family> Variable', <fallback stack>;\n  --font-body: '<Family> Variable', <fallback stack>;\n  --text-body: …rem;   --leading-body: …rem;    /* 8-multiple in px */\n  --text-small: …rem;  --leading-small: …rem;   /* 4-multiple in px */\n  --text-h1: clamp(…rem, …, …rem);  --text-h2: clamp(…);  --text-h3: …rem;\n  --leading-display: 1.05;          /* unitless; fluid headings are grid-exempt */\n  /* 8-point grid */\n  --space-half: 4px;  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;  --space-4: 32px;\n  --space-6: 48px;    --space-8: 64px;  --space-12: 96px; --space-16: 128px;\n  --target-min: 48px;\n  /* shape */\n  --radius-sm: 8px;  --radius-card: …;  --radius-pill: 999px;\n  --border: …;  --shadow: …;  --shadow-hover: …;\n  --focus-ring: 3px solid var(--color-focus);  --focus-offset: 2px;\n  /* layout */\n  --content-max: …px;  /* multiple of 8 */\n  --header-h: …px;     /* header band height, multiple of 8; scroll-padding-top uses it if sticky */\n  --logo-h: …px;       /* header logo height on desktop, multiple of 8 */\n  --logo-h-sm: …px;    /* on small screens; logo ≤ 192 px wide at this height */\n}\n```\n\n## Palette roles\n| Token | Hex | Used for |\n|---|---|---|\n\n## Contrast\n| Foreground | Background | Kind (body text / large text / non-text) | Ratio | Needs | Passes |\n|---|---|---|---|---|---|\n\n## Type\n- **Display:** <family> (`@fontsource-variable/<slug>@<version>`), weights …, tracking …; sizes `--text-h1…h3`, `--leading-display`\n- **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch\n\n## Logo\n- **Concept:** <the move(s), and what any swapped letter or symbol stands for, plus \"From the owner:\n  '<their words>'\" only when it follows their wish | \"Supplied by the user\" | \"Kept from <source>\" |\n  \"No logo: owner kept the current look\" (header shows the site name as text in `--font-display`)>\n- **Built from:** `@fontsource/<display-slug>@<version>`, weight(s)/style(s) …\n- **Files:** `brand/logo.svg` (header, `--logo-h` desktop / `--logo-h-sm` small screens),\n  `brand/logo-mark.svg`, `brand/favicon.svg`<, `brand/logo-seal.svg`>; source `brand/logo-build.mjs`\n- **Measured:** letters … px tall at `--logo-h-sm`; width … px at `--logo-h-sm`\n- **Use:** the frontend copies `brand/*.svg` into `public/`. Header: `<a href=\"/\"><img src=\"/logo.svg\"\n  alt=\"<Site name>\" style=\"height: var(--logo-h)\"></a>` (switch to `--logo-h-sm` on small screens).\n  Favicon: `<link rel=\"icon\" href=\"/favicon.svg\" type=\"image/svg+xml\">`\n- **Don't:** recolour, stretch, add effects, or retype the logo as live text.\n\n## Grid, shape & motion\n<section padding desktop/mobile (space tokens), gutters, breakpoints in px (multiples of 8), borders,\nradii, shadows, hover behaviour, every animation and its pause control, and \"no motion under\nprefers-reduced-motion\".>\n\n## Accessibility (WCAG 2.2 AA)\n- **Focus:** <style; which colour on which surface>\n- **Targets:** <48 px controls; inline exceptions>\n- **Links & states:** <underline rule; how active/error states differ beyond colour>\n- **Motion:** <what moves, where its pause control is>\n- **Sticky elements:** <none | header uses --header-h + scroll-padding-top>\n- **Help:** <where the contact link sits on every page>\n- **Text on images:** <none | scrim spec and resulting ratio>\n- **Reflow:** <anything special at 320 px>\n- **Exempt from contrast:** <disabled controls / decorative shapes, named>\n\n## Components\n| Component | Renders (from content model) | Look | ≤ 320 px |\n|---|---|---|---|\n| Header + nav | Navigation items | … Nav links and the button never wrap (`white-space: nowrap`); the inline nav collapses to a menu button at <px> (the width it stops fitting one line). | Logo + menu button only; nav items and CTA inside the menu |\n| Post card | Article: image, category, title, excerpt | … | … |\n| … | | | |\n\n## Page composition\n- **<Page>** — <sections top to bottom, each naming its component and band colour>\n- …\n\n## Imagery\n<subjects, mood and colour fit for photos; search keywords; treatment (frame, crop ratio, radius,\nduotone…); alt text written from what the photo shows.>\n\n## Don'ts\n- <3–6 site-specific rules, e.g. \"no grey cards\", \"never put body text on the primary accent\">\n````\n\n## Invariants\n\n- **One question.** Refine owns discovery; this step only chooses among directions (or keeps the\n  existing look).\n- **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed\n  exemptions.\n- **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand\n  colours keep their hue but only appear in roles where they pass.\n- **The header never wraps.** Nav labels and the header button stay on one line (`white-space:\n  nowrap`); the inline nav collapses to a menu button at the width it stops fitting, not only at the\n  mobile breakpoint (5.5).\n- **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.\n- **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,\n  emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no\n  logo shows the site name as text and gets no new logo.\n- **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.\n- **The tokens block is the only source of values** (breakpoints excepted). Components and pages\n  reference tokens, never raw hex codes, pixel values or font names.\n- **No backend calls.** Design never waits on provision and never writes to the instance.\n- **Never overwrite an existing `design.md` silently.** Keep or change, as in Step 1.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/05-design/logo-kit.mjs",

package/src/servers/agency-hosting.js

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 import instructions from '../core/instructions.agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.17.2', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.17.3', tools, instructions });

package/src/servers/agency-hosting.ts

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 import instructions from '../core/instructions.agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.17.2', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.17.3', tools, instructions });

package/src/servers/agent-readiness.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.17.3', tools });

package/src/servers/agent-readiness.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.17.3', tools });

package/src/servers/all.js

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.17.2', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.17.3', tools, instructions, skills });

package/src/servers/all.ts

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.17.2', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.17.3', tools, instructions, skills });

package/src/servers/billing.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.17.3', tools });

package/src/servers/billing.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.17.3', tools });

package/src/servers/dns.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.17.3', tools });

package/src/servers/dns.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.17.3', tools });

package/src/servers/domains.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.17.3', tools });

package/src/servers/domains.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.17.3', tools });

package/src/servers/ecommerce.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.17.3', tools });

package/src/servers/ecommerce.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.17.3', tools });

package/src/servers/horizons.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.17.3', tools });

package/src/servers/horizons.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.17.3', tools });

package/src/servers/hosting.js

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '3.17.2', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.17.3', tools, instructions });

package/src/servers/hosting.ts

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '3.17.2', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.17.3', tools, instructions });

package/src/servers/mail.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.17.3', tools });

package/src/servers/mail.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.17.3', tools });

package/src/servers/reach.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.17.3', tools });

package/src/servers/reach.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.17.3', tools });

package/src/servers/vps.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.17.3', tools });

package/src/servers/vps.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.17.3', tools });

package/src/servers/wordpress.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.17.3', tools });

package/src/servers/wordpress.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '3.17.2', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.17.3', tools });