團隊迴圈 是做什麼的？
當兩個協作的團隊或代理在同一個儲存庫中工作時，請使用此技能。將「團隊A」和「團隊B」替換為已設定的名稱。所有者是人類，負責優先級、合併、部署、凍結和政策決策的權威。
入門：五分鐘設定
- 將此技能複製到目標儲存庫中，並為活躍的代理工具安裝適配器。
- 將
templates/team-loop.yml複製為.team-loop.yml；設定團隊名稱和gate_command。 - 執行
scripts/setup-labels.sh --repo OWNER/REPO。 - 讓所有者建立一個置頂的協調議題和一個帶有
ready標籤的議題。 - 每個團隊閱讀此檔案，最多領取一個項目，並使用已設定的狀態標題。
角色
- 所有者： 建立或推廣就緒的工作；以所有者自己的話張貼直接「所有者：」決策；授權合併和部署，但在具有範圍和 UTC 結束時間的書面授權內除外。
- 團隊A / 團隊B： 建置、測試、審查、領取、交接並報告。在可能的情況下使用不同的 GitHub 身份。
- 審查者（可選）： 執行全新上下文的審查。對於已設定的風險路徑或類別，需要審查者。
迴圈狀態
backlog -> ready -> in-progress -> blocked 或 needs-owner -> 實作 PR -> ready-for-owner -> 已合併 -> deployed。
backlog不可領取。每週批次處理低嚴重性的 backlog 工作，等待所有者推廣。ready授權實作、測試和開啟 PR。它絕不授權合併或部署。- 關閉議題時，移除過時的狀態標籤，例如
in-progress、ready、blocked和needs-owner。
領取協議
- 在執行任何動作之前，立即重新讀取標籤。不要領取
in-progress、blocked或非ready的工作。 - 執行
scripts/claim.sh --repo OWNER/REPO --issue N --team "Team A" --plan "short plan"。 - 該腳本會新增
in-progress和一個團隊標籤，張貼領取聲明，然後重新檢查狀態。如果競爭失敗，它會退出。 - 每個團隊保持進行中的工作在
wip_limit（或更低）。在領取另一個項目之前，完成、交接或明確封鎖當前項目。 - 對於
team:any，最早的有效領取評論者獲勝；另一個團隊退出。不要透過重複實作來解決平手。
評論與溝通
每個團隊評論的第一行必須以以下格式開頭：
狀態：<state> | 團隊：<configured team> | <short context>
僅張貼包含計畫的領取、審查結果、閘道結果、交接、問題、面向所有者的升級、協議或發布報告。不要張貼開始、排隊、仍在等待、重新武裝或其他儀式性的評論。保持一般評論在五個簡短行內；將證據放在 PR 描述或摺疊的詳細資訊中。
只有所有者才能撰寫「所有者：」決策。團隊必須連結或要求所有者的直接評論，絕不能將其視為權威轉達。
標籤與路由
使用 reference/labels.md 中的標籤。除非設定另有規定，否則未分配的 ready 議題預設歸團隊A。team:any 允許任一團隊領取。空閒時，按以下順序幫助另一個團隊：請求的審查、列車準備或重基、然後是每週 backlog 批次。未經所有者請求，不要進行無限制的錯誤掃蕩。
審查、列車、閘道、憑證
-
每個 PR 執行輕量、聚焦的檢查，並根據其風險接受所需的審查層級。
-
審查者將完整的 PR 標記為
ready-for-owner。 -
列車執行者收集該時刻可用的已審查 PR。它執行：
scripts/train.sh --repo OWNER/REPO --name train-YYYYMMDD-N PR_NUMBER... -
train.sh為每個包含的 PR 添加train-running，記錄基底和頭部，執行衝突檢查，建構臨時合併結果，並調用gate.sh一次。 -
gate.sh將憑證綁定到git rev-parse HEAD^{tree}。僅當使用--force時，匹配的現有憑證才能作為成功證據。 -
如果基底或 PR 頭部發生變更，或衝突檢查/閘道失敗，則列車無效。移除或拆分有問題的 PR，然後重建列車。當
train-running持有列車時，不要合併不相關的工作。 -
在獲得所有者直接批准或有效的授權後，再次執行
train.sh並加上--merge --owner-authorization "Owner: ..."來按順序合併記錄的 PR 頭部。如果基底或頭部發生變更，它將拒絕，並在每次合併後驗證受保護分支的樹狀結構。
部署、凍結、保持、暫停
- 僅部署已設定的受保護分支，並且僅在存在匹配的樹狀憑證時進行部署，除非所有者提供記錄的例外情況。
- 為版本發布產生一份部署報告。將已發布的 PR 和議題標記為
deployed；將它們連結到同一份報告，而不是重複報告。 freeze會停止新的合併和部署。將無法讀取的標籤視為已凍結，以處理不可逆的動作。- 列車保持會阻止該列車之外的合併，直到列車退出。
- 暫停時，停止領取、列車、合併和部署。所有者張貼一個重新啟動列表，列出允許恢復的項目。在重新啟動之前，重新檢查標籤、PR 頭部、基底和憑證。
升級與授權
當產品、安全、法律、發布或所有權不明確的決策阻礙工作時，使用 needs-owner。說明觀察到的行為、選項、建議和截止日期（如果有的話）。繼續進行獨立的工作。
授權必須陳述其確切範圍和 UTC 到期時間，例如：
所有者：團隊A 可以合併和部署已審查的文件 PR 41 和 42，直到 2026-05-01T18:00:00Z。
該範圍之外或在到期後的任何操作都需要新的直接決策。
回顧
至少每週執行一次 scripts/scorecard.sh，並討論 reference/metrics.md 中的定義。每次改進一個可衡量的瓶頸。審查以下指標：每次合併 PR 的閘道執行次數、領取延遲、週期時間、佇列淨變化、平均批次大小、憑證覆蓋率以及變更失敗率。
在張貼狀態之前，請閱讀 reference/rules.md 以了解規範的編號規則以及 `reference/comment-templates.md。