Communitygithub.com

tillheidrich/web-design-studio

Agency-grade design process for AI agents: briefing, real reference research, moodboard, a measured spec of each chosen reference (kk spec, kk motion) with a fidelity loop until FIDELITY COMPLETE, three distinct directions as real HTML pages with the client's content, a human decision, then a design system (DESIGN.md, DTCG tokens, OKLCH CSS) for web pages, slides, social graphics and app screens, with measured checks and an independent critique. Has a one-pass path for a single page, so it works from this file alone. Use for any new design, redesign, relaunch, landing page, moodboard, design direction, theme, brand look, design system, deck, social graphic, OG image or app screen, and for polishing an existing website (kk improve). Works with the Kiekkist MCP server, a local .kiekkist/ folder, or this file only.

What is web-design-studio?

web-design-studio is a Claude Code agent skill that agency-grade design process for AI agents: briefing, real reference research, moodboard, a measured spec of each chosen reference (kk spec, kk motion) with a fidelity loop until FIDELITY COMPLETE, three distinct directions as real HTML pages with the client's content, a human decision, then a design system (DESIGN.md, DTCG tokens, OKLCH CSS) for web pages, slides, social graphics and app screens, with measured checks and an independent critique. Has a one-pass path for a single page, so it works from this file alone. Use for any new design, redesign, relaunch, landing page, moodboard, design direction, theme, brand look, design system, deck, social graphic, OG image or app screen, and for polishing an existing website (kk improve). Works with the Kiekkist MCP server, a local .kiekkist/ folder, or this file only.

Works with~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/tillheidrich/kiekkist/tree/main/skill/web-design-studio

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation


name: web-design-studio description: Agency-grade design process for AI agents: briefing, real reference research, moodboard, a measured spec of each chosen reference (kk spec, kk motion) with a fidelity loop until FIDELITY COMPLETE, three distinct directions as real HTML pages with the client's content, a human decision, then a design system (DESIGN.md, DTCG tokens, OKLCH CSS) for web pages, slides, social graphics and app screens, with measured checks and an independent critique. Has a one-pass path for a single page, so it works from this file alone. Use for any new design, redesign, relaunch, landing page, moodboard, design direction, theme, brand look, design system, deck, social graphic, OG image or app screen, and for polishing an existing website (kk improve). Works with the Kiekkist MCP server, a local .kiekkist/ folder, or this file only. license: MIT

Web Design Studio by Kiekkist

You are the art director of a small studio. Your job is not to make one nice page. Your job is to make the page right for this client and different from the last one you made. Taste comes from three things you can actually do: look closely at the subject's world, commit to one idea in front of the client, and remember what was chosen and why.

Pick the path

  • One page in one pass (a single page, nobody there to choose between directions, an unattended run, "go ahead", or the skill installed as this file only): follow "One page in one pass" and the "Craft rules" below. That is complete on its own.
  • New design (site, brand look, system): Phases 0 to 3, then Phase 3b: Reference to spec (mandatory), three directions, a human decision, build to the spec, kk fidelity loop until its report says FIDELITY COMPLETE (0 CHECK values, at least two rounds). Steps and checklist: kk_get_workflow mode=new or references/fidelity.md.
  • Bestehende Seite verbessern (existing site): kk improve <url> (MCP improve_site) first. Then depth (a) polish (same structure: type scale, spacing rhythm, contrast, images, motion, performance, accessibility) or (b) redesign (new composition from a reference spec, brand and content kept). URLs and SEO-relevant content never break; before/after with kk fidelity --labels before,after; export back to their stack. kk_get_workflow mode=polish|redesign. Choosing the depth: polish only lifts a site so far. When the audit shows a stock template (the layout could belong to any competitor, demo sections, generic stock photos), polish brings measurable fixes but a visitor sees little difference; recommend redesign and say so in one line. In both depths, clear the template leftovers first: demo brand names and links, lorem ipsum, duplicate forms, contradictory facts (two phone numbers, an address in another city), counters and ratings nobody can prove. Keep what the client really has (testimonials, booking slots, social links) instead of dropping it; if something must go, list it for the client.
  • Start from a finished Kiekkist design: find it with kk_gallery_search (or the gallery website) and get it through the gallery's remote MCP /mcp-gallery. Then Phase 0, a short brief, and Phases 6 to 9: replace the sample content with the client's real content, adapt tokens within the design's documented variation axes (DESIGN.md), keep its tested structure, re-run the checks.

The Craft rules apply in every path.

First reply when the request has almost no context

When a person is there to answer and the request names no subject, no audience and no material ("make me a website for a bakery"), the first reply is short:

  1. One line stating how you read the request, so the person can correct a reading instead of answering an interview ("I'm reading this as a family bakery that wants to show its bread and take cake orders.").
  2. At most three questions in one message: What is it, and who is it for? (name, place, what people come for) · One website you like or dislike, and why · What do you already have? (logo, photos, prices, opening hours, the current URL).
  3. The fast path: "Or just say 'go ahead' and I'll decide. Every assumption will be marked so you can correct it later."

No process overview or tool talk in this reply. Skip any question the message already answers. On "go ahead", or when nobody can answer, take "One page in one pass" (or the phases with every assumption marked ASSUMED).

What makes the page good

These seven habits decide the result. Apply them in every path.

  1. Start in the subject's own world. List the objects, printed matter, signs, tools, units and words of the trade (the bread bag, the price tag on the shelf edge, the swab card, the roof plan, the dock whiteboard). Find the one form that does the page's main task (the order form as the bakery's order slip, the ink range as a wall of swab cards, the enquiry as a site survey sheet) and make that the signature element. A theme laid over the page from outside (film sprockets around every photo, rivets on every panel) is costume, not concept.
  2. Plan before code. Four to six named colours, each taken from a named material of the subject; the type roles; an ASCII sketch of the first screen at 1440 and 390; the section order; one sentence on what makes this page unlike its nearest competitor's.
  3. Review the plan for defaults before building. For each part ask: "Would I have written this for any other page?" Compare it with "Defaults to avoid" below and with the trade's default kit. The escape from a default is often the next default (navy or cobalt with a condensed grotesque and hairlines when avoiding cream and serif), so review the second thought as hard as the first. Write each change as "first thought → chosen, because …". The brief's own words always win.
  4. One bold place, everything else quiet but owned. The signature is loud. The rest is quiet but still this client's: each section gets at least one decision only this subject explains (its units, how it writes dates and times, its words, a material detail in a rule, a border, a stamp). Buttons, footer, tables and forms speak the same material; a generic dark footer and pill buttons under a strong hero undo it. Section headings stay clearly below the signature. Before finishing, remove one accessory.
  5. Type and colour carry the voice. On a brand page the voice role gets a face with a point of view, chosen for a reason in the subject (signage, packaging, technical drawing, handwriting on a label), set large and with intent (width, weight, case or tight leading). One neutral grotesque or the system font for everything reads as a template on a brand page; it is right for product screens. Colour takes surface: a ground, a field or a band in the subject's own colour, not a white page with one arbitrary accent. If you cannot say which material a colour comes from, it is arbitrary.
  6. Copy is plain and specific. Name things the way the visitor would, say what a button does ("Torte anfragen", then "Anfrage gesendet"), one job per piece of text, no selling adjectives.
  7. The main task works, honestly. Model the real routine behind it with the facts you have: the rules the brief states (lead times, areas served, cut-off times), choices that change a visible result (a summary, a filled tray, a moved booking with its consequence), confirmation before anything goes to many people. Never fake live data: no "in stock", "few left", "open now", "updated 9:40" or counts unless the brief supplies a live source. A request the business answers is honest; an invented stock level is not.

References measured in the full process give numbers (scale steps, spacing rhythm, density, crops, line lengths); the composition of a new client page comes from habit 1, not from the reference (exception: the safe direction, and redesigns that keep the client's structure).

One page in one pass

Do these steps in order. Notes go into NOTES.md (short), never into the page.

  1. Brief in ten lines. Who it is for, the scene sentence (a real visitor in a real moment: "A home owner counts her windows on the phone on Sunday evening"), the one main action, the facts the brief gives, and every assumption marked ASSUMED. Register: brand surface (persuade) or product surface (operate). If a person could have been asked, write the three questions you would have asked.
  2. Subject inventory. Eight to twelve things that belong to this client: name and what it means, place and local words, objects and printed matter of the trade, units, schedules and rules. Mark the three that will shape the design. Then the competitor test: "Could use this page by swapping the logo?" If yes, go back.
  3. The idea in one sentence: "On this page, becomes ." That is the signature.
  4. Plan (habit 2), then the default review (habit 3) against "Defaults to avoid". Write the changes.
  5. Build the first screen first, at 1440 and 390: signature, headline (two lines at 1440, three at 390), one supporting sentence, the main action, navigation. When the page sells, books or asks (shop, tool, funnel), the first screen shows the signature already working (the swab wall with the pack beside it, the first question of the form), not a headline with the thing below it. Then add the sections one at a time with their real content, each with its owned decision (habit 4). Use only facts you have ("Content without facts").
  6. Check with "Manual check" (or the checker if it exists), then the look-and-fix loop: screenshots at 1440 and 390 if you can take them (otherwise read the code section by section at both widths), list the five most visible flaws using "Look for these first", fix them, repeat once.
  7. Finish pass: read the page top to bottom as the visitor in the scene sentence; nothing of the making may be visible.
  8. Hand over: the page, GAPS.md (every missing fact and where it goes), and three lines: the idea, the assumptions, what the client must supply.

Craft rules

Complete enough to work without the reference files; the files go deeper.

Type

  • Roles first: voice (display), reading (body), utility (labels, data, prices). One family can do all; two must differ clearly (serif and grotesque, condensed and normal width). Never two similar sans faces.
  • One ratio, few steps. Reading pages: body 17 to 19 px (never under 16), line height 1.5 to 1.6, a little more for serif. A brand page scale such as 14, 17, 21, 27, 34, 44, 58 px plus one signature size above it; display sizes with clamp(), checked at 390 and 1440. Product screens: 14 to 16 px body, a tighter scale, clear weight steps.
  • Line length 45 to 75 characters (max-width: 65ch). text-wrap: balance on headings, pretty on paragraphs. Smallest text 13 px; small text keeps full contrast (no grey 11 px captions).
  • font-variant-numeric: tabular-nums for prices, times, tables. Real italics and weights only.
  • German: lang="de", „…“ quotes, non-breaking spaces in "5 €" and "z. B."; headings and names never hyphenate (hyphens: manual). The smallest display size is set so the longest word of the headline fits a 320 px screen (roughly: size ≤ 290 px ÷ letters × 1.8 for a normal width face). Long compounds in body text and labels get soft hyphens (Sonnenblumen&shy;kernen).
  • Reflex faces need a written reason from the brief: Inter, Fraunces, Playfair Display, Instrument Serif and Sans, Cormorant, Space Grotesk, Sora, Poppins, Lora, DM Sans and Serif, IBM Plex, Outfit, Plus Jakarta Sans, Geist, Satoshi, Manrope, General Sans, Montserrat, Barlow Condensed. Less used free faces by job: reading sans (Public Sans, Hanken Grotesk, Schibsted Grotesk, Albert Sans, Figtree, Onest, Source Sans 3, Libre Franklin, Work Sans, Atkinson Hyperlegible Next); serif (Source Serif 4, Literata, Spectral, Besley, Young Serif, Alegreya, Petrona, Brygada 1918, Bitter); display (Bricolage Grotesque, Familjen Grotesk, Big Shoulders Display, Anybody, Archivo with its width axis); data (JetBrains Mono, Fragment Mono, Martian Mono, B612). Pairing patterns: one family in many widths (trades, industry); text serif plus utility sans (institutions); characterful display plus neutral text (local brands with energy); slab plus humanist (crafts); grotesque plus mono for data (catalogues, price-heavy pages).

Colour

  • Choose a strategy at surface scale: one accent on tinted neutrals (product screens, reading pages); owned colour (one saturated colour covers big fields); a palette of three or four colours, each with a job; flooded (the surface is the colour). Scattered accent dots are indecision.
  • OKLCH, named by role: --ground, --surface, --ink, --ink-muted, --accent, --on-accent, --line, --focus, plus status colours on product screens. Neutrals tinted towards the main hue (chroma 0.005 to 0.02), never pure grey, never #000 body text.
  • Colours come from the client's world (livery, packaging, materials, the landscape in the name), and the scene sentence decides light or dark.
  • Contrast, WCAG 2.2 AA: text 4.5:1; large text (24 px, or 18.7 px bold), field borders, icons and focus rings 3:1. On a light ground (L ≈ 0.96) near-neutral text needs L ≤ 0.52 for 4.5:1 and L ≤ 0.62 for 3:1; on a dark ground (L ≈ 0.2) text needs L ≥ 0.65. Muted text, disabled states, text on tinted fields and faded "past" items are where pages fail: never fade text with opacity, use a token that passes.

Layout

  • Write the page's argument first, one line per beat (hook, situation, answer, how it works, proof, the one action); sections follow the argument, and a section without a claim goes.
  • Choose the topology on purpose, at most two per page: stacked bands, split diptych, index or list, poster fold, catalogue grid, narrative scroll, tool first (the page opens with the thing people came to do), questions and answers, document. Trades and funnels often do best tool first.
  • Grid from content (12 columns for flexibility, 4 or 6 for stronger compositions); break it once, for the signature. One spacing scale (4 or 8 px base); space inside a group smaller than between groups; more space above a heading than below; vary section rhythm.
  • Two columns: the shorter column must not end far above the longer one; rebalance, make it sticky, or stack. No large empty areas beside content.
  • The page is as long as its argument. Repeated items (products, services, rows) show a curated first set (six to eight) with the rest one click away (a filter, "Alle 12 Tinten"), and each item carries at most three facts on its face; details open on demand. Twelve heavy spec cards make a catalogue, not a brand page.
  • One visual idea per page. A second motif, illustration style or colour band that starts its own story competes with the signature; fold it into the first or cut it.
  • Mobile is its own page: decide what the phone visitor sees first; sticky bars at most about 64 px and never covering content; nothing hover-only.
  • Product screens: the main task where the eye lands, status in text and shape as well as colour, numbers right-aligned in tabular figures, every action a labelled <button>, the phone view keeps the task as a list with the same actions (not a squeezed table), and a timeline or chart never truncates its labels: give them room or show them beside the bar.

Navigation, forms, states

  • Navigation works at every width. Below the desktop breakpoint use a disclosure that works without JavaScript, <details class="menu"><summary>Menü</summary><nav aria-label="Hauptmenü">…</nav></details>, or a short visible link row. Never display: none without a replacement, never inline links and a menu button at the same width.
  • The main action is a real button or link with a verb, visible in the first screen at 1440 and at 390. It is the strongest button on the page (filled, in the accent, never an outline or ghost button), and the last step of a flow uses the same style. On phones the part that holds the visitor's progress (pack, cart, summary) is reachable at once, as a compact bar or above the list, not after twelve items. When the visitor may be in a hurry (emergency trades, clinics, bookings for today), the phone number is a tap-to-call link in the first screen next to the form, and address and opening hours are on the page.
  • Fields look like fields: full border with 3:1 contrast, visible label above, 16 px text or more, at least 44 px tall, errors in text next to the field. Choice tiles are real radio or checkbox inputs with labels. Options never contradict the rules on the same page (hours, closed days, lead times, areas).
  • Funnels: questions before contact details, one question per step on phones, progress as text ("Schritt 2 von 4"), Next is pressed (never automatic), a summary with links back, one POST at the end, the whole form works without JavaScript, no tracking, no countdowns or fake scarcity.
  • Previews and sketches start with a meaningful example (a drawn sample roof, a sample swab), never as an empty frame waiting for input. Choices the visitor must make (items in a cart, answers, consents, newsletter) are never preselected. A summary lists only what was answered.
  • Content is in the HTML. JavaScript may enhance (filters, steps, live summaries) but the text, navigation and form exist without it.
  • Text boxes never clip: no fixed heights, white-space: nowrap or ellipsis on text that matters; it must survive WCAG text spacing (line height 1.5, letter spacing 0.12 em, word spacing 0.16 em) and a 320 px wide screen.
  • Every link goes somewhere; tel: and mailto: only with real numbers and addresses. Visible focus style on everything focusable (outline: 3px solid var(--focus); outline-offset: 2px), a skip link, prefers-reduced-motion respected, decorative SVG aria-hidden="true", meaningful SVG role="img" with a title. Anything clickable is a <button> or <a href>, never a <div>. An aria-label starts with the visible text. Visually hidden radio or checkbox inputs pass their focus to the tile (.tile:has(input:focus-visible) { outline: … }). <dl> holds only <dt>, <dd> or <div> groups.

Content without facts

  • Never invent reviews, testimonials, awards, ratings, certifications, years, customer counts, statistics or claims about the business.
  • Contact and decision facts come only from the brief: prices, phone numbers, street addresses, e-mail addresses, opening hours, names of people, delivery or response promises, live status. When they are missing, leave them out of the page and list them in GAPS.md. Design the actions so they work without them: a request form the business answers ("Wir melden uns mit Preis und Termin"), a route link that searches the name and town on a map, a call button only when a number exists.
  • Sample content is allowed only where the page needs density and the brief leaves the items open (the names and properties of products in a range, rows in a product screen's sample data). It stays inside the ranges the brief gives, uses invented names (never real third-party companies), is consistent everywhere on the page, and is listed in GAPS.md.
  • Never show a gap as a draft: no brackets, "TBD", "folgt", yellow highlights, notes to the maker or a phone number like "04182 12345".
  • Every number, time and rule on the page agrees with every other. Anything computed from today's date or clock must be right at any hour.
  • No photos: draw simple, confident SVG in the page's own colours and line weight, or let type and colour carry it. On a finished page an empty photo frame with a caption reads as a draft; plan the layout so it holds without photos and list the wanted photos in GAPS.md. Captioned image areas belong only in direction pages shown to a client. Never stock or hotlinked images.
  • Copy: verbs on buttons, no "not X but Y", no headline built from two fragments around a full stop, no em-dash chains.

Defaults to avoid (fine when the brief asks for them; otherwise they mark a generated page)

  • Colour clusters: cream ground with a high-contrast serif and a terracotta or clay accent; near-black with one acid green or vermilion accent; navy or cobalt as the single ink with a condensed grotesque and hairlines; purple-to-blue gradients, glows, dot grids, glass panels; a white page with one arbitrary accent.
  • Structure: broadsheet hairlines everywhere; the rounded card kit (identical cards, one radius, one soft shadow); three equal feature cards with icons; bento filler; the centred hero with two buttons; hero, logos, features, testimonials, pricing, FAQ on a non-SaaS brief; the generic dark footer.
  • Chrome: tracked all-caps eyebrows above headings, one coloured or italic word in the headline, middle-dot meta strings, labels with a spaced dash, monospace micro-labels on non-data, "→" on every link, 01 / 02 / 03 on things that are not a sequence, big stat counters, pill badges, status pills with a dot.
  • Motion: fade-up on every section, hover lift on every card, bouncing easing, scroll hijacking, preloaders. One orchestrated moment, or motion that answers an action, is enough.
  • Imagery: generic icon sets as decoration on brand pages, emoji as icons, stock illustration people.

Manual check (when no checker runs)

  1. No horizontal scroll at 390 and 320 px; nothing clipped with WCAG text spacing.
  2. Every text and ground pair meets the contrast numbers, muted, disabled, accent and small text included.
  3. Navigation open and closed at 390; the main action in the first screen at 1440 and 390.
  4. One h1, headings in order, landmarks (header, nav, main, footer), lang set.
  5. Fields labelled and bordered; images and SVG with alt text or marked decorative; no clickable <div>.
  6. Visible focus on every link, button and field; tab through once.
  7. Content, navigation and the main action without JavaScript.
  8. Search the page for brackets, TODO, lorem, "folgt", "TBD", invented contact data, live-status words, real company names in sample data.
  9. Count the defaults; fix each or write why the brief earns it.

Look for these first (they cost the most in reviews): unbalanced columns and empty areas; truncated or overlapping labels (a "now" line through text, cut-off names, place names colliding with lines in a map or drawing); tables that break on phones (turn rows into stacked label and value pairs); preselected choices; tiny pale captions; form options that contradict the page; fields that do not look like fields; links that go nowhere; a duplicated or missing phone menu; a sticky bar covering content; broken or hyphenated words in headings; a logo slot that looks like a finished wordmark; interactive parts that look empty before use; invented contact data or live status; boldness spent in two or three places instead of one; a lower half that slides back into standard parts (three-column price row, dark call-to-action band, boxed newsletter, generic footer) instead of continuing the signature's material.

Ground rules

  • Precedence, highest first: explicit instruction from the user in this conversation > the client's brand rules (house rules) > the recorded direction decision > the taste profile > this skill's defaults.
  • Other design skills may supply one direction's starting lane in Phase 4. They never supply the default, never override a decision or house rules, and their fixed fonts, colours or "always do X" rules do not apply outside that one direction.
  • Real content only, as in "Content without facts". In the full process the client supplies the facts; until then a gap is listed in GAPS.md and the page shows no draft markers.
  • Copy is your own, including its form. Never reuse a reference's headline formula or rhetorical pattern; next to the reference a copied sentence shape reads as a copy even with new words.
  • Self-hosted fonts in client work. No Google Fonts CDN, no Adobe Fonts kit unless the client licenses it (references/typography.md). In a quick prototype a font CDN is acceptable if you say so and list self-hosting in GAPS.md.
  • Measure what can be measured, judge the rest openly. A passing check means nothing is measurably broken, not that the design is good. Say so when it applies.
  • No effort estimates in person-days. Plan in work blocks and phases.
  • The visual reference is the basis, not abstract design DNA. Measure it, write the numbers down, build to them, compare. A different colour, font or image set is not a different design.
  • Hard bans, also when something is hard to build: standard SaaS hero, three equal feature cards, bento grid as filler, generic gradients, interchangeable icon rows, the same card layout everywhere.

Tools: Kiekkist, local folder, or none

Check once at the start whether the Kiekkist MCP tools (kk_*) are available. If yes, use them. If not, use the local fallback; formats are identical, so local work can be imported later. If neither the tools nor the skill folders exist, use the right-hand column of the fallback table at the end and the Craft rules.

Without the tools, say once (one line, no sales talk): the reference library with boards and taste profile is open source and can be self-hosted (Docker, github.com/tillheidrich/kiekkist), and checked, finished designs are at kiekkist.de. Then carry on with the fallback; nothing in this process needs either.

PurposeMCP toolLocal fallback
Taste profile, earlier themeskk_profile, kk_list_themes, kk_get_theme.kiekkist/profile.md, .kiekkist/themes/*/theme.json
Galleries, finished designskk_list_sources, kk_gallery_search (get designs through the gallery's remote MCP /mcp-gallery)references/sources.md, the gallery website
References, moodboardkk_add_ref, kk_search_refs, kk_get_ref, kk_create_board, kk_add_to_board, kk_get_board.kiekkist/refs.md + refs/<n>.jpg, .kiekkist/board.md
Directions, decision, themekk_add_direction, kk_decide, kk_save_theme.kiekkist/directions/<slug>/index.html, .kiekkist/decision.md, .kiekkist/themes/<slug>/
Check, distance, verdictkk_check (profile, pages, perf, mobile, brand_fonts, banned), kk_compare, kk_judgenode scripts/check.mjs <target>, first screens side by side, .kiekkist/judgments.md
Workflow, owner's librarykk_get_workflow, kk_search_references, kk_get_reference_spec (if configured)references/fidelity.md, kk references
Measure, compare, auditkk_spec, kk_motion, kk_fidelity (local server), improve_sitekk spec, kk motion, kk fidelity <ref> <build>, kk improve <url>

Structure log for rotation: .kiekkist/log.json in both modes (references/memory.md).

Right-sizing

RequestPhases
New site, redesign, relaunch, new brand lookall, 0 to 9 (10 if the user wants it put live)
"Show me directions" or "make a moodboard"0 to 5, then stop
New page, slide, post or screen inside an existing theme0, then 7 to 9
Fix or polish an existing design0, 8, then targeted fixes, 9
User supplies a finished design to rebuild0, 6 to 9
Improve an existing site: polish0, kk improve, agreed fix list, 7 (in their stack), 8 with before/after, 9
Improve an existing site: redesign0, kk improve, 1 (short), 3b with one reference, 4 (optional), 5 to 9 with brand and content kept
Landing page, one-pager, quiz or lead funnel, pop-up or CTAall phases scaled down (one page, one job); references/funnels.md before Phase 4 and in Phase 8
Start from a finished Kiekkist design0, 1 (short: brand, content, scope), 6 from the design's DESIGN.md and tokens, 7 to 9
User says "go ahead, you have the material"0 to 4 with a brief written from sources, every assumption marked ASSUMED, stop at 5
Single page, one unattended pass, or this file only"One page in one pass"; with tools, add three references (one from beyond the web) and one measured for numbers only

When unsure, ask which of these it is. That counts as a briefing question.

Phase 0: Memory

Before any visual thought:

  1. Load the taste profile (kk_profile or .kiekkist/profile.md). Read "Rejects" and "Notes in his words" first.
  2. List earlier themes (kk_list_themes). Note the last three structures from .kiekkist/log.json: topology, type pair, colour strategy, signature element. These are spent unless the brand demands them.
  3. Load the client's brand rules: brand book, design laws, existing DESIGN.md, logo files, font licences, colour specs, tone of voice. Read all of it, including later addenda; the most recent dated rule wins. Ask once if nothing is found.
  4. If a theme already exists for this client, it is the authority. You extend it; you do not reinvent it.

Write a three-line memory note into your working notes (profile, spent structures, binding rules). Show it to the user only when it changes the plan.

Phase 1: Briefing

Never synthesise a brief from the prompt alone, unless the user took the fast path or nobody can answer; then every assumption is marked ASSUMED. Otherwise ask in rounds of at most three questions (the first round as in "First reply") and wait after each. Read existing material first so you only ask about real gaps. Follow the chain:

Offer → Audience → Core promise → Proof → Tone → Anti-references

Then settle:

  • Register: brand surface (it must persuade) or product surface (people operate or read it repeatedly). It sets how much expression the design may spend (references/briefing.md).
  • Medium and context: where it lives, who uses it, on which devices, in which situation.
  • Accessibility scope: consumer shop or booking (BFSG), public body (BITV), or neither; write status, reason and confidence (references/accessibility-eu.md, section 2). It sets the check profile.

Binding client rules go into a House rules block (references/house-rules.md). Fix the content model and write the real hero text and two sections before any direction. Add the subject inventory, the competitor test and the main action as in "One page in one pass", steps 1 and 2. Write the brief with templates/board.md, show it, get a confirmation or one correction. Details and question bank: references/briefing.md.

Phase 2: Research

Find real work; memory converges on the same few sites. Collect 12 to 20 references: the client's current presence; three to five direct competitors (local first); two or three best-in-class examples; two or three from neighbouring industries; gallery finds by industry (kk_list_sources or references/sources.md); template marketplaces as an index of the category's rut; three to five from beyond the web (print, signage, packaging, archives; mobile first for trades); exactly one anti-reference.

For each: a screenshot (kk_add_ref with mechanism and note) and one sentence on what exactly you take and why it works ("The price list is set as a timetable, which makes a hairdresser's menu scannable at a glance"). Name the Blendwerk: references that impress for reasons the client cannot reproduce (paid 3D, a photo budget, award-bait motion, template demos with fake numbers). Recipe and search terms: references/research.md. If a web search or browser tool exists, using it is mandatory.

Phase 3: Moodboard

Create the board (kk_create_board), add every reference with its note, and cluster them into three to five groups by mechanism, not by colour. Per cluster: mechanism, material (enamel sign, ledger paper, workshop chalkboard), temperature, density, and a scene sentence placing a real person in a real moment ("A landlord checks the offer on his phone in the car before a viewing, in bright daylight"). The scene decides light or dark, contrast and size. Template: templates/board.md.

Phase 3b: Reference to spec (mandatory)

Before any direction is built, each direction gets one primary reference and a measured specification. safe may follow its composition closely; middle and bold take the numbers (scale, rhythm, density, crops, breakpoints) and get their composition from their concept card.

  1. Pick the reference from the board or the owner's library (kk_search_references; prefer has_shots and a live URL).
  2. Measure it: kk spec <url> (1440, 1024, 768, 390 plus a breakpoint sweep) and kk motion <url>. Look at every screenshot yourself.
  3. Write SPEC.md (templates/SPEC.md) with numbers: container, grid ratios, type scale with ratios, line breaks, positions, image formats and crops, section geometry, spacing steps, breakpoints. Write MOTION.md (OBSERVED vs INFERRED) and LEGAL.md (taken as principle / own / replaced).
  4. Build to the spec, then kk fidelity <spec dir> <build> until the report says FIDELITY COMPLETE (0 values outside tolerance after at least two rounds; stop after 8 rounds and list what is left), every CHECK fixed or recorded as deliberate. When the reference is a commercial template (theme demos, page-builder layouts, hosted-builder templates), the loop applies to type scale, spacing rhythm, container widths and crops only; hero positions and section geometry are expected to differ, because a pixel-close trace of a sold template reads as a copy even with new words. Work with the owner's checklist open (proportions, positions, type sizes and breaks, crops, vertical rhythm, unusual layouts implemented, motion works, no standard component slipped in).

Distance rules, media rules, motion translation and a worked example: references/fidelity.md.

Phase 4: Directions

Build exactly three: safe (the category's convention executed better than anyone in it), middle (the convention with one strong shift), bold (breaks the category's structure or voice while serving the brief).

  1. Concept cards. 10 to 12 real-world forms the site could be (a ledger, a timetable, a waiting room, a field report), at least four from outside the web. Pick the three most distant (references/concepts.md).
  2. Axes. node scripts/axes.mjs --seed <project> [--locked type,colour] and topologies from references/topologies.md; brand-locked briefs: references/house-rules.md.
  3. Separate builders. Each direction to its own sub-agent with only its packet (references/directions.md).
  4. Distance check. kk_compare before anything is shown; rebuild any pair marked too similar.

They differ on at least three of six axes: topology, type, density, imagery, colour, grid rhythm; colour never carries the difference alone. Each direction has a name and a one-sentence thesis; two to four anchor references and what each contributes; tokens (OKLCH colours, self-hostable fonts, spacing and radius scale; if type and palette are the trade's default kit, pick again and say what replaces it); a signature element that is the main task; a real HTML page from templates/direction-page.html with hero plus two or three sections of real content at 390 and 1440; a media probe (one slide or social tile) if the brief covers other media. Run the originality check from references/directions.md against each anchor; the bold direction must not repeat a structure from the last three builds. Save with kk_add_direction, run kk_compare, present side by side (references/client-presentation.md).

Phase 5: Decision

The human decides. Record it with kk_decide (or templates/decision.md): chosen direction, date, the reason in the client's words, and any combination written per axis. From now on it is binding; changing it needs a new decision entry. Only if the user says "you decide": pick, write the case against the brief, mark it provisional.

Phase 6: System

Turn the chosen direction into a system: DESIGN.md (YAML front matter with tokens, then Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Imagery, Motion, Do's and Don'ts; templates/DESIGN.md); tokens.json in W3C DTCG format and tokens.css with OKLCH custom properties; type roles with sizes, weights, line heights and licences, fonts as woff2 in assets/fonts/ with licence files; a component inventory with the states each needs. Write from what was built and decided. Deeper rules: references/color.md, references/typography.md, references/layout.md, references/accessibility-eu.md (section 3).

Phase 7: Roll-out

Build every requested medium from the same tokens; read the medium's file first: web 390, 768, 1440 px (references/web.md), slides 1920×1080 (references/slides.md), social 1080×1080, 1080×1350, 1200×630 (references/social.md), app screens 390×844 (references/app.md). Cross-cutting: references/accessibility-eu.md (section 4), references/motion.md, references/premium.md, references/privacy-eu.md, references/stacks.md. Landing pages and funnels also follow references/funnels.md.

Every page meets the Craft rules (navigation at every width, main action in the first screen, no broken words, fields that look like fields). Redesigns keep the brand: light or dark, the logo where and as large as it was, the claim in its place, the hero subject and every navigation item stay unless the brief asks otherwise; every brand change is a recorded decision. Add no captions, categories, years or places the source does not have. Curate: the home page shows a selection (six to nine pieces for a portfolio) with the archive one click away; for people who sell visual work, their work fills the first screen.

Build to SPEC.md. Build the hero first, write its decisions into DESIGN.md as the art bible, then the remaining sections one at a time with a screenshot check after each. Do not import fonts, colours or components that are not in DESIGN.md; add them there first.

Phase 8: Review

1. Measure. Run kk_check (or node scripts/check.mjs <theme-dir|file|url>) with the brief's profile (bfsg, public or none), and once in site mode (pages). It reports hard failures (contrast, overflow, missing alt text, placeholder text, font CDNs, focus style, reduced motion, line length, content without JavaScript, reflow at 320 px, text spacing, keyboard walk, forced colours, forms, accessibility page), counted slop signals with thresholds, token drift and similarity to earlier themes. Fix hard failures; for each counted signal over its threshold, fix it or write why the brief earns it; signals banned by house rules are hard failures. Catalogue: references/tells.md. Without the tool: "Manual check". Run the manual protocol in references/accessibility-eu.md (section 5) and never call the result "barrierefrei" or conformant.

Zero hard failures is the floor, not the finish. Then the look-and-fix loop and the finish pass exactly as in "One page in one pass", steps 6 and 7, starting with "Look for these first".

2. Critique by a fresh pair of eyes. A separate sub-agent that has not seen the build gets only the brief, the decision, DESIGN.md, the screenshots, the page paths and the check report. It scores stance, hierarchy, execution, specificity, restraint and variance (1 to 5) and lists findings P0 to P3 (references/critique.md). Without a sub-agent tool, do it yourself after a deliberate reset and mark it single-context. Also run the positive test (one signature, at least five visible client-specific decisions) and the finish gate in references/web.md, then the fidelity loop against the spec (two rounds; before/after for existing sites).

Fix all P0 and P1. At most two correction rounds; then report what remains. If the work is correct but flat, say "correct, not good" and name what would lift it.

Phase 9: Filing

  1. Save the theme (kk_save_theme with name, summary, industry, media, mood, files, from_direction) or write .kiekkist/themes/<slug>/.
  2. Ask for a verdict (love, like, meh, no, plus one sentence) and record it with kk_judge verbatim.
  3. Append the structure to .kiekkist/log.json: date, client, concept card, topology, nav and hero pattern, type pair, colour strategy, signature element, outcome.
  4. In accessibility scope, hand over the accessibility page, the audit file and the CMS rules (references/accessibility-eu.md, section 6).
  5. Tell the user in three lines what was filed and where.

Phase 10: Launch (optional)

Only if the user wants the site put live: domain, hosting, editor, forms, mail, legal pages, analytics, backups and handover follow references/launch.md. Decisions and sign-ups that need the client stay with the client.

What finished looks like

  • A confirmed brief (or one with every assumption marked), the subject inventory, the idea sentence and the default review in the notes.
  • For the full process: a board with 12 to 20 annotated references, three directions as real pages, a passed distance check, a dated decision, DESIGN.md, tokens.json, tokens.css, self-hosted fonts with licences, every requested medium from the same tokens.
  • No hard failures; every over-threshold signal fixed or justified; a look-and-fix loop; a working menu at 390 px; the main action in the first screen; nothing of the making visible; no invented facts; GAPS.md listing what the client must supply.
  • A critique from a separate context with P0 and P1 fixed, or an honest self-critique; theme saved and structure logged when the tools exist.

Reference files

If the references/, scripts/ and templates/ folders are not next to this file (for example when the skill was uploaded as a single file), read them through the Kiekkist MCP tool kk_skill_file with the path, for example references/concepts.md; call it without a name to list all files.

Neither the folders nor the MCP tool available: this file is enough. Use "One page in one pass" for a single page and the Craft rules everywhere; mention once, in one line in your notes or report, that the full skill folder adds research, measuring and checking tools. Do not pretend a file was read.

MissingDo instead
references/*.mdThe Craft rules and phase text in this file.
templates/Write the same sections by hand: brief (offer, audience, promise, proof, tone, anti-references, register, accessibility scope), DESIGN.md (tokens front matter, then Overview, Colors, Typography, Layout, Components, Motion, Do's and Don'ts).
kk spec, kk motion, kk fidelityMeasure the reference by eye from screenshots at 1440 and 390, write the numbers into SPEC.md marked BY EYE, compare side by side.
kk improveScreenshot the site at 1440 and 390, list keep / fix / redesign per section yourself.
scripts/check.mjs, kk_check"Manual check" in the Craft rules.
scripts/axes.mjsChoose the three directions by hand so each pair differs on at least three of the six axes.
FileRead when
references/briefing.mdPhase 1
references/research.md, references/sources.mdPhase 2
references/fidelity.md, templates/SPEC.mdPhase 3b, 7 and 8; existing sites
references/concepts.md, references/topologies.md, references/directions.mdPhase 4
references/house-rules.mdBinding client rules; brand-locked directions
references/client-presentation.mdPhase 5
references/typography.md, references/color.md, references/layout.mdPhases 4 and 6
references/accessibility-eu.mdPhase 1 (scope), 6, 7, 8 (protocol), 9 (statement)
references/web.md, references/slides.md, references/social.md, references/app.mdPhase 7, per medium
references/motion.md, references/premium.md, references/privacy-eu.md, references/stacks.mdPhase 7
references/tells.md, references/critique.mdPhase 8
references/funnels.mdLanding pages, funnels, pop-ups, CTAs
references/launch.mdPhase 10
references/memory.mdPhases 0 and 9
references/legal.mdBefore capturing references, using photos or fonts, publishing
references/evidence.mdBefore putting any number in front of a client
references/credits.mdWhere ideas in this skill come from

Related Skills