团队协作循环是做什么的？

当两个协作团队或智能体在同一个仓库中工作时，使用此技能。将“团队A”和“团队B”替换为配置的名称。所有者是人类，是优先级、合并、部署、冻结和策略决策的权威。

入职：五分钟设置

将此技能复制到目标仓库中，并为活跃的智能体工具安装适配器。
将 templates/team-loop.yml 复制到 .team-loop.yml；设置团队名称和 gate_command。
运行 scripts/setup-labels.sh --repo OWNER/REPO。
让所有者创建一个置顶的协调议题和一个标有 ready 标签的议题。
每个团队阅读此文件，最多认领一个待办项，并使用配置的状态标头。

角色

所有者： 创建或升级准备好的工作；以其原话发布直接的 Owner: 决策；授权合并和部署，除非在具有范围和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，最早的有效认领评论获胜；另一个团队回退。不要通过重复实现来解决平局。

评论与沟通

每个团队评论在其第一行必须以以下格式开头：

Status: <状态> | Team: <已配置的团队> | <简短上下文>

仅发布包含计划的认领、审查结论、门控结果、移交、问题、面向所有者的升级、协议或发布报告。不要发布已开始、已排队、仍在等待、重新准备或其他仪式性评论。保持常规评论在五个短行内；将证据放在PR描述或折叠的详情中。

只有所有者编写 Owner: 决策。团队必须链接或请求直接的所有者评论，绝不能将其作为权威转述。

标签与路由

使用 reference/labels.md 中的标签。未分配的ready议题默认归于团队A，除非配置另有说明。team:any 允许任一团队认领。空闲时，按以下顺序帮助另一个团队：请求的审查、列车准备或变基，然后是每周backlog批次。未经所有者请求，不要进行无明确范围的bug普查。

审查、列车、门控、证书

每个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 停止新的合并和部署。对于不可逆操作，将失败的标签读取视为冻结状态。
列车持有（hold）会阻止该列车之外的合并，直到列车退出。
在暂停（pause）时，停止认领、列车、合并和部署。所有者发布一个重启列表，列出允许恢复的项目。在重启前，重新检查标签、PR头部、基准和证书。

升级与授权

当产品、安全、法律、发布或模糊的归属决策阻碍工作时，使用 needs-owner。描述观察到的行为、选项、建议以及截止日期（如果有）。继续独立的工作。

授权必须陈述其确切范围和UTC过期时间，例如：

Owner: 团队A可以合并和部署已审查的文档PR 41和42，直到2026-05-01T18:00:00Z。

超出该范围或过期后的任何操作都需要新的直接决策。

回顾

至少每周运行 scripts/scorecard.sh 并讨论 reference/metrics.md 中的定义。每次改进一个可衡量的瓶颈。审查每次合并PR的门控运行次数、认领延迟、周期时间、队列净变化、平均批量大小、认证份额和变更失败率。

在发布状态之前，请阅读 reference/rules.md 了解规范的编号规则和 reference/comment-templates.md 了解评论模板。

团队协作循环