專案流程操作
此技能將分散的 GitHub 議題、拉取請求與 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"