持續整合設定
決定在每次推送和每次變更請求時執行什麼，然後以專案所屬平台能理解的語法撰寫。此檔案中的決策與平台無關：偵測生態系統、決定需要執行什麼、選擇測試矩陣、決定快取策略。然而，表達這些決策的語法並非平台無關，因此它分別存放在 references/github-actions.md（供 GitHub Actions 使用）和 references/gitlab.md（供 GitLab CI/CD 使用）。在撰寫任何配置之前，請先閱讀對應的參考檔案；不要透過翻譯另一個平台的關鍵字來撰寫某個平台的語法，因為兩者在觸發器、測試矩陣和快取方面的結構截然不同。
範疇
此技能擁有「執行什麼」的決定權：哪些檢查會執行、在哪些觸發條件下、針對哪些版本、使用什麼快取。它與其他兩個技能共享它所撰寫的工作流程與管線檔案，而它們之間的邊界是規則領域，而非檔案描述。
以下的 CI 規則（R-CI-*）歸屬於此。SEC 規則，即相同檔案的安全性態勢（例如固定的 Action SHA、最小權限、依賴更新程式、分支保護和固定的映像檔），歸屬於 oss-harden。REL 規則，即透過受信任發布、來源證明和核准關卡將建置成品發布到註冊表，歸屬於 oss-publish。在使用此技能時，請勿新增 permissions: 區塊、固定 SHA、配置分支保護或撰寫發布作業；請注意專案需要這些，並將工作移交給擁有該規則的技能。
將建置好的靜態網站部署到平台本身的 Pages 託管服務，也屬於在推送時執行的事項，因此它歸屬於此，而不是負責註冊表發布的 oss-publish。沒有規則要求必須這麼做：專案發布網站是因為它有一個網站，因此僅在該儲存庫會建置網站且使用者要求部署時才撰寫。
原則
在新增任何步驟、秘密或配置值之前，務必進行驗證：讀取實際的儲存庫，而不是猜測其結構。在不確定時提問，而不是憑空捏造一個看似合理的答案。
呼叫專案自身的自動化腳本，而不是在管線內部撰寫 shell 邏輯。執行 npm test 而非 jest --coverage --ci 的步驟，能讓管線和貢獻者的筆記型電腦執行相同的指令，這正是 R-CI-02 所檢查的。當不存在此類自動化時，詢問是否要將其新增到專案中，還是回退到使用內聯指令。
呈現政策選項，而不是猜測它們，即使儲存庫已經包含測試、Dockerfile 或管線也是如此。變更請求時執行什麼、什麼觸發發布建置、以及部署如何進行，這些都是使用者做的決定；程式碼只能告訴你什麼是可能的，而不是什麼是被期望的。
流程
步驟 1：偵測平台
查找現有的 .github/workflows/ 目錄或 .gitlab-ci.yml 檔案，檢查 git 遠端是否有 github.com 或 gitlab 主機，或者如果以上訊號都不存在則直接詢問。這決定了哪個參考檔案管轄步驟 6 和 7。如果使用者明確說明了平台，則信任該陳述，而不是儲存庫中發現的任何訊號。
步驟 2：分析儲存庫
從原始碼檔案和套件清單中識別語言和執行環境，並記下專案聲明支援的版本範圍；步驟 4 中的測試矩陣必須涵蓋所有這些版本，包括支援的最舊和最新版本，依據 R-CI-03。
找到所有專案已定義的適用的 lint、測試、型別檢查和建置指令，無論是套件管理員腳本、Makefile、Rakefile 還是像 tox 或 just 這樣的工具，並仔細閱讀它們以了解其參數和副作用。不要憑空發明一個缺失的檢查類別：文件儲存庫可能沒有建置步驟，而一個小腳本可能沒有 linter。如果儲存庫有 CONTRIBUTING 指南，其指令和專案自動化必須一致；在將任一者複製到 CI 之前解決任何衝突。
在修改任何現有的 CI 配置之前先閱讀它，以便知道是要擴展它還是替換它。
識別專案提交的每個鎖定檔案，例如 package-lock.json、Gemfile.lock、poetry.lock 或 Cargo.lock，以及每個安裝指令可以安全重複使用的套件管理員下載快取。不要假設已安裝的依賴項目錄就是快取。
找到 .env.example 並在原始碼中搜尋所需的環境變數，以便在產生配置之前（而不是在執行失敗之後）就識別出需要秘密的步驟。
步驟 3：呈現發現結果並詢問
總結步驟 2 的發現，然後詢問純程式碼無法回答的選擇：在拉取請求或合併請求時應該執行什麼、什麼應該觸發發布建置，以及現有的 CI 應該被擴展還是替換。只詢問與此專案相關的問題；沒有 Dockerfile 的專案就不會詢問關於註冊表的問題。
如果步驟 2 發現了會產生靜態網站的建置步驟，詢問它是否也應該部署，以及部署到哪裡。網站可以僅作為檢查被建置而從不發布，因此將靜態建置視為一個問題，而不是同意部署。
步驟 4：選擇測試矩陣
根據步驟 2 中識別出的支援版本線來建置版本矩陣，而不是基於單一的固定版本。包含專案聲明支援的每個仍在維護的主要或次要版本線。沒有聲明支援範圍的專案將獲得單一版本的管線，而不是憑空產生的矩陣；不要製造清單中未聲明的支援聲明。如果範圍是連續的，並且包含了專案無意支援的版本線，請修正已聲明的範圍，而不是默默地測試一個子集。
步驟 5：決定快取策略
僅快取套件管理員的下載資料，或該工具官方文件說明可安全重複使用的其他目錄。當該平台官方提供的執行階段設定 Action 支援偵測到的套件管理員並且會對鎖定檔案進行哈希處理時，優先使用它。否則，將明確的快取鍵值建立在鎖定檔案以及會改變其內容的每個相容性邊界上，例如作業系統、架構、執行環境和套件管理員。回退鍵值是選用的，且不得跨越這些邊界之一。沒有鎖定檔案或沒有可重複使用的下載快取的專案不會有快取步驟。
步驟 6：撰寫配置
開啟步驟 1 中所選平台的參考檔案，並嚴格遵循其語法。兩個參考檔案都涵蓋了在推送到預設分支時以及在每個變更請求時觸發（R-CI-01）、每個作業都有逾時設定並取消同一分支上被取代的執行（R-CI-05），以及步驟 5 中的快取決策（R-CI-04）。兩者也都包含一個 Pages 部署章節，僅在步驟 3 確定專案需要時才使用。兩個參考檔案都不涵蓋權限、SHA 固定或發布；這些都保留在你於此處撰寫的檔案之外。
步驟 7：在呈現之前進行驗證
如果平台有可用的驗證器，則使用其驗證器確認配置在語法上有效，並確認其調用的每個指令都存在，並能在本地以相同順序成功執行。對於 GitLab，使用 CI Lint 並展開包含的配置。對於 GitHub，在 Actions 編輯器中檢查工作流程，或者在使用者授權該外部更改時將其推送到分支；一般的 YAML 解析器無法驗證 GitHub 表達式或工作流程語義。列出管線所需的任何秘密，以及添加每個秘密的指令，但不要執行該指令。確認測試矩陣符合每個支援的版本線，並且每個作業都有逾時設定，並在安全的情況下參與取消被取代的執行。
步驟 8：呈現結果
顯示產生的檔案、偵測到和決策的簡短摘要、要配置的秘密列表，以及任何留待使用者在儲存庫或專案層級設定的項目，例如分支保護或環境核准者，並指明負責它的技能，而不是在此處嘗試處理。
此技能擁有的規則
R-CI-01：CI 在每次推送到預設分支時以及每次變更請求時執行
R-CI-02：CI 執行與貢獻指南提供給人類的相同 lint、測試和建置指令
R-CI-03：測試矩陣涵蓋專案聲明支援的每個執行環境版本
R-CI-04：依賴項快取的鍵值基於鎖定檔案
R-CI-05：每個作業都有逾時設定，並且同一分支上被取代的執行會被取消