project-flow-ops

Project Flow Ops

這個 skill 將分散的 GitHub issue、PR 和 Linear 任務整合成一個執行流程。

當問題是協調而非編碼時使用。

使用時機

• 分類開放的 PR 或 issue backlog
• 決定哪些該放進 Linear，哪些只留在 GitHub
• 將進行中的 GitHub 工作連結到內部執行軌道
• 將 PR 分類為合併、移植/重建、關閉或暫存
• 審查評論、CI 失敗或停滯的 issue 是否阻礙執行

運作模式

• GitHub 是公開與社群的事實來源
• Linear 是內部執行的事實來源，用於進行中的排程工作
• 並非每個 GitHub issue 都需要對應的 Linear issue
• 僅在以下情況建立或更新 Linear：
  • 工作正在進行中
  • 工作已委派
  • 工作已排程
  • 工作跨功能
  • 工作重要到需要內部追蹤

核心流程

1. 先讀取公開表面

收集：

• GitHub issue 或 PR 狀態
• 作者與分支狀態
• 審查評論
• CI 狀態
• 連結的 issue

2. 分類工作

每個項目應歸入以下狀態之一：

狀態	意義
合併	獨立、符合政策、準備就緒
移植/重建	有用的想法，但應手動重新導入 ECC
關閉	方向錯誤、過時、不安全或重複
暫存	可能有用，但尚未排程

3. 決定是否需要 Linear

僅在以下情況建立或更新 Linear：

• 執行已積極規劃
• 涉及多個儲存庫或工作流
• 工作需要內部擁有權或排序
• issue 是較大計畫軌道的一部分

不要機械性地鏡像所有內容。

4. 保持兩個系統一致

當工作進行中：

• GitHub issue/PR 應說明公開發生的事
• Linear 應在內部追蹤負責人、優先順序和執行軌道

當工作完成或被拒絕：

• 將公開結果回覆到 GitHub
• 相應地標記 Linear 任務

審查規則

• 絕不單憑標題、摘要或信任合併；使用完整 diff
• 當外部來源的功能有價值但不獨立時，應在 ECC 內部重建
• CI 紅燈表示需分類並修正或封鎖；不要假裝它已準備好合併
• 如果真正的阻礙是產品方向，請直接說明，不要躲在工具背後

輸出格式

回傳：

PUBLIC STATUS
- issue / PR 狀態
- CI / 審查狀態

CLASSIFICATION
- merge / port-rebuild / close / park
- 一段理由說明

LINEAR ACTION
- create / update / 不需要 Linear 項目
- 專案 / 軌道（如適用）

NEXT OPERATOR ACTION
- 確切的下一步行動

良好使用案例

• "審查開放的 PR backlog，告訴我哪些該合併、哪些該重建"
• "將 GitHub issues 對應到我們的 ECC 1.x 和 ECC 2.0 計畫軌道"
• "檢查這個是否需要 Linear issue，還是只留在 GitHub 就好"