Linear Issue 匯出 Markdown 指南

Linear 快，而且有主見——正是工程團隊想要的樣子。它同時也是團隊知識大量累積的地方：重現步驟、設計決策、回顧會議、客戶回報。把這些內容以 Markdown 拿出來，AI 工作流、文件生成與長期封存就都打開了。

這篇指南整理了把 Linear 內容匯出的每一種實際做法。

為什麼要把 Linear 匯出成 Markdown？

用 AI 做分流 — 把近期的 issue 丟給 Claude 或 ChatGPT，問「有哪些主題一直重複出現？」
從已關閉的 issue 生出發布說明 — Linear 內建的「Build changelog」很好用但不夠彈性；Markdown 讓你想怎麼組就怎麼組
事後檢討 — 把事故 issue 連同所有上下層關聯，一次拉成單一份 Markdown 文件拿去開檢討會
RAG 知識庫 — 把關閉的 issue 灌進向量資料庫，日後出事時自動浮出相關的舊案
專案盤點 — 把一個專案的 issue 匯成單一檔案，直接給利害關係人看進度
備份 — 知道萬一 Linear 掛掉你也重建得回來，晚上睡得比較安穩

方法一：Minibase Chrome 擴充功能（1～20 個 issue 最快）

Minibase 一鍵就能把任何 Linear 的 issue、專案或文件頁面轉成乾淨的 Markdown。

Minibase 從 Linear 抓下來的東西：

Issue 標題、狀態、優先級、負責人、週期、專案
完整的描述內文，含標題、程式碼區塊、清單與嵌入的附件
標籤與到期日，寫成 frontmatter
依發文順序排列的留言串，每則都帶作者與時間
行內的表情回應（例如 [:tada: × 3]）
關聯的 issue（父／子／blocks／blocked-by），轉成 Markdown 連結
附件（圖片、連結文件），轉成 Markdown 參照

Minibase 會丟掉的東西：

Linear 的側邊欄、命令列、快捷鍵提示
工作區外框與帳號小工具

什麼時候該用它： 為了寫一篇東西而抓幾個 issue、把某次事故的父 issue 連同所有子項一起撈出來做事後檢討、或任何臨時的一次性需求。

方法二：Linear GraphQL API

要大量匯出或寫進整合流程，Linear 的 GraphQL API 才是正規路徑。

典型流程：

從 Linear → Settings → API 建立個人 API key
帶著 Authorization: <api-key> 標頭，把 GraphQL 查詢 POST 到 https://api.linear.app/graphql
查詢 issue、留言、附件與關聯 issue
走過回應內容，輸出 Markdown

一段起手式查詢：

query {
  issues(first: 100, filter: { project: { id: { eq: "PROJECT_ID" } } }) {
    nodes {
      identifier
      title
      description
      state { name }
      assignee { name }
      priority
      labels { nodes { name } }
      comments { nodes { body user { name } createdAt } }
    }
  }
}

優點： 可程式化、支援篩選與分頁，最適合會固定重複的匯出。

缺點： Markdown 序列化得自己寫；專案一大，分頁也得自己處理。

方法三：Linear CLI（@linear/cli）

Linear 提供一個 CLI，把常用的 GraphQL 操作包了起來。臨時查詢很好用，要做完整 Markdown 匯出就沒那麼合適。

範例：

npx @linear/cli issues list --project "Engineering Migration"

輸出是純文字或 JSON。再接一個轉換器（例如一支小的 Node 腳本，或 jq 加上樣板）把它變成 Markdown。

它的強項： 快速的腳本化查詢、以及不需要完整保真度的 CI 工作。

方法四：Linear 內建匯出

Linear → Settings → Workspace → Export 目前匯出的是 issue 的 CSV。拿來做試算表分析很好，但不是 Markdown。CSV 轉 Markdown 這一步，還是得自己寫。

工程團隊的工作流

多數 Linear 使用者的需求，落在三種情境之一：

情境 A：「我想把這個 issue 放進筆記」

在 Linear 打開那個 issue
點 Chrome 工具列上的 Minibase
Markdown 檔案落到下載資料夾 → 拖進 Obsidian／Notion／你的 RAG 系統

情境 B：「用這個週期關掉的 issue 生一份發布說明」

用 GraphQL API：

query {
  issues(filter: { cycle: { id: { eq: "CYCLE_ID" } }, state: { type: { eq: "completed" } } }) {
    nodes { identifier title description labels { nodes { name } } }
  }
}

再接一支 Node 腳本，依樣板吐出 Markdown 更新日誌。開源的起手範例：linear-cli-tools。

情境 C：「把整個專案變成 Markdown 封存，交給利害關係人」

20 個 issue 以內：一個一個用 Minibase 存（很快）。
100 個以上：寫腳本打 GraphQL API。

AI 代理人要的是什麼樣的 Linear 匯出

如果目的是把匯出結果交給 Claude 或 ChatGPT 做彙整：

保留 issue 代號（ENG-1234）— LLM 常常需要回頭引用它
保留狀態的變化過程 — 「Backlog → In Progress → Done，前後三週」比單一個「Done」有資訊量得多
把留言串按時間順序攤平 — 不要依作者分組
關聯 issue 要連標題一起帶上，不能只給 ID — 「blocks ENG-1230（onboarding 流程壞掉）」有用；只寫「blocks ENG-1230」就沒用

Minibase 的擷取本來就全部照這樣做——Linear 是它的一級支援網站，輸出格式就是為了給 LLM 讀而調的。

實務上怎麼選

臨時、1～10 個 issue： Minibase。免費版儲存次數不限，Plus（每月 5.99 美元）另有 AI 範本、歷史紀錄與影片轉錄。
定期產生更新日誌： 寫 GraphQL API 腳本，掛在 CI 上跑。
整個工作區封存： GraphQL API 加一支序列化腳本，跑一次就好。
「上一季我們到底怎麼決定 X 的」： 對那個決策 issue 按下 Minibase，丟進 Claude 說「摘要這串的結論」→ 五秒有答案。

Linear 很快。你的匯出也該一樣快。

Minibase 一鍵把任何網頁變成乾淨的 Markdown，直接存進 AI 能搜尋的本機保管庫。擴充功能免費且儲存次數不限；Minibase Plus（每月 5.99 美元或每年 34.99 美元）另有 AI 範本、歷史紀錄與影片轉錄。minibase.md。