How Taste Skill works.

The repo holds one skill, design-taste-frontend. Install it with the skills CLI, as a plugin for Claude Code or Codex, or link it from a clone. Every method installs the same folder.

• Node 22 or newer and an installed Chrome, Edge or Chromium. The inspector drives the browser over the DevTools protocol and installs nothing. Set CHROME_PATH if the browser is somewhere unusual.
• draw.mjs, lint.mjs and assets.mjs run on Node 18 too. Only the inspector and scenes.mjs need 22.
• No API keys. Finding pictures needs network access.
• Working files go to .taste-skill/ in your project. The draw history lives in ~/.taste-skill/history.json, which TASTE_SKILL_HISTORY moves.

Run the install command again; the install name has not changed. For the Claude Code plugin, /plugin update upgrades it. A linked clone updates with git pull. Release notes are in the changelog.

The skill is built from a study of 247 curated sites from One Page Love and Awwwards Sites of the Day. It is a folder, not a single file: SKILL.md with the run and the house rules, eleven reference files, a library and zero-dependency scripts. A build runs in six steps.

SKILL.md writes the same run out in ten steps. After the look rounds it adds a motion layer (the inspector fails a page where fewer than eight elements move), and it ends with a report. The agent does not report until the inspector shows no FAIL at 1440, 768 and 390 on the final page.

The report tells you:

• the direction it dealt, with its seed, and every redraw with the reason;
• the idea sentence and the live thing;
• the scores from its last critique round and what still falls short;
• every found picture and clip with its title, creator, licence and source, and where its credit sits;
• which photographs and drawings stand in for your own, and which sample content to replace.

The skill first decides which kind of work it is doing. A page is read and scrolled: a landing page, a product site, a portfolio, an event, a restaurant. An app screen is worked in: a dashboard, an admin or analytics view, settings, billing, an inbox or queue, a wallet, an editor.

App screens arrived in 2.1 and take their own route, written in app-screens.md:

• Inventory the data and the jobs: the objects and their fields, realistic sizes, who opens the screen and what they do next. The data goes in a file, with totals computed from the rows.
• Name the screen's one question and its one finding. The largest block answers the question.
• draw.mjs --app deals one of seven styles distilled from 23 real product screens: achromatic ledger, framed sheet, accent ladder, editorial greeting, pastel consumer, true-black flat and data terminal.
• Build the shell, the data and every state (empty, zero, loading, error) with assets/app.css and assets/charts.js.
• Check with inspect.mjs --app, which judges the screen by app rules instead of page rules.

A software product's landing page is a page, but every interface fragment it shows (the hero's live screen, a feature crop, a chart) is built as a real piece of the app, with real data and the page's colours and type kept. The agent deals the app's style once, in its own folder:

Redesigns, restyles and reviews of an existing page or app screen are part of the main skill since 2.1.1. The route:

1. Record the before. Inspect the running page into .taste-skill/before (with --app for an app screen), lint its source, and read the code for what must survive: routes, forms, data, behaviour and the brand's own assets.
2. A review stops here, with a critique of the before screenshots, the inspector's measurements and the three changes that would move the page most.
3. Keep the stack, the content and what works. No framework or styling migration. A restyle keeps the layout and takes type, colour and components from a dealt direction. A redesign deals a full direction and rebuilds the sections inside the existing components.
4. Work in order of effect: type, colour, the frame, states, then stock components such as icon cards, pill badges and card grids.
5. Prove it. Inspect again into .taste-skill/after, compare every width, click through every link, form and menu that worked before, and report the measurements side by side.

inspect.mjs opens the page at 1440, 768 and 390 pixels, measures what a visitor would see and saves screenshots to .taste-skill/inspect/. Each finding is a FAIL or a WARN. A FAIL is a banned tell or a broken page, and the page is not done while one remains. A WARN is usually wrong and stays only with a reason the agent can say to a designer.

Two tools sit beside it. lint.mjs scans the source before a render, for what a browser cannot see, such as copy habits and motion values. scenes.mjs photographs every scroll scene from 0 to 100 percent of its hold, on desktop, on a phone and with reduced motion.

Run the last check on the production build: bundlers change the CSS a visitor receives, and the inspector warns (dev-server) when it is looking at a Vite, webpack or Next dev server. The full list of checks is in rules.mjs.

The draw deals from library/, distilled from the 247-site study and an October 2026 study of the latest 100 Awwwards Sites of the Day. The agent does not read it whole; the script deals from it and remembers recent draws, so consecutive projects do not look alike.

A direction is a way of composing, such as “The name as a monument”, “Colour chapters”, “The page is the object” or “The quiet instrument”. Under every dealt blueprint the sheet lists where it disagrees with the house rules. For app screens, library/app.json holds seven styles, five shells and 25 screen patterns for 13 kinds of product.

The agent adopts the sheet. It redraws one slot (--redraw hero, type, palette, photos, scenes, section:<role> or direction) only for a reason it can state: the slot contradicts a brand constraint, needs an asset that does not exist, or cannot hold the real content. Every redraw goes in the report.

The library photographs are atmosphere placeholders served by Lorem Picsum from Unsplash, under the Unsplash licence. They are meant to be replaced by the project's own pictures.

Agents with no photographs used to draw everything in SVG. The skill takes imagery in this order:

1. the project's own;
2. generated, when the agent has an image tool;
3. real pictures of the subject's world from open collections;
4. drawn in code, for what no honest picture exists of;
5. the dealt atmosphere photographs, where a generic picture honestly fits;
6. type and colour alone.

assets.mjs searches Openverse, Wikimedia Commons, the Art Institute of Chicago and The Metropolitan Museum of Art without API keys, and with --video it finds footage on Wikimedia Commons, the Internet Archive and NASA. It searches the inventory, not the category: the street in old postcards, an old map, the material up close, the trade in engravings. The floor is four real pictures per page, usually six to twelve.

• By default it offers only licences that allow commercial use: CC0, public domain, CC BY and CC BY-SA. Non-commercial and no-derivatives licences are left out.
• --get downloads a picture into the project's assets/ folder and records its title, creator, licence and source in assets/credits.json. Nothing is hotlinked.
• --credits prints the credit line for the footer and the list for the report. CC BY and CC BY-SA need the title, the creator, a link to the source and a link to the licence.
• A found picture shows the world around the client. It is never presented as the client's own product, room, dish, person or team.
• Fonts load from Google Fonts and Fontshare. Check each face's licence for your use.

The pictures in the example pages on this site are credited in CREDITS.md.

Since 2.1.3 this repo holds one skill. The others moved to repos of their own and kept their install names.

Install a moved skill from its new repo under the same name, for example: