Taste Engine — 风格路由器
一个通用流程，多种独立风格——具备防乱写、有条件公共SEO和可选的风格对齐动画。 Taste Engine 控制何时提问、加载哪个选定的风格包，以及如何强制执行。引擎本身没有固定的美学风格。styles/*.md 中的风格包包含实际的设计指令。
材质保真度（选定风格）——截图级合约
选定的视觉美学必须能够从渲染的界面中识别出来，而不仅仅是在标题或CSS变量名中声明。当选择 glassmorphism 时，加载 styles/glassmorphism.md 并应用其强制性的玻璃材质保真度门控：真实的可见磨砂/有色面板过滤出差异化的背景光、可读的反射/边缘以及可访问的备用方案。扁平的深蓝英雄区加上蓝色CTA不是玻璃拟态。使用 tests/glassmorphism-visual.md 进行验收检查，并以 examples/glassmorphism/frosted-surfaces.css 作为起始配方。不要将此特定于玻璃的检查应用于其他风格；每种美学风格都有其自身的要求。
玻璃拟态特有的渐变异常
当选择玻璃拟态时，有意使用的CSS渐变背景、环境光场和受控的柔和色彩形状被明确允许，因为它们使半透明磨砂和深度可见。不要为了满足通用的防乱写渐变警告而移除这些。阅读 styles/glassmorphism.md（"显式背景渐变异常"）并验证第一个视口显示一个正在过滤其差异化背景的真实面板。此豁免仅适用于选定的材质，且绝不影响可用性、真实性、可访问性或用户约束。
自动调用：零命令合约
- 这是一个任务触发的技能，而非仅限斜杠命令的工作流。已安装且支持自主Agent技能的代理应在作品集、网站、应用、仪表盘、登录页面和UI重新设计请求时发现上述元数据——即使使用者从未提及“taste-engine”。
- 一旦被调用，在编写任何UI代码之前应用自动调用合约。实际平台决定技能是否被调用；此文件无法创建操作系统级钩子或保证在每个主机上合规。
- 隐式风格选择： “为我构建一个作品集网站” → 询问一个简洁的风格问题，然后结束回合。切勿在同一回合中询问用户不相关的细节。
- 显式风格选择： “构建一个skeumorphsm风格的作品集网站” → 将拼写错误规范化为
skeuomorphism，读取styles/skeuomorphism.md并构建。不要运行问题菜单。 - 已有项目： 已批准的项目配置或文档化的品牌/风格对于增量工作优先于通用默认值；不要用菜单打断。
- 没有前端工作： API实现、调试业务逻辑、数据库迁移、基础设施、仅写作任务 → 不要启动风格选择器。
工程伴侣：有条件和框架感知
一旦视觉风格问题被解决（或为已有系统/非视觉工作跳过），应用工程路由器。每个Web UI 都获得通用的Web界面质量门控；React/Next 仅当栈和任务合理时才获得React性能和可选的React组合。React Native/Expo 工作获得原生移动，而非Web SEO。导航动效可在兼容性检查后使用视图过渡，或在确实有用时使用可选的 Anime.js。文档编写任务获得文档编写，无需视觉风格选择器。
这些是本地原始集成，而非导入的Vercel插件。它们总结了从上游研究中学到的工程实践。永远不要假设已安装上游技能，永远不要需要React，永远不要在没有明确部署意图的情况下部署，并且不要让技术指导覆盖用户的审美。核心预检、全屏英雄、SEO、防乱写和风格感知动效保持不变。参见工程路由测试。
全屏英雄——相关时必须
风格选择后，对于任何带有英雄区的新公共作品集、登陆页面或主页，加载全屏英雄合约。默认使用一个可见屏幕的头部+英雄组合：使用移动端安全的 min-height: 100svh（附带 100vh 后备）并减去实际正常流头部高度，或者当头部覆盖其上时使用全高英雄。不要盲目应用 100vh：固定高度可能会裁剪文本和工具栏变化的移动视口。在窄/短屏幕上保持内容和CTA可用；在缩放/大文本时允许自然增长和滚动。遵循所选风格的## 英雄构图（全首屏）指南和共享的防乱写检查。不要为了填满屏幕而发明图像、徽章、虚假统计数据或循环动画。
此规则不会强制将营销英雄区应用于私有仪表盘、表单、应用工作区或未创建/重新设计英雄区的增量编辑。用户明确选择紧凑英雄区或无英雄区时优先。当风格已确立时，无需额外的风格选择问题。
Anime.js v4 动效引擎——可选且风格感知
对于明确的UI微交互请求，或在构建确实能从额外动效中受益的选定风格时，加载动效引擎适配器和所选风格的## 动效指南。动效永远不会成为新的美学选择器，并且永远不需要第二次访谈。像 Tambahkan micro-interaction di dashboard ini 这样的请求保留现有项目风格，无需风格问题即可工作。如果项目没有选定的设计语言且用户正在构建新的UI，则原始的单问题预检仍然强制。
不自动安装依赖。 首先检查现有栈。对于简单过渡，优先使用CSS/原生浏览器能力；仅当它确实能简化协调动效或被明确请求时，才考虑使用Anime.js v4。对于React/Next，使用 createScope() + 生命周期清理；对于偏好减少动效的用户，禁用非必要效果同时保持交互功能。不要强制弹跳、循环或过度的交错。风格映射在 styles/motion-profiles.json 中；React配方在 examples/react/anime-v4-press.jsx 中。非Web/原生应用应改用其平台动效API。
跨风格SEO：自动且有条件
SEO不是一种风格选择。 对于新的或大幅改版的公共网站（作品集、登陆页面、博客、公共商业网站、公共文档或公共产品页面），在视觉风格选择之后加载SEO集成，以及必要时加载SEO实现配方。将技术SEO + 防乱写内容应用于每种选定的风格，无需将“你想要SEO吗？”作为第二个问题来询问。SEO永远不会改变选定的材质美学。
- 显式风格： “构建一个Skeuomorphism作品集” → 读取
styles/skeuomorphism.md+references/seo.md，无需风格问题，然后实现。 - 缺少风格： “构建一个作品集网站” → 询问一个风格问题并停止。回答后，加载风格+SEO并实现。不要为了仅写元数据而绕过预检。
- 仅SEO： “审计我网站的SEO” / “修复规范URL和站点地图” → 立即读取SEO模块，无需视觉风格访谈，也不进行不请自来的重新设计。
- 私有/内部应用： 保留机密性和现有可索引性；不要生成公共站点地图或泄露私有路由。原生移动/仅后端任务不在普通Web SEO范围内。
- 未知域名： 不要编造实时URL、作者身份、结构化数据、评论或页面内容；安全地实现语义/标题并报告待处理内容。
SEO和风格共享 FLOOR / REFLEX / FINISH 门控；隐私、真实内容、可访问性和功能行为优先于美学和搜索偏好。参见SEO验收场景。可选的独立 taste-seo 技能用于仅SEO安装；路由器用户无需单独安装它。
硬性要求：新视觉实现前的预检
对于引入或大幅改版视觉UI的任务，在视觉方向确定之前，不要编写UI代码、生成界面模型或更改设计令牌。
- 检查当前用户请求、现有产品品牌/设计系统和明确批准的项目风格配置。
- 如果风格已明确选择（例如，“野蛮风仪表盘”），不要再次询问。如有用，用一行简短确认并加载该风格包。
- 如果现有项目有明确建立的风格且用户请求增量更改，保留它；不要用新选择打断。重新设计请求可以覆盖已建立的风格。
- 否则，询问一个简洁的风格选择问题并停止。 提供6个对比选项和“更多风格/自定义/发送参考”。不要静默选择一个风格、在等待回复时开始编码或询问多问题访谈。
- 当用户回答时，通过注册表解析风格ID，读取仅选定的包，派生项目特定的令牌/决策，然后执行。用户提供的形容词或引用可能需要解释风格特征而不是强制预设。
- 如果工具运行者无法暂停等待用户输入，报告未解决的选项并不要编造同意。明确指示使用自主最佳默认值可能授权一个临时风格；将其标记为临时且可逆。
强制第一个问题（印尼语示例）
在我开始设计之前，您想要哪种视觉风格？
- Claymorphism — 柔软、触感、微妙深度
- Glassmorphism — 透明、层叠、现代
- Brutalism — 清晰排版、原始网格、高对比度
- Neo-brutalism — 大胆色彩、边框和硬阴影
- Minimalism — 干净、简单、内容聚焦
- Swiss / Editorial — 精确网格、主导排版 或输入其他、自定义，或发送参考。
适应用户的语言。保持为单个问题；描述差异而不声明哪个“最好”。对于长菜单，首先呈现六个外加查看剩余选项的方式。如果用户想要示例，在选择前显示选项。如果用户请求交互式选择器且代理支持，则将相同选项呈现为UI控件。
可用风格包
读取 styles/registry.json 以匹配ID、别名、常见拼写错误和描述。规范化标点符号、连字符和大小写；尊重否定风格提及（如“不要玻璃拟态”）和上下文。如果可用，python3 scripts/style_probe.py --prompt "..." 可以提供确定性的风格提示；语义解释和项目上下文仍然优先。不要按名称调用独立的风格技能：读取选定的本地 styles/<id>.md 文件，这是已安装的路由器的一部分。内置包：
| ID | 方向 | 选定后加载的文件 |
|---|---|---|
claymorphism | 雕刻触感 | 风格包 |
glassmorphism | 半透明层叠 | 风格包 |
brutalism | 原始结构化 | 风格包 |
neo-brutalism | 俏皮大胆 | 风格包 |
minimalism | 克制清晰 | 风格包 |
swiss-editorial | 排版网格 | 风格包 |
bento | 模块化磁贴 | 风格包 |
skeuomorphism | 物理控制隐喻 | 风格包 |
retro-terminal | 控制台美学 | 风格包 |
enterprise | 工作流/数据优先 | 风格包 |
自定义是一等公民： 如果所选美学不在注册表中，收集简短参考或约束，然后使用相同维度创建临时的项目特定风格定义。永远不要将风格误标为不存在的包。不需要外部互联网访问来进行选择。
路由器状态
needs-selection: 新的视觉工作；无已选择/确认的方向。询问一个风格问题然后停止。ready: 风格或现有品牌已明确建立；加载相关内容包并实现。refine: 现有UI中的小改动；保留风格，仅修改必要的令牌/组件。custom: 用户选择混合、提供截图或请求未指定的风格；映射到相同的设计维度，并仅确认重要的歧义。non-visual: 后端、测试、文档、无视觉决策的错误修复；完全跳过设计选择。
详细路由、混合和冲突规则：风格路由器。关于自主发现、风格别名、主机限制和精确示例记录，请参见自动调用。
选择后应用风格
- 提取需求： 产品、受众、设备、框架、现有品牌、明确的好恶、可访问性、性能。
- 仅加载选定包（以及根据需要共享的参考）。不要混合未选定包中的随机规则。
- 风格 ≠ 结构： 从真实用户目标派生产品流程和页面内容，而选定包决定视觉材质。在编码之前...