taste-skill 由 Leonxlnx 维护，仓库为 Leonxlnx/taste-skill，官网是 tasteskill.dev。仓库现在只有一个 Skill：design-taste-frontend。它不提供一套现成组件，而是让 coding agent 在动手前先定艺术方向、找真实图片，生成后再在真实浏览器里检查自己的页面。README 的说法是让 agent 设计网站和应用界面，而不是拼出一张平均化的落地页。按官方 README 整理，未在本机完整实测。
六步构建流程
README 把一次构建拆成六步：读 brief，列出只有这个客户才有的东西；脚本从 20 个研究过的方向里发三张牌，由 agent 选一个；用一句话把客户自己的材料和这个方向连起来；用开放图库里的真实图片和视频搭建页面；在真实浏览器里按三个宽度检查，发现模板味就判失败；最后看自己的截图，修最严重的三个问题，最多三轮。
README 估算一次构建约 30 到 45 分钟、几十万 token。这个数字来自项目自述，不是独立基准；实际耗时取决于页面复杂度和模型。
真实图片从哪里来
图片不是模型生成的，而是从 Wikimedia Commons、Openverse、Met 等开放馆藏里找，只接受公有领域、CC0、CC BY 和 CC BY-SA 文件，并把署名放在页面上。需要联网找图，但不需要 API key，Skill 本身也不安装任何东西。
使用时的运行条件是 Node 22 以上，以及已安装的 Chrome、Edge 或 Chromium。换成客户自己的产品照片通常更好；开放图库能解决“页面里全是渐变占位块”的问题，但未必能表达真实门店、真实人物或真实产品。
v2.1 的仪表盘分支
落地页之外，v2.1 也处理仪表盘和应用界面。它会从真实产品截图里蒸馏出的应用风格中发一张，按对应数值搭外壳、数据、图表和表格，再用应用规则检查：面板要安静、数字要对齐、颜色花在数据上、手机布局里导航要能收起来。对应命令是 inspect.mjs --app。
页面框架也会被检查：首屏有没有清晰标题、左右边距是否相等、有没有某一节被挤到一边、有没有莫名其妙的空白段。动效标准参考最近 100 个 Awwwards Sites of the Day，README 说这是测量出来的，不是凭感觉写的。
安装与运行
用通用安装器只装这一个 Skill：
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend" |
Claude Code 和 Codex 也各有插件安装方式；从克隆仓库安装时，./install.sh 会把 Skill 软链接进去，git pull 后原地更新。仓库只保留 design-taste-frontend，早期的高端视觉、极简 UI、工业粗野等 Skill 已迁到 taste-skill-classics，图片生成相关 Skill 迁到 imagegen-skills，安装名不变但仓库变了。
一个品牌落地页的场景
一家独立咖啡店只有一段 brief 和几张门店照片。Skill 先找出“二十年烘豆经验、只有二十个座位”这类只属于这家店的材料，再选一个方向，用开放图库补足氛围图，搭出页面后在三个宽度检查，最后根据截图修排版。人仍然要决定品牌语气、菜单、价格和法务文案；图库照片也不能假装成真实门店。
与规则型设计 Skill、v0/Framer 的差别
只给检查清单的设计 Skill 能指出问题，但不会给方向，也不会自己找图。taste-skill 把方向、素材和浏览器自查串成一条流程，适合“从零做一个有风格的页面”。v0、Framer 这类工具从模板或组件出发，产出快、可视化强；taste-skill 的产出仍是代码，检查和迭代在本地浏览器完成，速度慢一些，但更容易接进现有前端工程。
代价与边界
30 到 45 分钟和大量 token 意味着它不适合快速原型。开放图库的图片可能和品牌气质不符，商用前要核对每张图的许可和署名要求。参考 Awwwards 的动效标准有变成追逐潮流的风险，也不等于用户能顺利完成任务。
浏览器检查能发现布局、溢出和明显的模板味，发现不了商业定位是否成立，也不能替代可访问性测试和人工设计评审。README 的自检流程是项目方法，不是独立质量认证。
项目入口
- 仓库：Leonxlnx/taste-skill
- 官网：tasteskill.dev，桌面版：tastecode.dev
- 许可：MIT
- 适合：想让 AI 做出有明确视觉方向、而不是平均模板页的设计师和前端