GitHub Copilot 串接 Linear：把 issue 委派給 cloud agent 前的檢查表
GitHub Copilot cloud agent 現在可以從 Linear issue 接手任務：它會在 GitHub Actions 支援的暫時開發環境裡分析 repository、修改程式碼、執行自動化檢查，最後開出 draft pull request，並把進度回傳到 Linear 的 activity timeline。這不表示 Linear issue 一指派就能直接合併；更實際的問題是，如何讓 issue 提供足夠脈絡，又保留 branch、審查與費用的控制點。
本文處理的是「從 Linear 委派到 draft PR」的設定與審核流程。若你要先確認 cloud agent 本身的 repository 範圍與限制，可搭配 大型 repository 用 Copilot CLI 前，以 Git sparse-checkout 縮小工作目錄與授權範圍；若你是在 GitHub Actions 中排程 agent 任務，則應另外看 GitHub Agentic Workflows 改用 GITHUB_TOKEN 後，如何拆開 inference、讀取與受控寫入。
先確認這是 draft PR 工作流，不是自動合併
GitHub 2026 年 7 月 23 日宣布這項 Linear 整合正式上線。從 Linear 指派後，cloud agent 會建立 draft pull request，完成時請求人工 review；整合入口只支援直接建立 PR，不能像 GitHub.com 的 cloud agent 一樣先在同一入口做 repository research、規劃與迭代。
因此 Linear issue 要能獨立交代任務，至少要包含可驗收的結果、相關檔案或模組、不能碰的範圍，以及要跑的檢查。把「修一下登入問題」直接丟給 agent，往往只會把原本需要釐清的產品決策推遲到 PR review。
| issue 內容 | 可交給 agent 的程度 | 人工先補的資訊 |
|---|---|---|
| 明確 bug、重現步驟與預期測試 | 適合先試 | 目標 repository、驗收條件與不應變更的介面 |
| 範圍固定的文件或測試補強 | 適合 | 專案慣例、完成後要跑的命令 |
| 跨服務架構、資料遷移或權限設計 | 不宜直接指派 | 先完成方案與風險審查，再拆成小任務 |
| 緊急 production incident | 不應當成唯一處置 | 先依 incident 流程止血並保留人員判斷 |
安裝前同時核對 GitHub 與 Linear 的管理權限
官方的起點是安裝 GitHub Copilot for Linear app。執行這一步需要 GitHub organization owner 權限與 Linear workspace admin 權限；使用者接著要在 Linear 連結自己的 GitHub 帳號。若組織使用 Copilot Business 或 Enterprise，管理員也必須啟用 cloud agent 的相關 policy，且 repository owner 可以選擇不讓特定 repository 使用 cloud agent。
這些權限是不同層次的責任：安裝 App 不等於所有 repository 都適合委派，也不等於每位使用者都能略過既有 PR 規則。先列出可試行的 repository，再讓少量成員處理低風險 issue，比先對整個 workspace 開放更容易回收問題。
讓 Linear issue 成為可審核的任務合約
整合可以在每張 issue 選模型、自訂 agent、base branch 與 working branch，並可用 Linear comment 提供後續指示。這些選項不會取代 repository 裡的規範；它們是把每一次委派的差異明確留下來。
一張可試跑的 issue 可以採用以下格式：
## 目標在帳號設定頁加入 email 格式驗證，不變更送出 API。
## 範圍- 只修改 `src/pages/settings/` 與既有測試檔- 不調整驗證訊息的翻譯 key
## 驗收- 無效 email 顯示既有錯誤樣式- 有效 email 不阻擋送出- 執行 `pnpm test -- settings` 通過
## 分支base: mainworking: copilot/linear-email-validation如果團隊有既定的建置、測試、命名或安全掃描規則，應把它們放在 repository custom instructions 或 custom agent，而不是每張 issue 靠留言補齊。這樣才能區分「本次任務的變更」與「所有 agent 都必須遵守的底線」。
PR review 要看輸出，也要回看委派邊界
cloud agent 使用自己的 ephemeral development environment，並能執行測試與 linter；這些行為仍不等於變更已通過 review。PR reviewer 至少要把 diff 與原 issue 的範圍逐項對照：是否碰到未授權的模組、測試是否真的覆蓋驗收條件、以及 agent 是否在假設不明時新增了不該有的行為。
對 protected branch，維持既有 required review、status checks 與 merge 條件即可。不要為了讓 agent 更容易完成任務而放寬規則；遇到規則與 cloud agent 不相容時，GitHub 文件也指出 agent 可能被阻擋，應先判斷該規則是否確實需要調整，而不是把所有保護都設為 bypass。
把用量和成效分成兩份紀錄
Copilot cloud agent 會消耗 GitHub Actions minutes 與 AI credits，實際 AI credits 取決於模型和 session 處理的 token。先在小範圍 issue 上記錄每次委派的問題類型、PR 是否被合併、review 後改了什麼、耗用的 minutes 與 credits，才有材料決定哪些任務值得持續委派。
這也和 GitHub Copilot 成效怎麼看？用 repository 指標先分開 PR 活動與品質判斷 的原則一致：PR 數量或合併速度只能描述活動，不能單獨證明程式碼品質。把 Linear issue 到 PR 的流程視為一條可審核的交接線，而不是自動產出的捷徑，才能在跨工具工作流裡保留真正的工程判斷。
參考資料：
GitHub Changelog：Copilot cloud agent for Linear is now generally available
回報錯字、失效連結，或告訴我你想看的延伸主題。