uml 技能可協助你建立 PlantUML 圖表，用於軟體建模，包含類別圖、序列圖、活動圖、狀態機圖、元件圖、使用案例圖、部署圖，以及相關圖表。當你需要可編輯、能自動排版、以文字為先的圖表來支援程式碼、文件與 repo 工作流程時，可使用 uml 進行 Diagramming。它不適合分層架構、圖表，或 BPMN 工作流程。
這個技能的評分為 84/100，代表它是很適合放進目錄、提供給想要現成 UML/PlantUML 工作流程使用者的穩定候選項。這個 repository 提供了足夠的操作細節，能正確觸發技能、理解主要圖表類型，並以比一般提示詞更少的猜測來產生圖表；不過內容仍偏向文件導向，若能補強導入輔助會更完整。
- 觸發條件與範圍明確：frontmatter 說明它會用 PlantUML 語法建立 UML 圖表，並列出最適合的圖表類別與不適用情境。
- 操作指引扎實：SKILL.md 包含重要規則，例如 @startuml/@enduml、必要的 code fences、關鍵字與箭頭語法，以及註解與樣式指引。
- 可重複使用的涵蓋面廣：repo 收錄了多種常見 UML 圖表類型的具體範例，以及相當完整的 stencil/examples library。
- 沒有提供安裝指令、scripts 或支援檔案，因此使用者只能依賴 markdown skill 內容。
- 這個 repository 主要聚焦在圖表語法與範例，而不是互動式驗證或工作流程自動化，對複雜邊界情境的可靠性可能有限。
uml skill 概覽
uml skill 的用途
uml skill 能把粗略的軟體構想轉成使用 PlantUML 語法的 UML 圖。它特別適合需要快速、以文字為主的方式來建模類別、序列、活動、狀態、元件、部署、使用案例與相關關係，而不是手繪圖的人。
最適合誰使用
如果你正在整理程式碼結構、系統行為、服務邊界，或是需要以 markdown 保持版本控管的流程，uml skill 會很適合你。對於開發者、架構師、技術寫作者，以及為 repo 或設計文件產生圖表程式碼的 AI agents，尤其有幫助。
什麼情況下該選它
當你要做 Diagramming，而且輸出必須精準、可編輯、還能自動排版時，就該選 uml。它很適合依賴關係圖、套件階層圖與互動流程圖。不過，若你要的是分層架構圖、資料視覺化，或 BPMN 風格的業務流程，這就不是最合適的 skill。
如何使用 uml skill
安裝並先看對的檔案
使用 npx skills add markdown-viewer/skills --skill uml 安裝 uml skill。接著先打開 SKILL.md，再看和你的目標相符的範例檔。最值得先參考的是 examples/class-diagram.md、examples/sequence-diagram.md、examples/activity-diagram.md 和 examples/deployment-diagram.md。
給模型的是圖的意圖，不只是主題
差的提示會說：「幫我做一張 authentication 的 UML 圖。」更好的 uml 使用提示，會明確說出你要哪一種圖、必須出現哪些實體或角色，以及要呈現哪種關係或流程。例如：「建立一張 login 的 sequence diagram，包含 user、API、auth service 和 database；並加入成功與密碼錯誤兩個分支。」這樣 skill 才有足夠結構產出可用的 PlantUML。
依照圖種對應輸入內容
uml guide 最好用的方式，是一開始就選對圖種。類別圖適合結構與繼承，序列圖適合訊息流，活動圖適合分支流程，狀態機適合生命週期變化，元件圖適合服務依賴，部署圖適合執行時的配置位置。如果你不確定，先看對應的 examples/*.md 檔，再開始下提示，第一版輸出通常會更接近你要的符號與寫法。
有意識地使用語法限制
PlantUML 輸出應該以 @startuml 開頭、以 @enduml 結尾，而且 code fence 應使用 ```plantuml 或 ```puml。當你需要可直接渲染的結果時，記得在提示裡明確要求這些條件。如果你想要風格一致，可以要求加入 skinparam 設定、命名別名、註解，或指定繼承、組合、依賴等關係箭頭。
uml skill 常見問答
uml skill 對初學者友善嗎？
如果你已經知道要畫的業務或系統內容，答案是肯定的。這個 skill 會降低你對語法的猜測成本，但你仍然需要提供圖種、主要元素與彼此關係。初學者最容易得到好結果的方式，是先從一個範例檔開始，再依需求調整，而不是直接要求一張完全抽象的圖。
這和一般提示有什麼不同？
一般提示可能只會產生模糊的圖像描述。uml skill 則更適合產出可重複、可渲染的結果，因為它是建立在 PlantUML 語法與明確的 UML 約定上。對於文件、審查，以及 repo-based 工作流程來說，這種方式更可靠，因為重點是準確性，而不是文筆敘述。
什麼時候不該用 uml？
如果你需要的是儀表板圖表、業務流程符號，或是更適合其他 skill 的大型架構草圖，就不要用 uml skill。當你的目標只是高層次腦力激盪，還沒有固定的實體或關係時，它也不太適合，因為這套語法本來就仰賴具體輸入。
如何提升 uml skill
把真正重要的事實給足
uml 的安裝與使用效果最好時，輸入會很具體：名稱、角色、邊界、關鍵互動，以及圖表應該回答的確切問題。舉例來說，不要只說「顯示我的系統」，而要說「顯示 web client 如何呼叫 API gateway，並由它路由到 auth、orders 與 billing services。」這會讓版面配置、關係選擇與整體可用性都更好。
指定範圍，不要只講內容
常見的失敗模式是圖太滿。你可以明確告訴 uml skill 要排除什麼，來改善輸出品質：例如「排除內部 helper classes」、「只顯示 happy path 加上一個錯誤分支」，或「component diagram 只限 public interfaces」。這樣圖會更易讀，也能避免不必要的節點。
從第一版渲染結果開始迭代
如果第一張圖太密，請它縮小範圍、減少標籤，或改用另一種圖種。如果結構對了但視覺很亂，可以要求整理命名、使用 alias，或調整 skinparam。如果意思沒有表達出來，就補上缺少的關係類型或 sequence 步驟，再重新產生。最好的 uml guide 工作流程通常是兩輪：先顧結構，再處理樣式。