clarify
作者 pbakausclarify 可改善讓人看不懂的 UX 文案、錯誤訊息、標籤、導覽流程與操作指引，讓使用者更少猜測就能採取行動。它很適合技術寫作、支援內容，以及需要更清楚介面文字的產品團隊。這個技能會先釐清情境、受眾與使用者狀態，再進行改寫，因此產出的內容會更直接、更具體，也更好用。
這個技能評分 68/100，代表它可供目錄使用者瀏覽，但更適合以有限制、需留意風險的安裝方式來呈現。這個儲存庫提供了真正可觸發的流程，能改善不清楚的 UX 文案，也有足夠的步驟細節，優於一般泛用提示；但它非常依賴另一個技能（$impeccable），而且缺少能讓採用價值更一目了然的支援素材。
- 對不清楚的 UX 文案、錯誤訊息、標籤與操作指引有明確的觸發情境與使用案例。
- 提供具體流程步驟，可用來評估清晰度問題並蒐集受眾與心理狀態脈絡。
- 對 $impeccable 與其 Context Gathering Protocol 有強烈的執行依賴；在可用時能提升操作指引的品質。
- 沒有支援檔案、範例或參考資料，因此使用者必須只依賴 markdown 本身，且可能需要自行推敲部分用法細節。
- 對 $impeccable 的必要依賴會增加設定門檻，也表示這個技能並非完全自成一體。
clarify skill 概覽
clarify skill 的用途
clarify skill 可協助你把讓人困惑的 UX 文案，改寫成使用者真的知道怎麼做的內容。它特別適合處理不清楚的標籤、錯誤訊息、導覽上手流程、空狀態、表單提示，以及看完仍讓人摸不著頭緒的操作說明。若你是為了 Technical Writing 尋找 clarify，這個 skill 的重點是讓文字更直接、更具體，也更容易快速掃讀。
誰適合使用
當你正在撰寫給真實使用者閱讀的產品文案時，就很適合使用這個 clarify skill；尤其當受眾處於壓力中、時間有限，或本身不是很懂技術時，更能發揮效果。它很適合支援內容、介面稽核，以及想在不改動產品本身的前提下減少使用者困惑的產品團隊。
為什麼它不一樣
這個 skill 的價值不只是「把這段重寫一下」。它會先推著你評估情境：受眾的技術程度、使用者當下的心理狀態，以及這段文字應該引導出的動作。正因如此，輸出結果通常比一般泛用提示更實用，因為它把清楚表達視為一個決策問題，而不只是遣詞用字的問題。
如何使用 clarify skill
安裝並找到來源內容
使用 npx skills add pbakaus/impeccable --skill clarify 安裝 clarify skill。接著請先打開 SKILL.md，因為裡面包含了使用流程以及必做的前置準備。由於這個 repository 沒有其他輔助檔案，因此最主要、也最權威的資訊來源就是 skill 本體內容。
提供 clarify skill 正確的輸入
最佳的 clarify 使用方式，是從明確的目標開始，而不是丟一個模糊需求。好的輸入會清楚交代文字類型、受眾與情境：
- 「請把這些結帳錯誤訊息釐清，對象是第一次購物、可能有點焦慮的消費者。」
- 「請重寫這些 admin labels，給使用 SaaS dashboard 的內部支援人員使用。」
- 「請改善這段 setup flow 文案，對象是正在檢查 onboarding instructions 的 technical writers。」
像「把這段寫清楚一點」這種弱輸入，會迫使模型自行補情境，最後通常只會產出很空泛的文案。
遵循以情境優先的 clarify skill 工作流程
clarify skill 預期你在改寫前，先蒐集設計與使用情境。實際操作時，建議提供：
- 需要改善的原文全文。
- 它出現在產品中的哪個位置。
- 誰會看到它，以及他們當下想完成什麼事。
- 如果這是錯誤或失敗情境，使用者當下的情緒狀態。
- 任何限制條件，例如字數上限、品牌語氣或在地化需求。
這些情境資訊，才是讓 clarify skill 成為實用編輯工具、而不只是一次表面潤稿的關鍵。
先看最重要的 clarify skill 內容
如果你想快速掌握 clarify 指南，建議先閱讀 SKILL.md 中與這幾個主題相關的段落：現有文案評估、情境蒐集，以及系統化改善。這些部分能幫你理解這個 skill 如何判斷文字為什麼不清楚，以及應該如何修正。若你只能快速掃過一次，至少先看前置準備與評估邏輯，再開始寫 prompt。
clarify skill 常見問題
clarify 只是一般的改寫 prompt 嗎？
不是。clarify skill 比一般泛用 prompt 更有用，因為它會要求你在改寫前先界定受眾、預期動作與使用者狀態。當你的目標不只是讓文字「看起來更順」，而是要真正幫助理解時，這個差異就很重要。
clarify 適合用在 Technical Writing 嗎？
適合，尤其是當 Technical Writing 與 UI 字串、操作說明、說明文字或面向產品使用者的文件有重疊時更有幫助。它比較不是拿來處理長篇文件，而是更擅長讓一小段面向使用者的文字更容易理解、更容易採取行動。
什麼情況不該使用 clarify？
如果問題根本不是清晰度，就不該使用它。假如真正的問題是產品邏輯有誤、功能缺漏，或流程本身壞掉，再好的文案也補不起來。若你的需求是完整建立品牌 voice，而不是針對 UX 文案做精準優化，它也不是最強的選擇。
不會寫文案，也能把 clarify skill 用好嗎？
可以。只要你能提供它要求的情境資訊，這個 skill 對新手也算友善。比起花很多心力把 prompt 修得很漂亮，帶入範例、限制條件，以及你希望使用者完成的動作，通常更能得到好的 clarify 使用效果。
如何改進 clarify skill 的使用效果
提供更好的原始素材
品質提升最大的一步，通常來自更好的輸入。請提供原文、它所在畫面的上下文，以及一到兩個你想靠近的語氣範例。如果這段文案目前失效的原因很明確，也請直接說清楚：太模糊、太正式、太長、太技術化，或步驟太多。
明確說出使用者的心理狀態
在這個 skill 裡，最有力的訊號之一，就是使用者當下是平靜、困惑、挫折，還是正在從錯誤中恢復。請一開始就告訴模型。例如：「這段會出現在付款失敗之後，使用者可能很焦慮。」這樣通常能得到更有同理心、也更可執行的改寫版本。
要求能解決真正問題的修改
如果現有文案的問題在於沒有清楚指出下一步，就要求更明確的 call to action。若問題在於術語太多，就要求改成 plain language 的替代說法。若問題在於資訊太擠，就要求更短的版本。這樣能讓 clarify skill 聚焦在真正的問題上，而不是產出只是好看、但沒有解決問題的修飾性修改。
帶著限制條件檢查並反覆修正
第一輪完成後，請確認改寫後的文案是否仍符合 UI 空間、受眾需求，以及產品既有術語。接著再加入限制條件細修，例如更短的字數、更正式的語氣，或更高的資訊明確度。反覆調整很重要，因為清晰度往往不是靠「多給幾個版本」提升，而是靠你把 prompt 收斂得更準。