clarify

clarify skill 概覽

clarify skill 用來改寫容易讓人困惑的 UI 文案，幫助使用者清楚理解發生了什麼、下一步該怎麼做，以及這件事為什麼重要。它是為 UI/UX design work 打造，特別適合產品中出現模糊標籤、無力的錯誤訊息、難以照做的指示，或是表面上技術正確、但實際上仍讓真實使用者摸不著頭緒的 microcopy。

clarify 最適合處理什麼

當問題的核心不是版面配置或互動流程，而是介面中的文字本身時，就很適合用 clarify：

• 無法明確傳達操作結果的按鈕標籤
• 只是在解釋系統、沒有幫助使用者解決問題的錯誤訊息
• 沒有下一步指引的空狀態
• 預設使用者懂太多的表單輔助說明
• 雖然正確，但在壓力情境下認知負擔過重的操作指示

因此，clarify skill 很適合產品設計師、UX writer、frontend 團隊，以及在上線前要打磨對外文字的創辦人使用。

clarify 真正要做的工作

clarify 的實際任務，是把粗糙或不清楚的介面文案，轉成以下這種更能使用的文字：

• 更容易掃讀
• 更容易採取行動
• 更符合使用者的知識程度
• 更符合當下情境中的情緒狀態

最後一點很重要。原始 skill 會明確要求提供使用者的 technical level 與 mental state in context，這比一般只說「幫我寫清楚一點」的 prompt 實用得多。

clarify 和一般改寫 prompt 有什麼不同

一般 prompt 可能只會產出比較順的句子；clarify 更重視文案「為什麼會失敗」：

• jargon
• ambiguity
• passive voice
• missing context
• hidden assumptions
• tone mismatch
• too much or too little detail

它也依賴更完整的設計脈絡。這個 skill 要求先有 /frontend-design，如果相關脈絡還不存在，則要先跑 /teach-impeccable。這個依賴關係對安裝判斷非常重要：clarify 不是獨立使用的文案潤飾巨集，而是設計給更大一套 UX/design system workflow 內使用的。

如何使用 clarify skill

在正確的 repository 脈絡中安裝 clarify

clarify install 路徑遵循 pbakaus/impeccable repo 的 host skill 系統。如果你使用的是 Skills-compatible environment，請先加入該 repo，再從其中呼叫 clarify skill。這個 skill 的位置是：

/.agents/skills/clarify/SKILL.md

由於目前從 repository 可見的證據只有 SKILL.md，在假設有其他輔助資產之前，請先讀這個檔案。

第一次執行前先讀這個檔案

先從這裡開始：

• SKILL.md

真正的運作邏輯都在這裡：必要的前置準備、評估標準，以及逐步的文案檢視流程。目前沒有看到其他支援 script 或參考檔，因此關鍵價值就在於是否照著 skill 的順序正確使用。

不要跳過必要的依賴項

在使用 clarify 前，skill 明確要求先呼叫：

• /frontend-design

如果還沒有任何 design context，則先呼叫：

• /teach-impeccable

這是新使用者最常遇到的採用門檻。如果跳過這段準備，你可能還是會得到不錯的文字，但 UX 判斷通常會比較弱。這個 skill 預設設計原則與脈絡蒐集已經先建立好了。

clarify 要有什麼輸入才會發揮效果

clarify usage 最低可用的輸入，是目前的文案加上它出現的位置。如果再補上以下資訊，結果通常會更好：

• 目標畫面或流程
• 具體的 UI element 類型
• 受眾的 technical level
• 使用者當下的 mental state
• 讀完後希望他採取的行動
• tone、brand voice、字數限制等約束條件

如果缺少這些資訊，skill 仍然可以改寫文字，但就很難穩定選對直接程度、細節深度與情緒語氣。

clarify for UI/UX Design 最佳 prompt 長什麼樣

一個比較弱的請求會像：

• “Improve this error message: Authentication failed.”

更強的寫法則像：

• “Use clarify for UI/UX Design. Rewrite this login error message for non-technical users on mobile. They are likely frustrated and trying to get back into their account quickly. Current text: ‘Authentication failed.’ We want them to understand the problem and next step without sounding robotic. Keep it under 90 characters if possible.”

這種比較強的輸入，補齊了 skill 做判斷時缺少的資料：受眾、情緒、裝置情境，以及成功標準。

把模糊目標轉成可用的 clarify prompt

如果你的起點只是「讓 app 文案更清楚」，請改寫成下面這個結構：

1. current copy
2. 在產品中的位置
3. 使用者是誰
4. 他們想完成什麼事
5. 他們目前處於什麼情緒狀態
6. 讀完後應該採取什麼下一步
7. 長度或語氣限制

這個結構和 skill checklist 所暗示的實際 clarify guide 非常一致。

clarify usage 的實用工作流程建議

一個可靠的流程通常長這樣：

1. 先用 /frontend-design 蒐集產品與設計脈絡。
2. 確認受眾程度與 mental state。
3. 原樣貼上原始文案。
4. 說明所在畫面與預期的使用者行動。
5. 先要求診斷，再要求改寫選項。
6. 選定一個方向後，再針對語氣、精簡程度或具體性反覆調整。

「先診斷」這一步很重要，因為這個 skill 的設計目的，是找出文案 為什麼 不清楚，而不只是直接換一個說法。

先請 clarify 診斷，再請它改寫

如果你想得到超過一般 LLM 潤稿的價值，建議把輸出拆成兩個階段：

• 找出 clarity 問題
• 提供改寫版本

例如：

• “Use clarify. First identify jargon, ambiguity, missing context, assumptions, and tone issues in this onboarding copy. Then provide 3 rewrite options for first-time users.”

這樣團隊能檢視背後的判斷，而不是只憑感覺選一個「聽起來最順」的版本。

clarify 最擅長的場景

clarify skill 最擅長處理短而關鍵的 UI 文案，例如：

• errors
• labels
• helper text
• confirmations
• warnings
• empty states
• setup instructions

這些地方一旦文字不清楚，很快就會造成阻力；而且只要改寫能貼合情境，通常就能實質提升完成率與使用者信心。

clarify 比較不適合的情況

如果真正的問題是以下情況，請審慎使用：

• 產品流程本身就設計錯了
• 功能缺漏
• information architecture 很差
• 法務或合規文案幾乎不能動
• 長篇 marketing copy

遇到這些情況時，clarify 也許能改善可讀性，但無法解決根本問題。

clarify skill 常見問題

clarify 只有 UX writer 才適合用嗎？

不是。clarify 對設計師、PM、工程師，以及負責介面文字的創辦人都很有幫助，即使你不是受過訓練的 UX writer 也能用。前提是你能提供足夠的使用者與情境資訊。

clarify 對初學者友善嗎？

大致上算友善，但前提是你有注意到它的依賴鏈。原始 skill 要求在改寫前先跑 /frontend-design，必要時還要先跑 /teach-impeccable。如果初學者忽略這一步，可能會誤以為這個 skill 很單薄；但它真正的設計方式其實是「先建立脈絡，再改寫」。

clarify 比一般「rewrite this」prompt 強在哪裡？

最大的優勢是有結構的診斷能力。clarify 會針對造成混淆的具體原因進行檢查，例如 jargon、ambiguity、passive voice、missing context，以及對使用者知識的錯誤假設。這通常會帶來更能落地的介面文案改寫。

什麼時候不該用 clarify？

如果文案只是更深層產品問題的表象，就不應該優先使用 clarify。當使用者困惑的原因是流程壞掉、權限規則不清楚，或 UI 把關鍵資訊藏起來時，光靠更好的文字並不能解決問題。

clarify 適合拿來改錯誤訊息嗎？

適合。這是最明確的使用場景之一。這個 skill 會明確考量使用者的 mental state，這對登入失敗、付款異常、表單驗證錯誤等高壓時刻特別重要。

clarify 可以協助處理 tone 和 brand voice 嗎？

可以，但前提是你有把限制講清楚。如果你想要的是「plain but premium」、「friendly but not playful」或「supportive under stress」，請直接說明。否則這個 skill 主要還是會優先為 clarity 最佳化。

如何提升 clarify skill 的使用效果

給 clarify 的不只是句子，還要給使用者狀態

最有槓桿的改善方式，就是描述使用者當下的處境：

• 第一次使用還是熟練使用者
• 平靜還是焦慮
• 是在隨意瀏覽，還是在嘗試從失敗中恢復
• desktop 還是 mobile
• 注意力高還是低

這些資訊會直接影響最佳文案應該更短、更有溫度、更明確，還是更偏向指令式。

提供周邊 UI，而不是只丟孤立文字

有些標籤或訊息看起來不好，不是它本身有問題，而是少了周邊脈絡。想提升 clarify 的效果，請一併提供：

• 附近的欄位或按鈕
• 頁面標題
• 上一步
• 預期的下一步操作

同一句「不好的」文案，放在某個畫面上可能合理，換個地方就可能造成傷害。

請 clarify 提供多種改寫策略

不要只要一個答案，改成要求不同方向的選項，例如：

• 最短但清楚的版本
• 最有支持感的版本
• 最明確導向行動的版本

這對 clarify for UI/UX Design 特別有用，因為團隊經常需要在精簡、語氣與引導性之間做取捨。

盡早說明字數或版面限制

如果文案必須塞進 button、toast、modal 或 mobile form field，請一開始就講清楚。否則 clarify 很可能會產出理論上更清楚、但實際上放不進介面的文字。

留意常見失敗模式

即使用了 clarify，團隊還是常常會接受這類表面上更好、實際上有問題的改寫：

• 更清楚，但太長
• 更友善，但太模糊
• 更精確，但過度技術化
• 更 polished，但和真實任務脫節

評估輸出時，要對照你希望使用者採取的行動，而不是只看寫作品質。

反覆調整的是診斷，不只是字句

如果第一版結果不理想，不要只要求它再短一點。改問這個 skill 可能誤解了什麼：

• 受眾假設錯誤
• mental state 判斷錯誤
• 缺少產品脈絡
• 過度簡化
• 對下一步說明不足

這樣通常比只做表層修句，更能加快後續輸出的改善。

把 clarify 和整個畫面層級檢查一起用

實務上要提升 clarify skill 的最好方式，是把它當成畫面檢查流程的一部分，而不是單句修補工具。請把相關文案一起檢視：

• page title
• field labels
• helper text
• validation text
• CTA label
• success or failure message

這樣比較能抓出單行改寫看不見的一致性問題。

為 clarify usage 保留一份可重複使用的 prompt 模板

一個簡單好用的模板：

• “Use clarify. Context: [screen/flow]. Audience: [user type]. Mental state: [emotion/urgency]. Current copy: [text]. Goal: [desired action]. Constraints: [tone/length/brand]. First diagnose the clarity issues, then give 3 rewrite options.”

這能讓團隊中的 clarify usage 更一致，也能減少因為脈絡不足而產出過度泛化結果的情況。