mental 技能：透過參與者、邊界與通訊解釋系統全貌

Mental

透過參與者、邊界與通訊來解釋系統。

輸出合約：圖表優先

一份完整的 mental 解釋必須在回應中包含一個圖表。 先寫一句簡短的文字來引導讀者，然後立即嵌入以下任一者：

• 一個用 fence 包圍的 mermaid 區塊，使用 sequenceDiagram 與 autonumber（預設）。
• 如果渲染可用且使用者要求 D2，則嵌入一個已渲染的 D2 圖片。

接著以簡潔的散文說明流程及其演化。務必在建構較長的文字說明之前先建構圖表，這樣視覺化內容就不會在結尾被遺漏。 此合約同樣適用於簡短回答，以及針對已明確觸發之心智模型討論的後續說明。單純的澄清問題則不需要圖表。如果使用者明確要求不要圖表，請遵從其要求。

ASCII 箭頭、項目符號列表、表格、一般程式碼區塊、指向圖表的連結、承諾「稍後再畫」、以及未渲染的 D2 原始碼，均無法滿足此合約。 請勿詢問使用者是否想要圖表。如果沒有可用的渲染器，仍然輸出 Mermaid 原始碼；不要因為聊天介面可能無法渲染就將其替換為文字。產出 Mermaid 程式碼區塊不需要任何圖表產生工具。

所需回應格式範例（請根據實際情境調整參與者）：

瀏覽器要求 API 儲存資料；API 擁有資料庫存取權限。

```mermaid
sequenceDiagram
    autonumber
    participant Browser
    participant API
    participant Database
    Browser->>API: 儲存表單資料
    API->>Database: 儲存接受的資料
    Database-->>API: 儲存成功的記錄
    API-->>Browser: 成功回應
```

表單從瀏覽器開始。加入 API 讓它可以遠端儲存；加入資料庫則讓儲存的資料能夠比單次請求存活更久。

明確調用

僅在使用者明確要求時才使用此技能：/mental、$mental，或直接要求使用 mental 技能。一般的解釋請求不會啟動此技能。請將此視為一個「解釋請求」，而非允許實作、安裝、發布或變更所解釋的系統。

使用觸發詞後緊接著的主題，或從對話中推斷主題。只有在無法合理推斷主題時，才能提出一個聚焦的問題。

建構解釋

1. 以對話和可用證據為基礎建立模型。對於既有的程式碼庫，僅檢查建立相關關係所需的進入點或設定。區分觀察到的事實與假設。請勿憑空發明服務、成功的部署或已驗證的行為。
2. 從最簡單的有用系統開始：一個在本機運行的腳本、一個顯示頁面的瀏覽器、或一個回應請求的服務。在介紹基礎設施之前，先解釋已經能運作的部分。
3. 逐步推進到正在討論的系統。在每個有意義的階段，解釋新的需求、為滿足該需求而新增的參與者或連線，以及動作現在如何穿過系統。這些是解釋性的階段，而不是關於歷史時間順序的宣稱。如果使用者詢問實際的專案演進，請使用可用的歷史記錄並指出資訊缺口。
4. 根據情境選擇參與者：人員、處理程序、服務、儲存體、註冊表、佇列或外部提供者。為每個參與者賦予具體的角色。當位置影響理解時，將相關的參與者按機器、處理程序或網路邊界分組。
5. 按順序追蹤一個具體的動作如何穿過這些參與者，包括結果返回給呼叫者。標記跨越每個邊界的內容：原始碼、套件壓縮檔、HTTP 請求、JSON 回應、事件或儲存資料。當設定/分發與執行時期通訊兩者都重要時，請加以區分。
6. 僅在解決混淆時才解釋區別。例如，套件名稱選擇要擷取的內容，指令名稱選擇要執行的內容，而引數成為該指令的輸入。對於瀏覽器/API 範例，應區分程式碼傳遞與後續的 API 請求。

優先使用具有連貫散文的簡短進展，而不是詞彙表或元件目錄。如果使用者只想瞭解當前的互動，就展示該流程，而不要強迫呈現冗長的演化過程。指令與程式碼片段應作為模型的錨點；避免列出所有旗標、實作逐步解說或不相關的替代方案。保留會改變模型的細節，例如快取避免了下載，或非同步確認回覆在工作完成前就已送達。

圖表準確性

使用此技能產出的每個回應都必須包含至少一個 Mermaid 圖表或一個渲染後的 D2 圖片。預設使用 fence 包圍的 mermaid 區塊：它不需要任何渲染工具，且當渲染不可用時，原始碼仍然可讀。

• 偏好編號的循序圖：Mermaid 圖表以 sequenceDiagram 開頭，緊接著 autonumber。讓呼叫、訊息和回覆的順序可見。以可讀的由左至右順序引入參與者。
• 除了請求之外，也為回覆編號，以便讀者能理解完整的互動。在散文中追蹤編號的步驟；保持參考與圖表一致。編號顯示的是圖表中所說明的場景，而非宣稱並發工作總是依一個固定順序執行。當並發、替代路徑或選擇性步驟會改變模型時，使用 par、alt 或 opt。
• 對於演化過程，為有意義的階段使用獨立的小型編號序列；保持參與者名稱穩定，並說明新增了哪個參與者或訊息。
• 僅當「拓撲或結構」是主要問題，且循序圖會使其模糊時，才使用流程圖；或在使用者要求時使用。對於顯示互動的 D2 圖片，偏好使用循序佈局並明確地為訊息編號。
• 使用具體的參與者名稱和有方向的箭頭，並標記動作或資料。避免使用未標記的箭頭和不解釋任何功能的裝飾性方框。
• 讓每個圖表專注於正在解釋的互動。將不同的階段或擁擠的系統拆分為數個小圖表。在分階段圖表中，標記哪些參與者和連線是新增的。
• 保持標籤簡單，並對包含標點符號的流程圖標籤加上引號。在發送前檢查節點參考、箭頭方向、子圖及 fence 語法。
• 套件註冊表負責分發程式碼；不要將其畫成正在執行使用者的 CLI。資料庫負責儲存資料；不要將其畫成主動發起一般應用請求，除非這是系統的實際功能。
• 如果使用者偏好 D2 且渲染器可用，請渲染並檢查結果，然後嵌入圖片。僅有 D2 原始碼無法滿足圖片要求。如果渲染不可用，請使用 Mermaid 並簡短說明這是替代方案。不要為了解釋模型而安裝渲染器。

在圖表之後，伴隨一個簡短的具體動作逐步解說。當模型清晰時就結束；請勿附加實作任務或通用摘要。

發送前檢查

檢查回應本身：它是否包含一個用 fence 包圍的 mermaid 區塊或一個嵌入的渲染 D2 圖片？如果兩者都沒有，則解釋不完整。在發送前加入圖表。對於 Mermaid 循序圖，確認 autonumber 是否存在。檢查其箭頭是否與散文相符，並至少使用具體的參與者和標記的通訊來追蹤一個真實的互動。

範例

當範例有助於校準解釋時，請閱讀 references/examples.md。該檔案包含 npm 分發、前端/後端呼叫、服務間呼叫和非同步作業。請根據實際情境調整方法，而不是將那些參與者照搬進每個解釋中。