project-flow-ops
分流 GitHub issue 與 PR，決定哪些要進 Linear 並保持兩邊一致
中文翻譯
--- name: project-flow-ops description: 在 GitHub 和 Linear 之間運作執行流程：分流處理 issue 和 pull request、串起進行中的工作，並讓 GitHub 維持對外公開、Linear 維持內部執行層。使用者想控制 backlog、分流 PR，或協調 GitHub 到 Linear 時使用。 metadata: origin: ECC --- # Project Flow Ops 這個 skill 把互不相連的 GitHub issue、PR 和 Linear 任務，變成一條統一的執行流程。 問題是協調，不是寫程式的時候，就用它。 ## 何時使用 - 分流處理累積的 PR 或 issue backlog - 決定什麼該放進 Linear、什麼該只留在 GitHub - 把進行中的 GitHub 工作，連結到內部的執行流程 - 把 PR 分類成 merge、port/rebuild、close 或 park - 稽核 review 留言、CI 失敗或過期的 issue，是否正在卡住執行 ## 運作模式 - **GitHub** 是公開和社群的事實 - **Linear** 是進行中、已排程工作的內部執行事實 - 不是每個 GitHub issue 都需要有 Linear issue - 只有在工作符合下列情況時，才建立或更新 Linear： - 進行中 - 已委派 - 已排程 - 跨職能 - 重要到值得在內部追蹤 ## 核心工作流程 ### 1. 先讀公開的那一面 蒐集： - GitHub issue 或 PR 的狀態 - 作者和 branch 的狀態 - review 留言 - CI 狀態 - 連結的 issue ### 2. 把工作分類 每個項目最後都應該落在這幾種狀態之一： | 狀態 | 意義 | |-------|---------| | Merge | 自成一體、符合政策、已就緒 | | Port/Rebuild | 想法有用，但應該在 ECC 裡手動重新落地 | | Close | 方向錯誤、過期、不安全或重複 | | Park | 可能有用，但現在還沒排程 | ### 3. 決定是否需要 Linear 只有在下列情況才建立或更新 Linear： - 已經積極規劃要執行 - 牽涉到多個 repo 或工作流 - 這項工作需要內部的負責人或排序 - 這個 issue 是更大的 program 流程的一部分 不要機械式地把所有東西都鏡像過去。 ### 4. 讓兩個系統保持一致 當工作進行中： - GitHub 的 issue/PR 應該公開說明目前發生了什麼事 - Linear 應該在內部追蹤負責人、優先順序和執行流程 當工作出貨或被否決： - 把公開的結論貼回 GitHub - 相應地標記 Linear 任務 ## Review 規則 - 絕對不要只憑標題、摘要或信任就 merge，要看完整的 diff - 來源在外部的功能，如果有價值但不是自成一體，就應該在 ECC 裡重建 - CI 是紅的，就要分類並修好，或擋下；不要假裝它可以 merge 了 - 如果真正的阻礙是產品方向，就直接講，不要躲在工具後面 ## 輸出格式 回傳： ```text PUBLIC STATUS - issue / PR state - CI / review state CLASSIFICATION - merge / port-rebuild / close / park - one-paragraph rationale LINEAR ACTION - create / update / no Linear item needed - project / lane if applicable NEXT OPERATOR ACTION - exact next move ``` ## 好的使用情境 - 「稽核目前開著的 PR backlog，告訴我哪些該 merge、哪些該重建」 - 「把 GitHub issue 對應到我們的 ECC 1.x 和 ECC 2.0 program 流程」 - 「檢查這個是否需要 Linear issue，還是應該只留在 GitHub」
英文原文
--- name: project-flow-ops description: Operate execution flow across GitHub and Linear by triaging issues and pull requests, linking active work, and keeping GitHub public-facing while Linear remains the internal execution layer. Use when the user wants backlog control, PR triage, or GitHub-to-Linear coordination. metadata: origin: ECC --- # Project Flow Ops This skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow. Use it when the problem is coordination, not coding. ## When to Use - Triage open PR or issue backlogs - Decide what belongs in Linear vs what should remain GitHub-only - Link active GitHub work to internal execution lanes - Classify PRs into merge, port/rebuild, close, or park - Audit whether review comments, CI failures, or stale issues are blocking execution ## Operating Model - **GitHub** is the public and community truth - **Linear** is the internal execution truth for active scheduled work - Not every GitHub issue needs a Linear issue - Create or update Linear only when the work is: - active - delegated - scheduled - cross-functional - important enough to track internally ## Core Workflow ### 1. Read the public surface first Gather: - GitHub issue or PR state - author and branch status - review comments - CI status - linked issues ### 2. Classify the work Every item should end up in one of these states: | State | Meaning | |-------|---------| | Merge | self-contained, policy-compliant, ready | | Port/Rebuild | useful idea, but should be manually re-landed inside ECC | | Close | wrong direction, stale, unsafe, or duplicated | | Park | potentially useful, but not scheduled now | ### 3. Decide whether Linear is warranted Create or update Linear only if: - execution is actively planned - multiple repos or workstreams are involved - the work needs internal ownership or sequencing - the issue is part of a larger program lane Do not mirror everything mechanically. ### 4. Keep the two systems consistent When work is active: - GitHub issue/PR should say what is happening publicly - Linear should track owner, priority, and execution lane internally When work ships or is rejected: - post the public resolution back to GitHub - mark the Linear task accordingly ## Review Rules - Never merge from title, summary, or trust alone; use the full diff - External-source features should be rebuilt inside ECC when they are valuable but not self-contained - CI red means classify and fix or block; do not pretend it is merge-ready - If the real blocker is product direction, say so instead of hiding behind tooling ## Output Format Return: ```text PUBLIC STATUS - issue / PR state - CI / review state CLASSIFICATION - merge / port-rebuild / close / park - one-paragraph rationale LINEAR ACTION - create / update / no Linear item needed - project / lane if applicable NEXT OPERATOR ACTION - exact next move ``` ## Good Use Cases - "Audit the open PR backlog and tell me what to merge vs rebuild" - "Map GitHub issues into our ECC 1.x and ECC 2.0 program lanes" - "Check whether this needs a Linear issue or should stay GitHub-only"