核心用法
launchthatbot-git-team-ops 是一款面向 OpenClaw 多智能体系统的 GitOps 工作流技能，通过严格的角色分离机制实现安全的团队协作。该技能将智能体划分为两种互斥模式：
- Junior 模式：专精于代码开发与 PR 提交，支持从 main 分支创建特性分支、提交代码变更、推送分支并发起 Pull Request，但明确禁止合并操作、强制推送保护分支及修改工作流文件
- Senior 模式：承担代码评审、合并发布及仓库治理职责，可审查并合并 junior 的 PR、强制执行分支保护规则、更新 CI/CD 工作流模板并触发生产部署
技能提供三种认证机制：托管应用模式（推荐，通过短期 onboarding token 免登录接入）、自带应用模式（用户提供 GitHub App 凭证）以及 PAT 回退模式。
显著优点
1. 零信任权限架构：通过代码级策略引擎强制角色边界，而非依赖人为提示约束，从根本上杜绝权限越界
2. 工作流即代码：内置标准化模板（PR 验证、发布控制、CODEOWNERS），确保团队遵循统一的最佳实践
3. 安全优先的认证设计：优先使用 GitHub App 安装令牌而非 PAT，支持自动轮换；托管模式下采用一次性 onboarding token，避免长期凭证泄露风险
4. 合规可审计：所有操作强制声明角色身份、目标仓库及分支信息，并明确标注待人工审批节点，形成完整操作链条
潜在缺点与局限性
1. 平台绑定：深度依赖 LaunchThatBot 托管服务及 OpenClaw 运行时环境，跨平台迁移成本较高
2. 角色僵化：双模式设计难以应对模糊职责场景，临时性的 senior-junior 协作需求缺乏弹性机制
3. 托管模式限制：匿名 IP 仅支持 3 个并发 bot 租约，大规模团队并行开发可能触及速率限制
4. 模板定制化弱：预置工作流模板面向通用场景，特定技术栈（如特定云厂商、自定义构建工具）需额外开发适配层
适合人群
- 采用 OpenClaw + GitHub 技术栈的中小工程团队，寻求开箱即用的 GitOps 合规方案
- 对权限分离有强监管需求的组织（如金融、医疗 SaaS），需防止单一智能体拥有过宽操作权限
- 已通过 LaunchThatBot 平台部署智能体的现有用户，希望扩展多智能体协作能力
常规风险
1. Token 生命周期管理：尽管设计上要求 onboarding token 仅存活于单会话，若用户环境异常持久化缓存，仍存在横向移动风险
2. 模板注入：工作流模板更新由 senior 智能体执行，若模板源遭供应链攻击，可能批量污染下游仓库
3. 角色协商盲区：当前实现未内置 junior-senior 智能体间的自动协商协议，跨角色协作仍需人工介入编排
4. IP 封禁连锁：托管模式的源 IP 速率限制在共享出口场景（如企业 NAT、云函数）下可能导致服务中断