核心用法
launchthatbot/git-team-ops 是一款面向多智能体协作的 GitOps 技能，通过严格的角色分离（junior/senior）实现代码贡献与仓库治理的分层管控。初级模式限定于分支创建、代码提交与 PR 发起；高级模式则涵盖代码审核、合并、发布触发及工作流模板管理。
技能启动后强制收集三项信息：智能体角色类型、目标 GitHub 仓库、认证方式（托管应用/自有应用/个人令牌）。认证体系设计体现纵深防御：托管模式采用短期 onboarding token 与平台端点交互，匿名 IP 限流 3 个并发租约；自有应用模式要求提供 App ID、Installation ID 及 PEM 私钥；个人令牌仅作降级备选，并建议迁移至应用模式。
高级用户 onboarding 包含标准化流程：创建 chore/gitops-bootstrap 分支，注入 PR 验证、发布控制工作流模板及 CODEOWNERS 文件，经人工审核合并后激活 CI 治理。初级用户则需完成分支创建、轻量提交与 PR 验证，以确认权限边界。
显著优点
1. 角色最小权限：强制分离代码贡献与仓库治理权限，降低误操作与权限滥用风险。
2. 多模式认证：托管模式零配置上手，自有应用满足企业合规，个人令牌兜底兼容。
3. 模板化治理：内置工作流模板实现 PR 验证、发布控制的快速落地，避免重复造轮子。
4. 操作可审计：强制声明角色、仓库、分支及变更文件，输出风格标准化，便于追溯。
潜在局限
- 平台锁定：托管模式依赖 LaunchThatBot 服务端点，若平台不可用则强制降级。
- 角色静态：
junior/senior二元划分，缺乏更细粒度（如只读审核员、紧急发布者）的中间角色。 - GitHub 专属：工作流模板与权限模型深度绑定 GitHub，不支持 GitLab、Bitbucket 等替代平台。
- 人工卡点：高级 onboarding 要求用户手动合并 PR，无法全自动完成初始治理植入。
适合人群
- 采用 OpenClaw 智能体框架的 DevOps 团队，需快速建立人机协作的 GitOps 规范。
- 多智能体场景下需严格区分代码贡献与发布权限的组织。
- 希望以托管服务降低 GitHub App 运维负担的中小团队。
常规风险
- Token 泄露：短期 onboarding token 若被日志打印或持久化，可能导致仓库权限被劫持。
- IP 限流绕过：匿名模式下 3 个并发租约的限制可能被恶意消耗，影响正常业务。
- 分支保护绕过：尽管策略禁止，但配置错误的仓库可能仍存在 force-push 漏洞。
- 依赖供应链：工作流模板来自技能包，若分发渠道被投毒，将直接影响目标仓库 CI 安全。