Linear

Linear 技能概覽

Linear 技能能做什麼

Linear 是一個以工作流程為核心的技能，用來在 Linear 中管理 issues、projects、initiatives、labels 和團隊更新。它特別適合想要超越一般提示詞、穩定使用 Linear 的使用者：包括建立與更新工作項目、查詢狀態，以及維持 project ops 的一致性。

什麼情況下適合使用這個技能

如果你需要一份實用的 Linear 操作指南，特別是在專案管理上重視先搜尋再建立、狀態紀律，或可重複的團隊流程，那麼 Linear 技能很適合。對於在既有 Linear workspace 裡工作、希望代理行為更少猜測的情境，它也很有幫助。

這個技能的差異在哪裡

這個技能不只是自然語言助手。它包含工具感知的操作指引、當 MCP 不可用時的替代路徑，以及以 repo 為基礎的腳本，方便處理更複雜的操作。若你想同時兼顧快速動作與更深層自動化，這會是更強的 Linear 安裝選擇。

如何使用 Linear 技能

安裝並確認工具路徑

先用 repo 提供的 skill command 安裝 Linear 技能，接著確認目前可用的是哪個後端。這個技能設計上會優先使用 mcp__linear，但也能在 Bash 中退回使用 linear CLI。若你只想先看 repo 的一個部分，請先讀 SKILL.md，因為它會說明工具可用性，以及會影響實際執行的安全規則。

把模糊目標轉成可用的提示詞

好的 Linear 使用方式，從具體輸入開始：team key、item type、目標 project 或 issue key、期望狀態，以及任何 labels 或 priority。不要只說「把專案整理一下」，而是要提出明確動作，例如：「建立一個給 ENG 的 Linear issue，指派到 Phase 6A，priority 設為 2，加入 backend 和 bug 兩個 label，並附上 acceptance criteria。」這種細節會提升對應準確度，也能減少來回確認。

先讀這些檔案

如果你想要快速建立 Linear 安裝與使用流程，先預覽 SKILL.md、README.md、CLAUDE.md、api.md 和 troubleshooting.md。接著再查看 scripts/create-issue-with-project.ts、scripts/create-project-update.ts 和 scripts/create-initiative-update.ts，確認精確參數與驗證行為。如果你打算做自動化，也請順手檢查 scripts/linear-ops.ts 和 scripts/linear-api.mjs。

實用工作流程建議

建議把這個技能用在先搜尋、後建立的流程：建立前先確認是否已有相同的 project 或 issue，更新前先確認狀態名稱，建立工作時則優先使用包含 markdown 的描述。涉及安全性的動作，請遵循 repo 的 secret handling 模式，不要把 LINEAR_API_KEY 暴露在輸出或上下文中。如果 MCP 不可用，也不要停下來——改走這個技能文件說明的 CLI 路徑。

Linear 技能 FAQ

這比一般提到 Linear 的提示詞更好嗎？

是。一般提示詞可能足夠處理一次性需求，但 Linear 技能加入了可安裝的工作流程規則、後端 fallback 邏輯，以及讓重複性 Linear 使用更穩定的腳本。當你需要在 issue 建立、狀態更新與專案管理之間維持一致行為時，這點尤其重要。

使用 Linear 技能一定需要 MCP 嗎？

不需要。雖然它支援 MCP，但當 MCP tools 不可用時，技能明確支援透過 Bash 使用 CLI 路徑。這讓 Linear 技能在不同環境下更容易移植，也比較不會因為工具存取問題而失敗。

Linear 技能適合新手嗎？

大致上是，只要你能提供 workspace 的基本資訊：team key、issue key、project 名稱，以及你想要的結果。新手通常只有在需求太模糊時才會卡住。只要你給的結構夠清楚，這個技能就能更好地支持你做出正確的 Linear 安裝/使用判斷。

什麼情況下不建議使用？

如果你只需要對 Linear 的高層次說明，或你的任務不涉及實際 workspace 變更、查詢或專案追蹤，就不建議使用。若你希望完全不用自己提供 team、project 或 issue 的背景脈絡，這個技能的適配度也會比較低。

如何改進 Linear 技能

先補齊缺少的 workspace 資訊

最大的品質提升，來自一開始就把確切的 Linear 物件與限制講清楚：team key、project 名稱、issue key、目標狀態、assignee、priority 和 labels。好的輸入像是：「把 ENG-123 更新為 In Review，加入 frontend label，並留一則簡短 comment 說明 blocker。」像「把這個往前推」這種弱輸入，會迫使技能自己猜。

不只說意圖，也要寫出輸出要求

如果你想要更好的 Linear 使用結果，請直接指定你要的產物：issue description、project update、initiative update，或 comment。若你要新增 issue，請附上 acceptance criteria 或簡短 template。若你要 project update，請提供 markdown 大綱，以及你希望反映的狀態訊號，例如 onTrack、atRisk 或 offTrack。

注意常見失敗模式

最常見的失敗模式是語意不清：project 名稱只給一半、缺少 team key，或要求更新狀態卻沒有 state ID 或 state name。另一個常見問題，是還沒先搜尋就要求建立。這個技能在先搜尋、再判斷是否真的需要建立時表現最好。

第一次結果出來後再迭代

如果第一次結果已經接近但還不夠準，不要重講整個需求，而是補上缺少的限制條件。比如加上「沿用既有的 project description 風格」、「符合團隊的 label taxonomy」，或「把更新控制在 120 字以內」。這種迭代方式，比大幅改寫更能改善 Linear 技能的表現，也更接近真實專案管理需求。