Tooling Field Guide DOC—LIN/01 · linear.app REV 2026.04 · a
— The Linear Field Guide —

Linear/開發團隊的工作座標系

Compiled by 2026·04·29 STATUS · ACTIVE
FIELD GUIDE linear.app — issue tracker for fast-moving teams · keyboard-first · opinionated · GitHub / Slack / Figma / Symphony 整合
5
核心物件
5
Issue 狀態
⌘ K
指揮全場
NAU-1
人人有 ID
figure 00 · thesis One ID,
one task,
one truth.
Linear 是新一代的 issue tracker——它的設計哲學是「有意見的簡潔」： 不像 Jira 給你 100 個欄位讓你猶豫，也不像 GitHub Issues 一切扁平要靠 label 自救。 Linear 強迫你接受幾個它認為對的選擇——Workspace > Team > Project > Cycle > Issue， 每張 issue 自帶 ID、狀態、優先級。 整個 app 是 keyboard-first，⌘K 一條 command palette 可以做掉九成操作。 這份指南拆五個元素，看懂之後你也能用得像長期使用者。
linear.app/nautilusai/team/NAU/active
All issues
Active
Backlog
Todo 4
--- NAU-1 Get familiar with Linear
Apr 29
--- NAU-3 Connect your tools
Apr 29
--- NAU-2 Set up your teams
Apr 29
--- NAU-4 Import your data
Apr 29
01/05
— The Five-Layer Hierarchy
五層階層 · 從公司到 Issue
Linear 把工作組織成五層巢狀結構，每一層只關心自己這層的事。 看懂這張圖，你就懂為什麼 Linear 不需要太多自由度—— 因為結構本身已經替你做好決定。
// hierarchy
L1
Workspace
工作區 · 整個組織
最頂層的容器，等於「整間公司」。範例裡的 nautilusai 就是 workspace。一個帳號通常只屬於一個 workspace；計費、權限、品牌都掛這裡。
ORG · ROOT
L2
Team
團隊 · 工作流獨立單位
團隊有自己的 prefix（如 NAU）、自己的 workflow（state set）、自己的 cycle 設定。產品、平台、設計可以是不同 team；每張 issue 屬於一個 team。
PREFIX · NAU
L3
Project
專案 · 一段時間的目標
把多張相關 issue 集合成一個有起訖時間的 milestone。Project 自己有狀態（Planned / In Progress / Completed）、Lead、文件 / spec 區、進度條。
GOAL · BOUNDED
L4
Cycle
週期 · 兩週的衝刺單位
類似 sprint，但是 Linear 預設把它當作節奏器：每兩週自動翻新 cycle，未完成的 issue 自動 roll over 或被 explicit 留下。cycle 跟 project 是正交的——一張 issue 可以屬於某 cycle 也屬於某 project。
SPRINT · 14d
L5
Issue
議題 · 工作的原子單位
所有真正在動的事——bug、task、feature、spike。每張 issue 有獨一無二的 ID（NAU-1、NAU-2...），這個 ID 是 PR 標題、commit、Slack 連結的共通鍵。
ATOMIC · UNIT
02/05
— Anatomy of an Issue
Issue 解剖 · 一張票上有什麼
每張 issue 雖然只是一行 title，背後攜帶的 metadata 才是讓 Linear、Symphony、CI、Slack、Figma 串起來的關鍵。
// anatomy
NAUTILUSAI · TEAM ● ACTIVE
NAU-3 · Issue

Connect your tools — wire up GitHub / Slack / Figma to the workspace

Status
In Progress
Priority
High
Assignee
@giga
Labels
setup integration
Project
Onboarding 2026Q2
Cycle
Cycle 14 · Apr 22 → May 06
Estimate
3 pts
Due
May 02

◉ 你能在 issue 上掛的東西

  • ID 自動產生、永遠不重用、不改變。NAU-3 是這張票一輩子的 primary key。
  • Title 一句話講完做什麼。Linear 鼓勵動詞開頭，title 直接拿去當 PR 標題也行。
  • Description Markdown 編輯器，支援 / 指令、code block、checklist、嵌入 Figma / Loom。
  • Status Backlog / Todo / In Progress / In Review / Done / Canceled——下章詳述。
  • Priority No / Low / Medium / High / Urgent。會影響排序與通知。
  • Assignee 同時間只能一個人——逼你決定誰負責，避免「大家都」變「沒有人」。
  • Labels 自由 tag，跨團隊報表常用：bug、frontend、customer。
  • Estimate 點數或小時，用於 cycle velocity 計算。
  • Sub-issues 大票切小票，自動回填進度條。
  • Relations Blocks / Blocked by / Duplicates / Related——畫出依賴網。
  • Git linked 把 NAU-3 寫進 branch 名或 PR title，Linear 自動雙向連結 PR / commit / CI 狀態。
03/05
— Workflow States
Issue 狀態流 · 從 Backlog 到 Done
Linear 預設給五個 active state 加上一個 canceled。 每個 team 可以加自定 state，但保留三大類別（Unstarted / Started / Completed）做報表分組。
// state-machine

Backlog

Not started · cold

還沒排入任何 cycle 的池子。可以是粗略的點子或長期想做的事。

UNSTARTED

Todo

Planned · ready

已排入 cycle，但還沒開始動。指派人、排定優先級。

UNSTARTED

In Progress

Active · working

有人正在做。GitHub branch 一開、PR 一建，Linear 通常自動跳到這裡。

STARTED

In Review

Awaiting review

PR 已開，等同事 review 或等 CI。可選的 state——很多 team 用這個分流。

STARTED

Done

Completed · merged

PR 合進主幹、issue 自動關閉。Cycle 結算時計入 completed velocity。

COMPLETED
↓ 例外路徑 ↓

Canceled

Won't do · obsolete

不做了——可能 spec 變了、duplicate、或 priority 換掉。Linear 會把它從 velocity 排除，但保留紀錄供日後翻查。

COMPLETED
04/05
— Project & View
Project vs View · 容器 vs 鏡頭
新手最常搞混的兩個東西。Project 是「issue 的歸屬」， View 是「issue 的查詢」——一個是名詞，一個是動詞。
// container-vs-lens

Project — 一段時間要達成的目標

Static container · bounded goal

Project 把多張 issue 「永久綁在一起」。它有自己的 lead、target date、status、進度條，常常還有一份內建 spec 文件。 範例：Onboarding 2026Q2 把 NAU-1 ~ NAU-4 都收在底下，做完就完。

  • 類比類似 GitHub Milestone，但有文件、有 lead、有 timeline
  • 會跨可以跨 team——一個 project 把產品、設計、平台的 issue 一起裝
  • 有狀態Planned → In Progress → Completed / Canceled / Paused
  • 會結束target date 到期後可以回顧

View — 一個動態查詢

Saved query · dynamic lens

View 不擁有 issue，它只是一個「儲存起來的篩選條件」。 把 filter / sort / group 設好之後存成 view，下次同條件的 issue 自動進來。 範例：「我手上、High 以上、這個 cycle、未完成」這個 view 永遠是當下答案。

  • 類比類似 SQL 的 saved query，或 Notion 的 view
  • 三軸Filter 篩選 · Group by 分組 · Sort 排序
  • 可分享Workspace view 全公司可看，My views 只給自己
  • 不持有同一張 issue 可以同時出現在 N 個 view 裡，互不影響
05/05
— Daily Workflow Surfaces
每天會用到的四個畫面
實際在用 Linear 時，你不會天天去翻 issue list—— 你打開的會是這四個專為「節奏」設計的畫面。
// daily-surfaces
01

Inbox

Notifications, but quiet

所有 mention、assign、subscribe 變動的彙整。比 Slack 安靜，比 email 即時——一天看兩次就夠。

02

Triage

Inbox for issues

客戶回報、bug、外部 webhook 進來的 issue 先進 triage 池，team 每天分類—— assign / archive / 排 cycle。

03

Active Cycle

This week's plan

這 14 天 team 該做完的清單。畫面內建燒下圖、velocity、健康度，cycle 結束自動 carry over 沒做完的票。

04

Roadmap / Initiatives

Quarter on a page

把 N 個 project 排在時間軸上，CEO 一眼看完整季要交什麼。Initiatives 是更上一層的「主題」聚合。

— The Mental Model —

Workspace › Team › Project › Issue

Linear 的設計哲學就一句話：讓你少做選擇。 它已經替你決定了階層、決定了狀態、決定了優先級的尺度、決定了 cycle 的長度。 你能做的就是把工作切成 issue，讓 issue 進到對應的層級裡，然後讓鍵盤替你完成其他。 這也是為什麼 openai/symphony 把 Linear 當作 agent 與人類的共同語言—— 當 agent 跟人類都用同一張 NAU-3 在溝通，就再也沒有「翻譯成本」這回事。

◉ Further Reading 延伸閱讀
→ 01
Companion · OpenAI Symphony

Symphony — 把 Linear ticket 餵給 Coding Agent

Symphony 直接拿 Linear API 當作工作來源——這篇看完，再看 Symphony 你會懂為什麼它選 Linear 而不是 Jira。
→
→ 02
Blueprint · Enterprise

AI Agent 導入流程藍圖

把 Linear 放在企業導入 AI Agent 的整張藍圖裡——它扮演「業務應用層」的人類介面。
→
→ 03
Engineering · Manual

Harness Engineering — 工程手冊

Linear 是 harness 裡「工作來源」這條輸入管線。理解 harness 的角色，才知道 Linear 該做什麼、不該做什麼。
→