在 Ottermind 中使用 Linear：從議題清單到明確的下一步

將 Linear 議題帶進對話，一起釐清接下來該做什麼。在 Ottermind 設定好 Linear 技能後，代理可以讀取有權存取的議題與留言、協助準備檢視會議，並根據團隊已記錄的脈絡草擬後續事項。經過核准後，還能透過支援的寫入操作，將成果寫回 Linear。

當追蹤工具裡已經有詳細資料，卻仍需要把線索串起來時，這種做法很實用。哪個議題需要做決定？兩份客戶回報是否在描述同一個故障？下一張工作單還缺哪些資訊，才能交給工程師處理？

以下流程以一個包含邀請連結問題的虛構版本發布為例。議題 ID、來源事實與輸出範例均為示意內容，不代表曾在已連線的工作區中進行實際測試。

連接你要協作的團隊

使用 byungkyu 發布的 Linear API 技能。這款第三方技能透過 Maton 連線，需要完成 Maton 驗證，並具備有效的 Linear OAuth 連線。連線會決定代理可以存取哪個工作區及哪些資源。

依照 Ottermind 技能指南，啟用技能並將它綁定至負責任務的代理。如果你有多個 Linear 連線，請指定要使用的工作區。先請代理讀取一個已知議題，並確認其 ID 與標題。

技能文件涵蓋議題搜尋、查詢、建立、更新與留言。寫入操作需要明確核准，部分操作可能還需要額外的授權範圍。技能設定說明列出了這些要求。

圍繞團隊需要做出的決定準備檢視會議

假設團隊正在準備版本發布，有三個議題提到了邀請連結。其中一個已指派負責人，另一個最近收到要求釐清的留言，第三個則包含一份尚未重現的客戶問題回報。

開啟看板，可以看到議題在哪裡。準備檢視會議，則需要了解哪些事實應該放在一起討論。請代理閱讀說明與相關留言，再整理出簡短議程，附上能追溯依據的連結。

為 [團隊] 的 Linear 工作區中的 [專案] 準備一份版本發布檢視議程。
閱讀進行中的議題，以及理解目前狀態所需的留言。

每個討論項目都要包含議題 ID、標題、狀態、負責人、
已記錄的問題或待釐清事項，以及提供依據的議題連結。
將議程分為待決策事項、缺少的資訊與已確認的阻礙。
依據已記錄的事實，不要只因議題存在已久，就推斷它受到阻礙。
說明你檢視了哪些內容，以及哪些紀錄無法取得。不要編輯議題。

有效的議程應提供足夠細節，讓同事明白每個項目為何需要討論。在這個虛構範例中，可以這樣整理：

在這項請求中，代理的工作是彙整依據、整理問題。缺少重現步驟，是一項具體的資訊缺口；若要宣稱整個版本發布都有風險，則需要更多資訊。

Linear 支援依議題屬性與關聯進行篩選。限定特定專案、團隊或議題集合，能讓檢視更聚焦，也更容易評估涵蓋範圍。

讀取議題集合: Linear 篩選參考文件 · Linear GraphQL 指南

議程完成後，可以要求更精簡的版本：「幫我準備一段五分鐘的會議開場。先談邀請功能需要做的決定，再列出資訊補充請求。」有人需要查看細節時，仍可回頭參考完整的依據表。

比較相似回報，也保留彼此的差異

「邀請連結壞了」可能是在描述不同的故障。有位使用者可能開啟了過期連結，另一位可能登入了錯誤的帳號，還有人可能是在接受有效邀請後才看到錯誤訊息。

建立新議題之前，先搜尋可能相關的既有紀錄，再請代理比較說明、發生條件與預期行為。這樣能將廣泛的關鍵字比對，轉成可供檢視的假設：哪些回報可能適合一起處理。

在 [團隊] 的議題中搜尋邀請連結過期或無法開啟的問題。
閱讀相關議題的說明與留言。

比較回報的行為、重現條件、受影響的情境
與預期結果。每一列都要附上議題 ID 與來源連結。
建議值得當作潛在重複項目來檢視的議題配對，並分別說明理由。
將不確定的比對結果分開保留。不要關閉、合併或修改議題。

以下是可以要求產出的簡短比較範例。這些 ID 與回報都是虛構的：

DEMO-41 與 DEMO-63 可以考慮放在同一場討論中，但這不代表它們具有相同根因。DEMO-58 也提到邀請，不過它的重現條件指向另一個問題。

接著可以追問：「需要哪些證據，才能判斷 DEMO-41 與 DEMO-63 是否應放在同一個議題中處理？」答案可能會指出需要對應的螢幕截圖、完整且精確的錯誤訊息，或重現步驟的比較。這些需求應來自回報本身，而不是憑空編造診斷。

在議題分流時，這項區分很重要。目標是減少重複調查，同時保留工程師日後可能需要的資訊。

將已達成共識的行為整理成可實作的工作單

現在假設檢視會議做出決定：邀請過期時，應說明問題，並引導使用者向工作區管理員索取新的邀請。這項決定不包含變更邀請的有效期限規則。

這些筆記已足以草擬一個範圍明確的議題。繼續在同一段對話中處理，便能保留相關回報與決策原因供後續參考。

根據這些已核准的產品決策，草擬一個 Linear 議題：[筆記]。
使用 [團隊] 與 [專案]，並連結我們剛才檢視過的相關回報。

包含精簡標題、觀察到的行為、預期行為、
範圍內的工作、筆記中明確列出的排除項目，以及驗收標準。
不要自行編造實作方式。除非筆記有指定，
否則不要設定負責人與優先順序。建立前先展示完整草稿。
我核准建立後，請回傳議題 ID 與 URL。

針對這個虛構決定，草稿可以包含：

• 標題： 在邀請過期時說明下一步操作。
• 觀察到的行為： 回報中的過期連結流程結束時，未提供有用的補救操作。
• 預期行為： 說明邀請已過期，並引導使用者向管理員索取新的邀請。
• 不在範圍內： 變更邀請的有效期限規則。
• 驗收檢查： 開啟過期邀請時，顯示已議定的說明與補救指示。

這是一個撰寫範例，並非宣稱 Ottermind 已建立或測試議題。它要呈現的是如何將決定化為可執行的工作，同時避免不知不覺加入額外需求。

請一併檢視預期行為與驗收標準。如果筆記沒有說明補救指示應採按鈕還是純文字，就把這點標記為待釐清事項。現在提出精確的問題，比在工作單中自行補上設計細節更有幫助。

所選技能支援建立議題與新增留言。核准確切的寫入內容後，請代理提供產生的議題連結。如果決定屬於既有議題，就在該議題中準備一則聚焦的留言，不必為同一項工作再新增追蹤位置。

讓下一步持續連回原始回報

一次有效的對話可以留下三份相互關聯的成果：檢視議程、議題比較，以及反映團隊決定的草稿。每份成果都應連回能說明工作緣由的紀錄。

從 Linear 技能 和一組需要關注的議題開始。技能入門介紹說明如何讓代理具備這項能力。若要了解更完整的工作方式，AI 專案管理指南涵蓋檢視與交接，代理工作區指南則說明脈絡如何支援不同步驟之間的工作。