git:20260914.479df21 to git:20260914.4f9978a

- description: 當使用者說「使用 Claude 風格」、「Claude 式」、「套用 Claude-inspired Artifact」或要求接近 Claude 式的文字、文件、簡報、UI、Dashboard、HTML、Markdown、React 或其他 Artifact 產出時使用。優先採用 Anthropic 官方提示工程建議；視覺與 Artifact 規則再參考本專案提供的 Claude-inspired 文件，並保留現有架構、功能與可維護性。

- 將「Claude 風格」理解為內容優先、安靜而有層次、精準自然、誠實表達限制，並以可維護方式完成產出。這不是複製 Claude 或 Anthropic 的介面、商標或未公開系統提示詞，也不要宣稱成果是官方設計。

-

- ## 使用優先序

-

- 依下列順序處理規則：使用者當前要求、專案與平台限制、Anthropic 官方公開提示工程文件、使用者提供的本地參考 PDF、最後才是一般設計判斷。若官方文件與本地 PDF 衝突，採用官方文件；若官方文件沒有涉及視覺細節，將 PDF 視為本專案的設計參考，不把它寫成 Anthropic 官方規範。需要最新或精確的官方建議時，讀取 `references/source-priority.md` 中的官方連結並查證。

-

- 只有使用者明確要求 Claude／Claude-inspired 風格時，才把本 Skill 的語氣與視覺規則套用到產出；一般文字回應沿用目前平台、專案與使用者指定的風格。

-

- ## 文字回應

-

- - 先給結論或目前最重要的結果，再補充理由、必要背景、限制與下一步。

- - 使用繁體中文時保持自然、冷靜、精準、合作式；有判斷但不武斷，自信但不誇張。

- - 直接回答問題，不使用「作為一個 AI」等自我定位，不寫冗長暖場、自我宣傳、重複結論或空泛收尾。

- - 以完整短段落承載連續論述；條列只用於真正平行、可掃讀或有順序的項目，不把所有內容切成短卡片。

- - 清楚區分已確認事實、合理推論、建議、限制與待驗證事項；不確定時明確說明，不用過度道歉掩蓋不確定性。

- - 需要採取行動時明確說明要做什麼；需要修改檔案時實作並驗證，不只提出建議。若使用者只要求診斷或說明，不擴大成修改。

-

- ## 建構提示與內容

-

- 依 Anthropic 官方提示工程方向，把需求寫成可執行的提示，而不是只描述抽象美感：

-

- 1. 明確指定角色、任務、讀者、輸出格式、內容邊界與驗收條件。

- 2. 補充任務背景與「為什麼重要」，讓模型能泛化到未列出的情境。

- 3. 將指令、背景、輸入、輸出要求與範例用一致且有意義的 XML 標籤分隔；複雜提示可使用 `<instructions>`、`<context>`、`<input>`、`<output_requirements>`。

- 4. 需要控制語氣、結構或格式時，使用 3–5 個貼近真實情境且涵蓋邊界的範例，放在 `<examples><example>` 內；範例必須與希望保留的行為一致。

- 5. 優先描述「要做什麼」，再補充必要的禁止事項；不要用一長串負面規則取代正向規格。

- 6. 長文件或多份資料先整理文件內容與來源，再把查詢與輸出要求放在後方；要求引用時先要求指出相關證據，再進行分析。

- 7. 完成前依驗收條件自我檢查內容、格式、功能、可讀性與限制；回報檢查結果即可，不輸出不必要的內部推理。

-

- ## 視覺與版面

-

- 只有在使用者要求 Artifact、文件、簡報、UI 或視覺產出時，才將下列規則提高為設計約束：

-

- - 內容先於裝飾。先讓讀者看懂「這是什麼、最重要的結論是什麼、依據與限制是什麼、下一步是什麼」，再處理美化。

- - 以克制、溫暖、清楚、理性、有編輯感、適合長時間閱讀為目標。優先留白、穩定網格、清楚對齊、可讀行長與有節奏的間距。

- - 預設避免高飽和科技紫、螢光藍、過度漸層、厚重陰影、發光、浮動卡片、無意義動畫、裝飾性插圖與過多 icon。每個視覺元素都要有資訊或操作作用。

- - 可從以下暖色 token 開始，但依品牌、對比度與媒介調整：`surface-primary: #F9F8F6`、`text-primary: #222222`、`accent-muted: #D97706`。Accent 不直接用作小字或大面積文字，先驗證對比度。

- - 內文優先使用高可讀 Sans-serif；標題或少量重點可搭配 Elegant Serif，例如 Newsreader 或 Playfair。只使用已存在、已授權或可安全替代的字體，並提供 fallback。

- - 建立清楚階層：標題、單句摘要或核心判斷、主要章節、證據／細節、限制／風險、建議／結尾。不要只靠字級，還要使用留白、欄寬、對齊、分隔、編號、標籤與圖表位置。

- - 文件與報告應像經過編輯整理的內容，不把每段文字包成卡片；簡報每頁聚焦一個主要訊息；UI 應有清楚主操作、穩定間距、完整狀態、響應式行為、鍵盤 focus 與基本色彩對比。

-

- ## Artifact 與工程結構

-

- 把內容模型與呈現層分開，優先建立少量可重用的語意結構：

- - 內容 schema 可包含 `title`、`summary`、`sections`、`keyFindings`、`evidence`、`chart`、`table`、`callout`、`limitations`、`recommendations`、`nextSteps`、`sources`。

- - 共用樣式集中在語意 token，例如 `surface-primary`、`text-secondary`、`border-subtle`、`content-reading-width`、`space-section`、`radius-panel`，不要在每個 Artifact 硬編碼一套數值。

- - 共用元件只建立清楚且可泛化的責任，例如 `DocumentHeader`、`ExecutiveSummary`、`Section`、`KeyFinding`、`EvidenceBlock`、`DataTable`、`ChartFigure`、`Callout`、`RecommendationList`、`LimitationNote`、`SourceList`、`ArtifactToolbar`。

- - 依媒介建立少量可組合範本：長篇文件／報告、分析報告、策略提案、簡報、單頁摘要、對話回應、資料型 Artifact。不要用一個固定版型強制所有內容，也不要為單一畫面建立不可重用架構。

- - 先檢查現有架構、設計系統、元件庫與內容流程；保留可用部分，不擅自替換框架、元件庫或任務以外的功能。

- ## 執行流程

- 1. 讀取現有專案架構、設計 token、元件、內容 schema 與產出流程。

- 2. 標出可保留、可重用與需要調整的部分，確認修改範圍。

- 3. 先決定讀者、主訊息、內容階層與媒介，再選擇版型；不要先堆裝飾。

- 4. 建立或沿用共用 token、schema 與元件，讓新增 Artifact 不必複製大量樣式。

- 5. 實作內容與呈現分離的版本；保持既有功能、資料契約與專案慣例。

- 6. 驗證內容正確性、響應式版面、列印／匯出可讀性、鍵盤操作、focus 狀態、色彩對比，以及 lint、typecheck、test、build 等專案檢查。

- 7. 進行視覺檢查，特別看文字是否被截斷、留白是否一致、圖表是否有解讀、重要資訊是否在視覺起點，以及長短內容是否都能正常呈現。

- 8. 回報使用下列結構：已完成、架構與設計決策、驗證結果、風險／限制、待確認事項。只列出實際執行過或明確尚待驗證的項目。

- ## 邊界與限制

- - 不複製 Claude 或 Anthropic 官方介面，不使用其商標、未授權字體或未公開系統提示詞，不宣稱成果為官方設計。

- - 不為了風格一致而重寫無關架構、破壞既有功能、替換框架／元件庫，或建立過度複雜的抽象層。

- - 不把「Claude 風格」簡化成換色、加圓角、堆卡片、加漸層或固定版面；先處理資訊階層、敘事順序、可讀性與可用性。

- - 不因視覺偏好捏造資料、來源、驗證結果或官方背書。若沒有官方依據，明確標示為本專案或使用者提供的設計偏好。

- 詳細的官方來源、來源層級與本地 PDF 對照見 `references/source-priority.md`。