haslanli/glance

glance 是做什麼的？

有人拿到了一個答案，但他們沒有時間或背景知識去理解。在一覽之後，他們應該知道答案的含義、該怎麼做，以及還有哪些未知之處。tldr 濃縮一個答案給已經懂該領域語言的讀者；glance 則翻譯答案並將其呈現出來。

指令

如果參數是 help（或 --help、-h、?），請精確輸出此區塊並停止：

/glance            以一覽的方式重新講述上一個答案
/glance <what>     重述一個答案、答案的一部分，或多個答案：「你關於建置的回覆」、
                   「只要數字」、「今天做的所有事」、「目前為止的所有決定」，
                   或貼上的文字
/glance on         重述上一個答案，之後以這種方式回答，直到 /glance off
/glance super      類似 on，但每個要點都要精簡成片語
/glance off        恢復正常回覆
/glance status     顯示目前是哪個模式
/glance help       顯示此說明

- 每個數字、名稱、路徑、步驟、警告和未解決的問題都會保留。
- 當答案包含數據時，會以圖像呈現：圖表、方塊、網格、卡片或重新整理過的表格。
- 模式會持續到 /glance off 為止，且僅限於本次對話。
- 在 /btw 內部，模式不會延續：在終端機中，/btw 只回答一次且不保留任何東西；在桌面應用程式中，/btw 會開啟一個側邊聊天，因此在該處設定的模式只會保留在該側邊聊天中。

哪個答案

• 無參數、on 或 super： Claude 在此指令之前給出的最後一個答案。不是整個對話串（除非要求），不是使用者的訊息，也不是原始工具輸出。如果該答案本身已是一覽，則取它前一個答案。如果沒有這樣的答案，用一行說明並停止。
• 任何其他參數都是一個指示。用同事會理解的方式解讀：它可以指向一個答案（「你關於遷移的回覆」、「往上兩則訊息」）、縮小範圍（「只要數字」、「只要決定」；保留範圍內的內容，捨棄範圍外的）、涵蓋多個答案或整個對話（「今天做的所有事」、「目前為止的所有決定」、「итог всего прогресса」）、包含貼上的文字，或結合以上情況。如果符合條件的答案有兩個，取最近的一個並用一行簡短說明。如果沒有任何答案符合，用一行說明並停止；切勿改用其他內容代替。
• 以使用者自己的話提出要求而非使用 /glance（例如「покажи кратко」、「太長了，只要重點」、「我們現在進行到哪裡了？」）：將該請求視為指示，無論是什麼語言，並用該語言回覆。
• 只有答案是來源。 重述所選答案的內容，不從檔案、工具輸出或對話中較早看到的數據中擷取，即使它們更詳細：如果答案將三個服務合併成一行，那麼一覽就保留那一行。
• 如果答案已經夠短夠清楚（幾行，非專家也能理解）：原樣回傳，並用一行說明它已經可以用一覽的方式閱讀。
• 在模式中： 正常完成該輪的工作（工具、檢查、編輯），然後以 glance 的形式給出回覆。

多個答案或整個對話

當指示涵蓋多個答案（目前為止的進度、對話回顧、從某個時間點以來的所有內容、每個決定）時，將它們全部重述為一個一覽：

• 來源： Claude 在該時間範圍內給出的每個答案、使用者沿途陳述的決定，以及 Claude 維護的任務清單（如果有的話）。跳過先前的一覽，因為它們已經重述了範圍內的答案。僅從對話中建構：不要讀取 git 歷史、檔案或追蹤器來填補空白，因為提問者是在問這個對話中發現和完成了什麼。如果範圍內的部分內容已不在對話中（例如，較早的輪次被壓縮成摘要），則使用現有的內容，並用一行說明涵蓋了哪些範圍。
• 一個一覽，不是每個答案一個。 第一句說明整體狀況。將要點圍繞使用者在整個範圍內的疑問進行分組（完成了什麼、決定了什麼、還有哪些未解決、下一步要做什麼），並用此內容本身的語言標示。只有在需要讓事實有意義時，才標明該事實所屬的步驟。
• 合併，並保留所有內容。 多個答案重複的事實只出現一次。每個答案中的每個數字、名稱、路徑、命令、警告和未解決的問題都必須保留。
• 以較晚的答案為準。 當較晚的答案更新或反駁了較早的答案（新的測量值、已上線的修復、被推翻的決定）時，使用較晚的版本，並在旁邊用幾個字說明：「/search 280 ms（cast 修復前為 350 ms）」。一個較晚答案已解決的未解決問題就不再是未解決。
• 視覺呈現仍然最多三個區段。將它們分配給整個範圍內最重要的數據，通常每個有數據的步驟一個區段；其餘的放在一個緊湊的表格或要點中。
• 長度是根據所有來源答案的總長度來衡量。

一覽的結構

按此順序：

1. 答案，用日常用語表達。 一兩句簡短的句子，最多約 25 個字，就像你對朋友說的方式：「你的帳單在十月初因兩項變更而增加超過一倍。」不使用原文的措辭、行話或需要解釋的隱喻。
2. 視覺呈現，當有數據時。 請參閱下方說明。
3. 視覺呈現未顯示內容的要點： 原因、步驟、決定、注意事項、未解決的問題。
   • 圍繞讀者的疑問進行分組（為什麼發生、該怎麼做、還有哪些未知、他們需要做什麼），並用此內容本身的語言為每個組別加上標籤（「十月初的兩項變更」、「修復方案，從最便宜的開始」）。不要重複使用原文的標題，也不要使用固定的標籤集。
   • 每個要點一行，最多兩行，寫成簡短片語而非完整句子（參閱長度）。
   • 當一個術語第一次出現會讓非專家困惑，而他們又需要理解它才能跟上答案時，在括號中添加 2-4 個字的解釋。不要解釋日常用語，且每個一覽最多使用一兩次。
   • 命令、程式碼、路徑和錯誤文字保持原樣，並使用程式碼格式。

除此之外沒有其他內容。句子在視覺呈現之前，要點緊接在視覺呈現之後，中間不能用段落重新陳述答案或描述視覺呈現。

視覺呈現

何時使用。 每當答案包含數據時：需要比較的數字（跨項目、群組或時間）、幾個具有相同細節的項目、已變更的值，或多個項目各自的狀態。在這些情況下，視覺呈現是預設選項，而非額外選項。當答案主要是論述且其中只有少數數字時，則跳過視覺呈現。

使用什麼形式。 任何能讓這些數據一覽無遺的形式。根據答案對其數據的描述來選擇，而不是根據主題或習慣：兩張帳單可能需要兩種不同的視覺呈現。閱讀答案的第一句話，然後思考讀者必須看到什麼才能相信它。

• 總額從 A 變成 B，且答案給出了構成差額的變化 → 步驟加總精確的橋接圖
• 單一項目佔了幾乎所有的變化 → 以該項目作為一個指標卡（其佔比，當這是精確算術時），其餘作為長條圖
• 每一行有幾個時期的數值，且每行的變化方式很重要 → 一個表格，每行附帶一個小型內聯趨勢線
• 項目從一個值移動到另一個值，並且根據答案給出的預算、目標或競爭對手來評估 → before → after 行，在每個值下方以淺色顯示基準
• 按原因分組的問題、失敗、損失或浪費 → 原因列表：每個原因附帶一個長條圖顯示其計數或金額，以及受影響的項目
• 答案主要關注的 1 到 4 個數字 → 標題指標卡（單一數字用指標卡，絕對不要用只有一個長條的圖表）
• 一個值相對於其限制或總體（例如磁碟使用率 92%、預算花費 80%），或多個項目各自相對於其限制 → 儀表圖
• 跨時期或類別的一個數列（最多 12 個）→ 長條圖；更多時間點 → 折線圖
• 跨項目的數額 → 在同一尺度上的長條圖，由大到小排序
• 一個總額分成 2 到 6 個部分，且答案重點在於這個分割 → 一個分割長條圖，上方列出各部分；要比較各部分之間的關係 → 長條圖
• 某些項目上升、某些項目下降的變化，全部使用同一單位 → 從零線開始的分岔長條圖
• before → after，或每個項目有幾個數字（各列單位可能不同）→ 一個表格，每個數字一個對齊的欄位，需要關注的行以藍色標示，並在答案給出目標或限制時，在該行旁畫一條基準線
• 每個項目在每個設定下的狀態（測試矩陣）→ 一個表格，每個設定一欄，每個儲存格一個單詞，只有失敗的儲存格變成紅色
• 具有相同細節的選項 → 比較表，並標記推薦的選項

永遠不要使用圓餅圖或甜甜圈圖，永遠不要使用第二個 Y 軸，一個圖表上永遠不要超過兩條線，並且除了套件的三種顏色（淺藍、藍、紅）之外，不要使用其他顏色。當上述形式無法在一個尺度和一個單位內誠實呈現數據時，請使用表格。

一個視覺呈現包含一到三個區段（例如，先是指標卡，然後是主要圖表，最後是一個列表）。每個值都直接印在視覺呈現上，因此不需要懸停即可查看；套件會命名兩個例外情況（具有多個點的折線圖、內聯趨勢線），並為它們提供懸停讀數。

僅在值得時才互動。 視覺呈現保持靜態，除非數據行數過多（約 15 行或更多），或者答案以兩種或更多種方式分割相同的行（例如按標題和語言、按月份和服務）。在這種情況下，使用套件的互動式表格（排序、篩選晶片、用於長列表的搜尋框）或其檢視切換，並遵守以下規則：

• 第一個檢視，在任何人點擊之前，就已經回答了問題：顯示每一行，按照靜態視覺呈現的方式排序和標記，或顯示答案所關注的分割方式。
• 控制項只能以另一種方式顯示原始數據。不能有假設性分析、預測、趨勢線、平均值或原始數據中沒有的數字，也不能有任何會改變或計算數值的控制項。
• 篩選器使用答案本身的類別和詞語（「僅損失」、「失敗」），絕不使用它未提及的分組方式。
• 篩選後的檢視會顯示顯示了多少行（「顯示 12 行，共 40 行」）。
• 一個表格及其控制項，而不是將多個圖表連接成儀表板。
• 如果沒有可視化工具，就沒有可點擊的內容：給出完整的表格，按照第一個檢視應有的方式排序。

如何製作。

• 使用可視化工具時（在 Claude 桌面應用程式中，包括其 /btw 側邊聊天，以及 visualize 工具）：呼叫 read_me，模組為 mockup 和 data_viz（僅在折線圖時加入 chart）。然後讀取此技能資料夾中的 references/ui-kit.md 並從中建構視覺呈現：完全貼上它的 CSS 區塊，以一行的螢幕閱讀器摘要開始，僅使用其組件，不要重新設定樣式。當工具的指南與套件有差異時，以套件為準。使用 show_widget 繪製。答案句子是你回覆的第一個文字，在呼叫 show_widget 之前寫好（先呼叫 read_me 是可以的），這樣讀者會在視覺呈現之前先看到答案；要點則在視覺呈現之後。
• 當答案解釋帳單或支出變化時，先閱讀 references/bills.md：它說明了這類讀者需要看到什麼，以及上述哪種形式最適合。
• 沒有可視化工具時（終端機，或終端機中的 /btw）：使用 Markdown 表格（如下所述重新整理過），或在要點內使用 before→after 格式。
• 顏色僅承載意義： 淺藍色用於所有普通標記，藍色用於需要查看的內容，紅色用於負面內容。使用直接標籤或簡短圖例來說明。
• 數值和標籤放在視覺呈現上；解釋性的句子保留在回覆中。

重新整理，並確保完全正確。 如果重新整理能讓閱讀速度更快，就不要直接複製原文的表格：按照重要程度排序（通常是變動最大或最重要的項目排在最前面），標記重要的行，或將表格轉換為圖表。無論如何重新整理，都必須保持正確：

• 與原文相同的行、相同的數值、相同的單位。不能刪除、合併或四捨五入。
• 根據數據中的一個鍵進行排序（例如金額變化），然後在排序後檢查順序。
• 僅標記原文支持的內容：「更糟」僅在原文如此說明或數字明顯朝錯誤方向移動時使用；「推薦」僅針對原文推薦的內容。
• 僅在視覺呈現上添加衍生的數字（差異、佔比），且僅當這是基於原文數值的精確算術運算，且視覺呈現需要它時（例如橋接圖的步驟、領先項目的佔比）；將其標示為「計算所得」。否則不要添加任何數字，也絕對不要在要點中添加新的計數或比較。
• 如果原文中的某個數值不明確，請保持原樣。

精確設計。 套件會處理間距、字體大小、對齊、深色模式和窄面板，因此不要覆蓋它。套件無法為你決定的部分：

• 一個起點。 答案主要關注的圖形、項目或行，以藍色（hi，或表格行的 at）突出顯示。其他所有內容保持淺藍色和次要地位。
• 相同的順序，相同的名稱。 項目在指標卡、圖表、行和要點中以相同的順序和相同的名稱出現。
• 相同的單位，數字在前。 在一行或一個數列內，以相同的方式書寫每個值（例如「8 vCPU」、「4 vCPU」），使用與原文相同的單位、分隔符號和小數位數。像「專用」這樣的限定詞放在數值下方的小字中，長度約 20 個字元；較長的說明屬於要點。
• 讓決定性的儲存格突出顯示。 每個選項最多一個標記的缺點，即原文給出的理由，並附上幾個字（例如「與 Postgres 配合緊密」、「超出預算」）。標記推薦的選項。讀者不應該掃描每個儲存格才知道原因。
• 每行一行。 使用原文使用的名稱，保持簡短，這樣每個表格行都能保持一行且高度相同。如果名稱需要解釋，請用白話文在要點中解釋。
• 藍色表示查看這裡；紅色表示負面。 藍色用於答案主要關注的內容，即使是壞消息：導致帳單暴漲的服務是藍色的。紅色僅用於超出答案給定的界線（限制、目標或預算）或失敗的值：其數字、其長條圖超出界線的部分，

...

[因翻譯需求而截斷]