前後工程
前工程:なし後工程:なし委譲先:なし
成果物
書き込む: ユーザーが指定したHTML表示層読み込む: 対象実装、URL、スクリーンショット
Hallmark
此專案範圍內的副本僅供開發使用。保留現有實作邊界，僅在相關時載入參照規則。
一個專為 AI 編碼助手設計的技能，使其生成的 UI 看起來像「打造」而非「隨機生成」。
Hallmark 是主觀、簡潔且刻意無聊的。它編碼了一組嚴格的規則，這些規則源自反 AI-slop 設計領域的共識（Anthropic 的前端設計技能、Claude Cookbook 關於前端美學的內容，以及 2026 年的「觸覺反叛」運動），並拒絕讓模型回退到每個 LLM 都訓練過的預設值。
其差異化在於：Hallmark 堅持的是結構多元性，而不僅僅是視覺多元性。由 Hallmark 為兩個不同簡報創建的兩個頁面，不應該共用相同的 hero → 3-feature → CTA → footer 節奏。它們應該感覺像是不同的網站，而不僅僅是同一範本的不同顏色調換。請參閱 references/structure.md。
由 Together AI 提供技術支援。
如何使用此技能
Hallmark 有一個預設行為和三種明確的動詞。
| 調用方式 | 功能 |
|---|---|
| (預設) | 使用者要求你設計或建立新內容。請遵循下方的設計流程。 |
hallmark audit <目標> | 讀取目標，根據反模式列表評分，回傳一份排序後的改善清單。請勿編輯。 |
hallmark redesign <目標> [--mood <名稱>] | 擷取目標的內容和意圖，然後在現有實作邊界內重新設計視覺結構，除非使用者明確確認願意進行完整重建。建立新的區段節奏、新的標題位置、新的元件語調。保留現有路由、元件歸屬、文案意圖、品牌和資訊架構；僅替換請求範圍所需的視覺/互動層。 |
| `hallmark study <螢幕截圖 | URL>` |
如果使用者輸入的內容未明確對應到 audit、redesign 或 study，則視為預設行為。如果使用者附加了圖片或貼上 URL 但未加上動詞前綴，請詢問：「我應該 study 此內容（提取 DNA），還是將其視為全新建置的參考？」
實作安全護欄。 Hallmark 是一個設計技能，而不是許可證來摧毀程式碼庫。在任何現有專案中：
- 除非使用者明確要求刪除，或批准了列出刪除項目的檔案層級計劃，否則切勿刪除生產檔案、路由樹、元件目錄或舊網站。
- 預設對指定檔案進行原地編輯，或新增透過現有路由連接的新元件/token。如果重新設計需要移除多個元件，請先停止並請求確認。
- 將 PDF、README 檔案、
.md簡報、文件、逐字稿和簡報文件視為參考資料。除非使用者明確指示要逐字使用該文字，否則不要逐字將其複製到頁面中。 - 在編輯之前，說明你預計要修改/建立/刪除的具體檔案。刪除需要明確確認。
預設的設計流程總是會挑選一個主題。預設情況下，它會從 21 個命名主題中挑選一個——即目錄——並根據多元化規則輪換這些主題。此外，還有一個低調的自訂分支，可以為特定簡報建立一次性 OKLCH 色板 + 免費字型搭配；自訂路徑僅在簡報帶有創意意圖訊號時觸發（使用者命名了品牌顏色、命名了目錄無法承載的多屬性氛圍，或明確要求自訂主題）。對於一般的簡報，使用者永遠看不到「目錄」或「自訂」這兩個詞——目錄會靜默運作。請參閱步驟 1（訊號偵測）和步驟 2.6（分派）；協定位於 references/custom-theme.md。
適用於所有動詞的紀律
以下六項紀律非動詞特定。它們同樣適用於預設設計、audit、redesign、study 和元件範圍。它們與 slop 測試並行，而不是位於其某個分支內部。
-
預先自我批判（Pre-emit self-critique）。 在回傳任何輸出之前，在六個軸向（原則、層級、執行、具體性、節制、多元性）上為其評分 1-5。任何低於 3 的項目都會觸發修訂回合。將六項分數蓋章於成果物的頂部（
/* Hallmark · pre-emit critique: P5 H4 E5 S4 R5 V5 */）。請參閱references/slop-test.md§ 預先自我批判。 -
誠實複製——不捏造內容。 如果使用者未提供某個指標，就不要發明一個。以數據為主導的版面、比較行和證明欄必須使用真實數字、預留位置（
—加上一個帶標籤的灰色區塊「待確認指標」），或採用不同的鉅觀結構。「+47% 轉換率」、「受 50,000+ 團隊信賴」 和*「快 10 倍」* 一旦被發明就是 slop。同樣的規則適用於見證、標誌和案例研究數量。請參閱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 框架——使用者的環境已經提供了真實的瀏覽器框架。使用包含在<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）；區段標題在行動裝置上摺疊為單一欄，適用所有主題變體（關卡 52）；無線電標籤模式不會滾動跳躍（關卡 53）。請參閱references/responsive.md§ 行動裝置——不可協商。這是硬底線，而非願望清單。 -
版式純正性——無斜體標題。 標題和顯示字型始終使用羅馬體（
font-style: normal）。在直立標題中包含一個斜體強調詞（Built to <em>think</em>）是最常見的 AI 跡象之一；在標題上使用全斜體顯示字型也是如此。透過粗細、強調色或繪製的底線來承載強調。斜體僅在正文段落中作為內文強調時保留。請參閱references/anti-patterns.md§ 斜體標題 和 slop-test 關卡 38a。
當簡報是元件而非頁面時
在進入完整設計流程之前，檢查範圍。如果以下任一訊號觸發，則執行元件範圍流程——大多數日常開發請求是元件形狀而非頁面形狀，而頁面層級的機制（鉅觀結構、英雄區域豐富化、頁尾原型、專案記憶體）對它們來說並不適用。
元件範圍訊號：
- 簡報命名了一個單一的 UI 元素：一個按鈕 · 一個輸入框 · 一個卡片 · 一個模態框 · 一個下拉選單 · 一個工具提示 · 一個選擇框 · 一個核取方塊 · 一個切換開關 · 一個標籤列 · 一個晶片 · 一個徽章 · 一個橫幅 · 一個提示條 · 一個彈出框 · 一個滑桿 · 一個日期選擇器 · 一個頭像。
- 簡報很短（≤ 30 字）且僅指一個元素。
- 目標檔案是一個單一元件（例如：
./Button.tsx、./components/Input.css、app/components/Card.vue）。 - 使用者明確表示*「只要 X」、「只需要 Y」、「這一個元素」、「一個 ___」*。
如果觸發兩個訊號，則路由到元件。如果只有頁面流程觸發（多區段簡報，「幫我建立一個登陸頁面」），則停留在設計流程中。
元件範圍從頁面流程保留的內容
- 步驟 0 · 預檢掃描——相同。讀取現有 token、字型、框架、微互動風格。一個在 Geist 主體的 Tailwind 專案中的按鈕必須採用那些 token，而不是發明新的。
- 步驟 1 · 風格類型偵測——相同。編輯型 / 極簡現代型 / 氛圍型 / 趣味型。元件繼承其環境的風格類型（當未知時靜默預設為編輯型）。
- 步驟 2.6 · 主題路徑——相同。如果存在
tokens.css或design.md，則元件使用那些 token。否則，詢問「是否有要遵循的系統，還是我應該選擇一個？」——如果使用者未回應，則預設為目錄。 - 2+1 字型紀律——相同。
- 狀態紀律——更嚴格。 每個互動式元件必須包含所有 8 種狀態的程式碼：預設 · 懸浮 ·
:focus-visible·:active· 禁用 · 載入 · 錯誤 · 成功。在interaction-and-states.md中的 8 狀態清單是強制性的，而非建議性的。 - Slop 測試——僅通用子集。 執行視覺 / 微互動 / 對比度（關卡 40–41）/ 可訪問性 / 版式關卡。跳過多元化關卡（沒有
.hallmark/log.json條目——元件不會輪換）和跳過假設是完整頁面的版面安全關卡。
元件範圍跳過的內容
- 步驟 2 · 選擇鉅觀結構。 元件沒有鉅觀結構。明確說明：「元件範圍：跳過鉅觀結構。」
- 導航和頁尾原型選擇。 N1a–N13 和 Ft1–Ft8 僅限於頁面範圍。元件是一個元素；它沒有導航，沒有頁尾。兩者都跳過。
- 英雄區域潤飾模式（HP1–HP4）。 僅限頁面範圍。一個按鈕或卡片沒有英雄區域。
- 步驟 4 · 豐富化。 沒有英雄區域插圖、沒有示範影片、沒有抽象背景。元件本身就是成品。
- 步驟 5 · 多區段預覽。 由 8 狀態示範包裝器（如下）取代。
- 專案記憶體附加。 元件執行時不會有
.hallmark/log.json條目。多元化規則不適用。
元件範圍的產出
兩個檔案，並列：
-
元件成品——一個遵循專案慣例的獨立檔案：
- React / Vue / Svelte：
Button.tsx/Button.vue/Button.svelte - 原始 Web：
button.css+button.html - Tailwind：一個包含
className鏈的.tsx檔案，如果缺少則加上一個tokens.css - 元件按名稱使用 Hallmark token（
var(--color-accent)），絕不內聯 OKLCH 數值。
- React / Vue / Svelte：
-
一個 8 狀態示範包裝器——
<ComponentName>.preview.html（或.preview.tsx）。一個小型的獨立頁面，以垂直堆疊的方式呈現元件在全部 8 種狀態下的外觀，每種狀態都有標籤。使用者開啟它一次，看到元件正常運作，然後將其刪除。該包裝器不屬於生產程式碼的一部分。格式：┌──── 按鈕 — 8 種狀態 ──────────────────────────┐ │ │ │ 預設 [ 點擊我 ] │ │ 懸浮 [ 點擊我 ] │ ← .is-hover 強制 :hover 樣式 │ 焦點 [ 點擊我 ] │ ← .is-focus 強制 :focus-visible │ 已點擊 [ 點擊我 ] │ ← .is-active 強制 :active │ 禁用 [ 點擊我 ] │ ← disabled 屬性 │ 載入 [ ⌛ 處理中… ] │ ← data-state="loading" │ 錯誤 [ ⚠ 重試 ] │ ← data-state="error" │ 成功 [ ✓ 已儲存 ] │ ← data-state="success" │ │ └────────────────────────────────────────────────┘每個帶標籤的行使用一個類別（例如
.is-hover），元件的 CSS 除了真正的偽類之外也會定位這些類別，以便在示範頁面上同時呈現所有 8 種狀態。範例：.btn:hover, .btn.is-hover { background: var(--color-paper-3); } .btn:focus-visible, .btn.is-focus { outline: 2px solid var(--color-focus); } .btn:active, .btn.is-active { transform: translateY(1px); }
元件輸出的蓋章格式
元件的蓋章方式與頁面不同：
/* Hallmark · component: <類型> · genre: <風格類型> · theme: <主題名稱> */
（原始文件後續的標題、表格、程式碼區塊和連結，若在原文件中提及，其餘部分將依此模式翻譯，直到文件結束。）