（3744期）Gitlab Workflow – GitLab 全流程自动化工作流

GitLab 全流程自动化工作流 GitLab 工作流助手，支持 MR 管理、代码审查、CI/CD 监控、分支操作，通过 MorphixAI 代理安全访问 GitLab API 使用说明 GitLab 工作流助手评估 核心用法 本 skill 是一套完整的 GitLab DevOps 工作流自动化方案，主要通过 mx_gitlab 工具与 nodes.run 本地命令协同工作。 主要功能模块： MR 全生命周期管理：创建、审批、状态检查、合并操作 代码审查：优先使用本地 git 进行 diff 分析，备选 MorphixAI 代理 API CI/CD 监控：Pipeline 列表查询、失败重试、状态监控 Issue 与分支管理：创建 Issue、列出分支、搜索项目 关键设计理念： 本地 git 优先：大型 MR 的 diff 审查通过本地命令完成，规避 API 响应体限制 状态驱动合并：严格要求先调用 getmergerequest 确认 detailedmergestatus 为 "mergeable" 再执行合并 规范化约束：强制分支命名规范（feature/JIRA-{ID}-xxx）、Commit message 格式（Scope: action description） 显著优点 完整的工作流闭环：从 MR 创建到合并的全流程自动化，减少人工切换成本 双模式代码审查：本地 git（无限制、快速）+ 代理 API（无本地仓库时备用），覆盖多种场景 防御性状态检查：内置合并前置条件验证，避免 500 错误和误操作 团队规范内建：分支命名、MR 描述模板、Review 检查清单等规范直接写入技能定义 心跳监控集成：支持 Pipeline 长时间监控场景，可结合 HEARTBEAT 机制异步追踪 潜在缺点与局限性 外部依赖较重：必须安装 openclaw-morphixai 插件、配置 MORPHIXAIAPIKEY、完成 GitLab 账号链接，初始化门槛较高 API 限制风险：mx_link proxy 获取大型 MR diff 可能因响应体过大返回 400，需降级到本地 git 状态延迟问题：detailedmergestatus 刚创建 MR 时为 "preparing"，需轮询等待，技能本身未内置自动重试逻辑 心跳间隔限制：默认 30m-1h 的心跳间隔不适合实时监控场景，需依赖外部 HEARTBEAT.md 机制 平台锁定：深度绑定 MorphixAI 代理架构，无法直接对接原生 GitLab API 或其他代理方案 适合人群 使用 GitLab 作为代码托管平台的开发团队 需要严格执行代码审查规范和分支策略的技术负责人 追求 MR、CI/CD、Issue 一站式管理的 DevOps 工程师 已有 MorphixAI/OpenClaw 生态使用基础的用户 常规风险 认证凭证泄露：MORPHIXAIAPIKEY 需配置为环境变量，存在被意外提交到版本控制的风险 误合并风险：尽管有状态检查，但并发场景下 MR 状态可能变化，直接调用合并仍存在竞态条件 本地命令注入：nodes.run 执行的 git 命令依赖用户输入（分支名、路径等），若未充分校验可能引入命令注入 Pipeline 误判：监控机制依赖手动轮询或心跳触发，非实时推送，关键 CI 状态变更可能延迟感知 原始说明 GitLab 工作流助手，严格遵循团队规范。用于 MR 管理、代码审查、CI/CD 状态查询、分支管理和合并操作。通过 MorphixAI 代理安全访问 GitLab API。