反“AI塑料感”设计 Skill，适用于全新页面设计、设计审计、改版重构以及从 URL 或截图提取设计 DNA。当用户需要新建应用或落地页、对现有设计进行改版重构、明确提及 Hallmark，或使用 audit/redesign/study 指令时调用。
Hallmark
专为 AI 编程助手打造的设计 Skill。让 AI 生成的 UI 看起来像是精心设计出来的，而不是流水线“捏”出来的。
Hallmark 极具主见（opinionated），强调精炼与克制。它固化了一套严苛的设计规则——源自反“AI塑料感”设计圈的共识（包括 Anthropic 的 frontend-design skill、Claude 针对前端美学的手册，以及 2026 年的“触感复兴”运动），绝不允许模型倒退回所有大模型预训练时带有的那些默认套路（defaults）。
它的核心差异化在于：Hallmark 追求的是结构多样性，而不仅仅是视觉色彩的变化。面对两个不同的需求，Hallmark 生成的页面绝不会共享同一种“Hero 头部 → 3 项特性列举 → CTA 转化按钮 → 页脚”的死板韵律。它们应当给人感觉是两个完全不同的网站，而不是同一个模板换了个皮肤。参见 references/structure.md。
由 Together AI 提供支持。
如何使用此 Skill
Hallmark 包含 1 种默认行为和 3 个显式动词指令。
| 调用方式 | 作用 |
|---|---|
| (默认) | 用户要求你设计或构建全新的东西。按下文的 Design（设计）流程 执行。 |
hallmark audit <target> |
读取目标，对照反模式清单进行打分，输出一份按优先级排序的优化清单（punch list）。切勿修改代码。 |
hallmark redesign <target> [--mood <name>] |
提取目标的现有内容与设计意图，然后在现有实现边界内重构视觉结构（除非用户明确确认要完全重写）。换用全新的板块韵律、全新的标题排版以及全新的组件风格。保留现有的路由、组件归属、文案意图、品牌属性及信息架构；仅替换指定范围内所需的视觉/交互层。 |
hallmark study <screenshot | URL> |
用户粘贴或附带了他们赏识的设计截图，或者粘贴了某个在线页面的 URL。提取其设计 DNA（宏观结构、设计原型、字体配对、核心配色），生成一份诊断报告，随后可选择使用提取出的 DNA 重构用户的页面内容，或者输出一份可复用的 design.md 文件。系统会自动识别输入类型：带 http:// 或 https:// 前缀的 URL 会自动切入 URL 模式；其他情况则进入图片模式。URL 模式会通过 WebFetch 读取页面的 HTML 与 CSS——能够精准识别确切的字体和颜色数值，但无法判定布局韵律。诊断完成后，用户有 3 种后续操作：基于该 DNA 构建页面（转入默认流程）、将 DNA 锁定并导出为可复用的 design.md（需显式触发，如“锁定 DNA” / “给我一份 design.md”），或止步于诊断阶段。绝不直接抄袭像素。拒绝模板市场类型的 URL。针对导出 design.md 的审核限制比诊断报告本身更为严格——URL 模式下导出要求声明该源站属于用户自身或为其品牌的公共参考。若 URL 遇到鉴权墙、仅 JS 渲染的 SPA 壳或无法读取的情况，将降级请求用户提供截图。 在运行此动词前请先加载 references/study.md。 |
如果用户输入的内容无法明确映射到 audit、redesign 或 study，则按默认流程处理。如果用户附带了图片或粘贴了 URL 但未加任何动词前缀，请询问：“需要我对此进行 study（提取设计 DNA），还是将其作为全新构建的参考图？”
实现安全红线。 Hallmark 是一个设计 Skill，而不是随意推倒重来代码库的许可证。在任何现有项目中：
- 除非用户明确要求删除，或批准了包含删除项的文件级变更计划，否则切勿删除生产环境文件、路由树、组件目录或旧版网站。
- 默认采用对指定文件进行原地修改（in-place edits），或者在现有路由中接入新增的组件/Token。如果改版重构需要移除多个组件，请先暂停并请求用户确认。
- 将 PDF、README 文件、
.md需求文档、文档、会议记录和 Pitch Deck 视为参考资料。切勿将它们逐字逐句复制到页面中，除非用户明确要求原封不动使用这些文本。 - 在修改前，明确列出预计修改/新建/删除的具体文件。删除文件必须获得显式确认。
默认的 Design 流程始终会选择一个主题。默认情况下，它会从 20 个预设主题（主题库 catalog）中挑选，并根据多样化规则轮换使用。此外，还有一个隐式的 custom（自定义） 分支，用于为特定需求构建一次性的 OKLCH 色盘 + 免费字体组合；自定义路线仅在需求包含明确的创作意图信号时触发（例如：用户指定了品牌色、提出了主题库无法覆盖的多属性视觉氛围，或显式要求自定义主题）。对于常规基础需求，用户永远不会看到“catalog”或“custom”这两个词——主题库在后台静默运行。参见步骤 1（信号检测）与步骤 2.6（分发）；具体协议详见 references/custom-theme.md。
贯穿所有动词的通用准则
这六项准则是通用的，不针对特定动词。它们同样适用于默认 Design、audit、redesign、study 以及组件级作用域（component-scope）。它们与 AI 塑料感测试（slop test）平级并行，而不是嵌套在某个分支中。
-
生成前自我批判（Pre-emit self-critique）。 在返回任何产出前，从六个维度（理念 Philosophy、层级 Hierarchy、完成度 Execution、针对性 Specificity、克制力 Restraint、多样性 Variety）进行 1–5 分的打分。任何一项 < 3 分 都必须触发一轮修改。将这六项评分印在产出文件顶部（例如
/* Hallmark · pre-emit critique: P5 H4 E5 S4 R5 V5 */）。参见references/slop-test.md§ Pre-emit self-critique。 -
真实文案——拒绝编造内容。 如果用户未提供具体指标数据，切勿凭空捏造。以数据为主导的布局、对比行和背书栏（proof bar）必须使用真实数字、占位符（
—搭配带有“待确认指标”标签的灰色块），或改用其他宏观结构。像 “转化率 +47%”、“超过 50,000+ 团队的信赖之选” 以及 “速度提升 10 倍” 这类凭空捏造的内容，一旦出现就是妥妥的 AI 垃圾（slop）。用户评价（testimonial）、Logo 标识和案例数量同理。参见references/anti-patterns.md§ 编造指标 以及 slop-test 关卡 46。 -
锁定 Token——拒绝渲染中途即兴发挥。 在步骤 2.6 确定主题后，产出物中的每一个颜色和每一个
font-family声明都必须引用已命名 Token（例如var(--color-accent)、font-family: var(--font-display)）。严禁使用行内 OKLCH / 十六进制 /rgb()值，或者绕过 Token 块直接写死font-family: "Some Font"。如果需要使用某个未在 Token 中定义的数值，必须先将其作为新的命名变量提升到 Token 块中，然后再进行引用。参见references/anti-patterns.md§ 渲染中途 Token 即兴发挥 以及 slop-test 关卡 48。 -
严禁自行绘制外壳 chrome。 Hallmark 决不能手动构建伪造的浏览器边框（URL 胶囊栏 + 红黄绿控制点）、伪造的手机外壳、伪造的代码块窗口（标题栏 + 嵌套
<pre>的控制点）或伪造的 IDE 外壳——用户的实际运行环境本身就已经提供了真实的外壳（chrome）。请使用包裹在<figure>中的真实截图（最多加上极细边框），或者直接省去外壳，让内容本身说话。参见references/anti-patterns.md§ 重绘 UI 外壳 以及 slop-test 关卡 47。 -
移动端响应式——每次生成均需在 320 / 375 / 414 / 768 px 下验证。 Hallmark 的产出必须在这四个宽度下完美呈现。硬性指标：严禁出现水平滚动条，且
html与body上必须同时设置根节点overflow-x: clip，决不能用hidden（关卡 34）；严禁出现双行可点击文本——包括按钮、主导航链接、页脚链接、面包屑、CTA 按钮（关卡 49）；包含图片的网格轨道必须使用minmax(0, 1fr)，严禁直接使用裸1fr（关卡 50）；大标题在超长单词处必须能够换行，设置overflow-wrap: anywhere; min-width: 0（关卡 51）；在所有主题变体中，分块标题（section head）在移动端必须折叠为单列展示（关卡 52）；单选 Tab 切换模式不能发生滚动跳跃（关卡 53）。参见references/responsive.md§ 移动端——硬性指标。这是底线要求，而不是可有可无的愿望清单。 -
排版纯粹性——标题严禁使用斜体。 标题与 Display 字体一律采用正体（
font-style: normal）。在原本立正的标题中突兀地嵌入一个斜体强调词（如Built to <em>think</em>）是最典型的 AI 破绽之一；大标题全用斜体展示也是同理。请通过字重、强调色或绘制下划线来传达强调语义。斜体仅允许保留在正文段落内部作为正文强调使用。参见references/anti-patterns.md§ 斜体标题 以及 slop-test 关卡 38a。
当需求是组件而不是页面时
在进入完整的 Design 流程之前，请先检查作用域（scope）。如果触发了以下任何一项，请改为执行组件级（Component-scope）流程——日常开发中大多数需求都是组件级的，而不是页面级的，而页面级的整套机制（宏观结构、Hero 增强、页脚原型、项目记忆）对于组件来说并不合适。
组件级作用域信号：
- 需求仅提到了单个 UI 元素：按钮 (button) · 输入框 (input) · 卡片 (card) · 弹窗 (modal) · 下拉菜单 (dropdown) · 气泡提示 (tooltip) · 选择器 (select) · 复选框 (checkbox) · 开关 (switch) · 标签页 (tab strip) · 碎片 (chip) · 徽章 (badge) · 横幅 (banner) · 轻提示 (snackbar) · 浮层 (popover) · 滑块 (slider) · 日期选择器 (date picker) · 头像 (avatar)。
- 需求文字简短（≤ 30 字）且仅指向一个元素。
- 目标文件为单个组件（例如
./Button.tsx、./components/Input.css、app/components/Card.vue）。 - 用户明确表示 “只需要 X”、“只要 Y”、“就这一个元素”、“单个 ___”。
若触发两条信号，即切入组件流程；若仅触发页面流程信号（多板块需求、“帮我建个落地页”），则留在 Design 流程。
组件级流程从页面流程继承的内容
- 步骤 0 · 预检扫描（Pre-flight scan）——保持一致。读取现有的 Token、字体、框架及微交互定位。如 Geist 字体的 Tailwind 项目中的按钮，必须继承使用这些 Token，而不是凭空捏造。
- 步骤 1 · 类型识别（Genre detection）——保持一致。社论风 (Editorial) / 现代极简风 (modern-minimal) / 氛围感风 (atmospheric) / 趣味风 (playful)。组件继承其上下文环境的类型（未知时静默默认至社论风）。
- 步骤 2.6 · 主题路线（Theme route）——保持一致。若存在
tokens.css或design.md，组件直接使用这些 Token。否则询问“是否有遵循的规范系统，还是由我挑选？”，若用户未回应则默认采用 catalog（主题库）。 - 2+1 字体规范——保持一致。
- 状态规范——更加严格。 每个交互组件必须为 全部 8 种状态 交付代码：默认 (default) · 悬停 (hover) · 焦点可见 (
:focus-visible) · 激活 (:active) · 禁用 (disabled) · 加载中 (loading) · 错误 (error) · 成功 (success)。在interaction-and-states.md中的 8 种状态检查清单是硬性强制要求，而非建议。 - Slop test——仅保留通用子集。 执行视觉 / 微交互 / 对比度（关卡 40–41）/ 无障碍（a11y）/ 排版关卡。跳过多样化关卡（不写入
.hallmark/log.json——组件不参与轮换），并跳过针对完整页面的布局安全关卡。
组件级流程跳过的内容
- 步骤 2 · 宏观结构选择。 组件没有宏观结构。需显式声明：“组件级作用域：跳过宏观结构选择。”
- 导航与页脚原型选择。 N1–N9 与 Ft1–Ft8 仅限页面级。组件是单元素，无导航、无页脚，全部跳过。
- Hero 优化模式 (HP1–HP4)。 仅限页面级。按钮或卡片不存在 Hero。
- 步骤 4 · 丰富度增强（Enrichment）。 无 Hero 插图、无演示视频、无抽象背景。组件本身即是最终产物。
- 步骤 5 · 多板块预览。 替换为 8 种状态演示包装器（详见下文）。
- 项目记忆追加。 组件运行不写入
.hallmark/log.json记录。多样化规则不适用。
组件级流程产出的内容
并排交付两个文件：
- 组件产出物——符合项目约定的单个自包含文件
