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. Keep the same explicit sandbox_id on file, build, preview, and publish calls; run commands through execute, not sandbox.