專案流程操作 是做什麼的？
此技能將分散的 GitHub 問題、PR 和 Linear 任務串聯成一個統一的執行流程。
當問題在於協調而非編碼時使用。
使用時機
- 分類開放的 PR 或問題待辦事項
- 決定哪些事項應歸入 Linear，哪些應僅留在 GitHub
- 將進行中的 GitHub 工作連結到內部執行軌道
- 將 PR 分類為合併、移植/重建、關閉或暫存
- 審查評論、CI 失敗或過時問題是否阻塞了執行進度
運作模型
- GitHub 是公開與社群的事實來源
- Linear 是內部執行的事實來源，用於進行中的排程工作
- 並非每個 GitHub 問題都需要一個 Linear 問題
- 僅在以下情況建立或更新 Linear：
- 正在進行中
- 已委派
- 已排程
- 跨功能
- 重要到需要內部追蹤
核心工作流程
1. 先讀取公開表面
收集：
- GitHub 問題或 PR 狀態
- 作者與分支狀態
- 審查評論
- CI 狀態
- 已連結的問題
2. 分類工作
每個項目應歸入以下其中一種狀態：
| 狀態 | 意義 |
|---|---|
| 合併 | 獨立、符合政策、已準備好 |
| 移植/重建 | 有用的想法，但應手動重新導入 ECC 內部 |
| 關閉 | 方向錯誤、過時、不安全或重複 |
| 暫存 | 可能有用，但尚未排程 |
3. 判斷是否需要 Linear
僅在以下情況建立或更新 Linear：
- 執行正在積極規劃中
- 涉及多個儲存庫或工作流
- 工作需要內部所有權或排程
- 問題屬於較大專案軌道的一部分
不要機械性地鏡像所有內容。
4. 保持兩個系統一致
當工作正在進行中：
- GitHub 問題/PR 應說明公開面向正在發生的事
- Linear 應在內部追蹤負責人、優先級和執行軌道
當工作完成或遭拒絕時：
- 在 GitHub 上發布公開的解決方案
- 相應地標記 Linear 任務
審查規則
- 切勿僅憑標題、摘要或信任來合併；務必使用完整的差異內容
- 當外部來源的功能有價值但非獨立時，應在 ECC 內部重建
- CI 紅燈表示需分類並修復或封鎖；不要假裝它已準備好合併
- 如果真正的阻礙是產品方向，應直接說明，而非躲在工具背後
輸出格式
回傳：
公開狀態
- 問題 / PR 狀態
- CI / 審查狀態
分類
- 合併 / 移植重建 / 關閉 / 暫存
- 一段理由說明
LINEAR 操作
- 建立 / 更新 / 不需要 Linear 項目
- 若適用，請填寫專案 / 軌道
下一步操作者動作
- 明確的下一步行動
良好使用案例
- 「審查開放的 PR 待辦事項，告訴我哪些該合併、哪些該重建」
- 「將 GitHub 問題對應到我們的 ECC 1.x 和 ECC 2.0 專案軌道」
- 「檢查這是否需要一個 Linear 問題，還是應僅留在 GitHub」