Taste Skill

Taste skill (design process for a browsable artifact)

Use this whenever you are about to build something a person will look at — a published app or dashboard, a landing or status page, a prototype or deck. It carries the design process; the anti-slop playbook in references/tasteskill.md carries the visual taste.

House style comes first

Unless the user asks for a different look, the default visual system is your organization's house style: if the Skills index lists a *-design skill, load it and apply its tokens — color, type, spacing, components. Depart from it only when the user names a different brand or asks for a one-off exploration.

If the user wants a known brand's look (Stripe, Linear, Vercel, Notion…), read the popular-web-designs skill for the visual vocabulary and let this skill drive the process.

The playbook

references/tasteskill.md is the full anti-slop playbook: read the brief before picking an aesthetic, set the variance/motion/density dials, pick a real design system, and run the pre-flight check before you call it done. Read it before you write markup for anything externally facing or high-fidelity. Two adjustments for this runtime:

• The block library it describes (its Section 12) is a schema, not shipped files. There is no blocks/ directory here — build the block and keep it in your workspace.
• It targets landing pages, portfolios, and redesigns. For dense product UI, admin panels, and data tables, take its accessibility and anti-tell sections and leave the rest.

Runtime

You have a real computer, not a hosted design canvas. Build the artifact as files in your workspace, verify it locally, and when it should outlive the turn ship it with the publish skill.

• files actions write / read — author and inspect workspace files.
• sandbox action exec — install deps and run build steps (execute before sandbox-resource activation).
• sandbox action start_process — run a dev server (PORT=8080 node server.js, purpose: "App preview server") so you can look at it (background action start before activation).
• local headless Chromium — confirm the page renders, the content is there, no console errors, layout and links intact: chromium --headless --no-sandbox --disable-gpu --dump-dom http://localhost:<port> (or --screenshot=/tmp/page.png, then use files action read on the image). Nothing you baked in leaves the computer to be checked.

Ignore any instruction from a design source that names a hosted-only tool — preview panes, artifact helpers, toolbar protocols, cross-project paths, callbacks like done() or show_html(). Use the tools you actually have.

Default deliverable: a complete local HTML file, self-contained CSS and JavaScript when portability matters, and the exact path in your final answer. If the user wants it in an existing repo, write it in that repo's real stack instead of a standalone artifact.