手動流程 vs Pipeline
GatherTech 的開發生命週期有兩種模式：手動流程（PM 逐步操作）和 Pipeline 自動化（Broker 驅動）。兩者共用相同的 Linear comment tag 追蹤機制，差異在於觸發方式和銜接邏輯。
模式選擇
何時用手動流程
- 單一 Issue 的 bug fix
- 不屬於任何 Phase 的獨立任務
- 需要 PM 在每一步做判斷的特殊情況
- 專案只有 1~2 個 Issues，Pipeline 有過度設計之感
何時用 Pipeline
- 多 Phase 專案（如 Jope.Core 有 10 Phases）
- 每 Phase 3~5 個 Issues，需自動串接
- 需要 Auto-Advance 跨 Phase 自動推進
- 需要完整的失敗重試和安全機制
手動流程詳解
完整 Skill 鏈
顏色說明：🟠 PM 操作 | 🟢 Dev 操作 | 🔴 Reviewer 操作
各 Skill 說明
/generate-task {issueId}
PM 為指定 Issue 撰寫開發指令。
輸入：Linear Issue ID
輸出：Linear comment ## Dev Instructions
內容：
- Target Agent
- Feature branch 名稱 + base branch
- 需求規格 + Spec Kit 參考
- Task 列表 + Acceptance Criteria
- Branch 建立指令
/pick-task {issueId}
Dev 接收任務並準備開發環境。
輸入：Linear Issue ID 動作：
- 從 Linear 取得 Issue 詳情
- 讀取
## Dev Instructionscomment - 建立 feature branch（從 base branch）
- 顯示任務摘要，開始開發
Resume Mode：如果 Issue 已有 ## Review Fix Instructions，自動進入 fix 模式。
/done [--fix]
Dev 完成開發，產出回報。
輸入：無（自動偵測當前 Issue）
輸出：Linear comment ## Completion Report（或 ## Review Fix Report）
內容：
- Branch 名稱
- Commit 列表
- 建立/修改的檔案清單
- Build + Test 結果
- 實作摘要
/create-pr {issueId}
PM 建立 Pull Request。
輸入：Linear Issue ID 動作：
- 收集 git log, diff stat
- 組裝 PR title + body
- 透過 PM Bot GitHub App 建立 PR
- 發送 Linear comment
## PR Created
Per-Phase PR：如果 repo-config.json 設定 prStrategy: "per-phase"，等所有同 Phase Issues 完成後才建 PR，PR 包含所有 Issues。
/review-fix {issueId}
PM 根據 Review 結果產出修正指令。
輸入：Linear Issue ID（已有 ## Review Result comment）
動作：
- 讀取 Review Report
- 針對每個 High/Critical 問題：
- 研究當前程式碼
- 撰寫 before/after 修正建議
- 發送 Linear comment
## Review Fix Instructions - 將 Issue 狀態改回
In Progress
Linear Comment Tag 追蹤
兩種模式共用相同的 comment tag。PM 的 /next skill 掃描這些 tag 判斷每個 Issue 的生命週期階段。
Tag 生命週期
| 階段 | Tag | 寫入者 | 掃描邏輯 |
|---|---|---|---|
| 1 | ## Dev Instructions | PM（/generate-task 或 Pipeline） | 有此 tag → 可派 Dev 開發 |
| 2 | ## Completion Report | Dev（/done） | 有此 tag + 無 PR Created → PM 應建 PR |
| 3 | ## PR Created | PM（/create-pr） | 有此 tag + 無 Review Result → 等待 Reviewer |
| 4 | ## Review Result | Reviewer | APPROVED → 可 merge；CHANGES → 需 fix |
| 5 | ## Review Fix Instructions | PM（/review-fix） | 有此 tag + 無 Fix Report → 等待 Dev fix |
| 6 | ## Review Fix Report | Dev（/done --fix） | 有此 tag + 無新 Review → 等待 Reviewer re-review |
向下相容
舊版 comment 使用中文 tag（## 開發指令、## 完成回報、## PR 已建立）。/next 同時掃描英文和中文 tag。新 comment 一律使用英文 tag。
手動 vs Pipeline 對照表
| 面向 | 手動流程 | Pipeline 自動化 |
|---|---|---|
| 觸發方式 | PM 手動執行每個 skill | PM 執行 /start-pipeline，後續自動 |
| Issue 銜接 | PM 手動決定下一個 Issue | Broker 自動派發下一個 |
| Phase 銜接 | PM 手動啟動下一 Phase | Auto-Advance 自動推進 |
| 失敗處理 | PM 自行決定是否重試 | 自動重試 3 次，超過暫停 |
| Review Fix | PM 手動 /review-fix → 通知 Dev | Broker 自動回到 PHASE_DEVELOPING |
| 追蹤方式 | Linear comment tag + /next 掃描 | Broker state + Linear comment + activity log |
| 適用場景 | 單一 Issue、bug fix | 多 Phase 專案、3+ Issues |
| PM 介入度 | 每步都需要 PM | 啟動後幾乎不需介入 |
| Agent 數量 | PM + Dev（Reviewer 可選） | PM + Dev + Reviewer（三者都需連線 Broker） |
混合模式
實際操作中，手動和 Pipeline 可以混合使用：
-
Pipeline 中手動介入：Pipeline 進入
HUMAN_NEEDED後，PM 可以手動執行 skill（如/review-fix），然後resume()繼續。 -
Pipeline 外手動補充：Pipeline 完成後，後續的 bug fix 用手動流程處理（不需要重啟 Pipeline）。
-
部分 Phase 用 Pipeline：大專案的核心 Phase 用 Pipeline，收尾的小 Phase 用手動流程。
開發生命週期總覽
無論手動或 Pipeline，每個 Issue 都經歷相同的生命週期：
這個生命週期是 GatherTech 開發流程的核心骨幹。Pipeline 自動化加速了每個步驟之間的銜接，但不改變步驟本身。