ruflo agent-ops-cicd-github 技能详解用一份声明式规格定义 GitHub Actions CI/CD 工程师 Agent【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflorufloThe original agent meta-harness通过.agents/skills/目录下的 SKILL.md 文件把专家角色沉淀为可被 Codex CLI 等 harness 加载的声明式技能。本文以 .agents/skills/agent-ops-cicd-github/SKILL.md 为主体逐段拆解这份cicd-engineer技能的完整规格——从触发条件、工具白名单、文件沙箱到生命周期钩子与 CI/CD 工作流模板——并结合 config.toml、CLAUDE.md 与 pod-schema.ts 等仓库源码说明该技能在 ruflo 体系中的注册与协作位置。读完本文你可以掌握 ruflo 技能的双层 frontmatter 编写规范、Agent 能力预算与安全约束的声明方式并得到一个可直接复用的 GitHub Actions 工作流基线模板。一、技能在 ruflo 中的位置.agents 目录与双层 frontmatter按 .agents/README.md 的说明.agents/目录是 agent configuration and skills for OpenAI Codex CLI其标准结构为config.toml主控配置skills/skill-name/SKILL.md存放技能指令可选附带scripts/与docs/技能通过$skill-name语法调用。仓库中该目录下已有上百个同类技能如agent-swarm、github-automation、github-workflow-automation、security-audit等agent-ops-cicd-github是其中专攻 CI/CD 的一个。该 SKILL.md 采用双层 YAML frontmatter结构这也是理解其成文骨架的关键外层 frontmatterL1–L4技能注册层name: agent-ops-cicd-githubdescription 明确invoke with$agent-ops-cicd-github即声明了 harness 的调用入口内层 frontmatterL6–L121完整的 Agent 规格层包含角色名、触发器、能力、约束、行为、集成关系、性能参数、生命周期钩子和调用示例。这种分层让harness 如何找到它与它是什么、能做什么、边界在哪两件事解耦。二、角色身份与元数据内层 frontmatter 定义了 Agent 的身份字段见 SKILL.md L7–L17字段取值含义namecicd-engineer角色名后续在 ruflo 业务 Pod 等机制中以此名引用descriptionSpecialized agent for GitHub Actions CI/CD pipeline creation and optimization一句话职责定位创建与优化流水线typedevops角色类别colorcyanUI 展示色version/created1.0.0/2025-07-25静态版本快照autonomoustrue允许自主执行specializationGitHub Actions, workflow automation, deployment pipelines专业领域complexitymoderate复杂度分级三、触发系统关键词、文件模式与任务模式triggers段L18–L37声明了四种激活信号。需要说明原文文件用$占位路径分隔符如.github$workflows、ci$cd还原为标准写法如下keywordsgithub actions、ci/cd、pipeline、workflow、deployment、continuous integration—— 用户语句命中这些词即可唤起file_patterns.github/workflows/*.yml、.github/workflows/*.yaml、**/action.yml、**/action.yaml—— 当操作对象是工作流文件或复合 Action 定义文件时该技能与当前任务天然相关这是上下文感知式的触发依据task_patternscreate * pipeline、setup github actions、add * workflow—— 匹配典型任务句式domainsdevops、ci/cd—— 领域标签供调度器归类。从这份清单可以看出设计意图让 harness 在用户提到 CI或正在改 workflow 文件两种情况下都能把任务路由给 cicd-engineer。四、工具白名单与执行预算capabilitiescapabilities段L38–L52为该 Agent 划定了能力边界与资源预算配置项取值说明allowed_toolsRead, Write, Edit, MultiEdit, Bash, Grep, Glob文件读写、编辑、执行与检索全套本地工具restricted_toolsWebSearch, Task注释写明Focused on pipeline creation——禁止联网检索也禁止再派生子任务强制聚焦max_file_operations40单次执行的文件操作上限max_execution_time300执行时长预算秒与 .agents/config.toml 中[performance]段的task_timeout 300相互呼应memory_accessboth可读可写记忆restricted_tools把Task子任务委派列入限制、can_spawn: []为空见第七节两处共同表达同一个约束cicd-engineer 是一个终端执行者而非协调者它的价值在于把流水线文件做对而不是继续分裂任务。五、文件系统沙箱constraintsconstraints段L53–L70是这份规格的安全核心用允许 禁止 体积 类型四道闸门限定操作面constraints: allowed_paths: - .github/** - scripts/** - *.yml - *.yaml - Dockerfile - docker-compose*.yml forbidden_paths: - .git/objects/** - node_modules/** - secrets/** max_file_size: 1048576 # 1MB allowed_file_types: - .yml - .yaml - .sh - .json允许面完全贴合 CI/CD 工程师的合理工作半径.github/**工作流与 Action 定义、构建脚本、YAML 配置与容器编排文件禁止面则封死 Git 内部对象、依赖目录和任何名为secrets的目录。这套思路与 .agents/config.toml 全局[security]段的策略一脉相承——后者同样声明了secret_scanning true、path_traversal_prevention true并用正则blocked_patterns\.env$、credentials\.json$、\.pem$、\.key$全局拦截敏感文件。技能级沙箱相当于在全局安全策略之上再收了一圈。六、行为策略与人工确认闸门behavior / communicationbehavior段L71–L78规定了失败与高危操作时的行为准则配置项取值解读error_handlingstrict错误不容忍直接暴露而非静默兜底confirmation_requiredproduction deployment workflowssecret management changespermission modifications三类高危变更必须先向人确认生产部署工作流、密钥管理变更、权限修改auto_rollbacktrue失败时自动回滚logging_leveldebug调试级日志便于审计每次流水线改动communication段L79–L83则约束交互风格style: technical技术化表达、update_frequency: batch批量汇报而非逐条刷屏、include_code_snippets: true回复必须附带代码片段、emoji_usage: minimal。与第六节的高危操作确认叠加requires_approval_from: security见下节构成了双闸门既需要人确认也需要 security 域角色审批——这正是该技能生产流水线安全立场的声明式表达。七、多 Agent 协作拓扑integrationintegration段L84–L93描述了它在 ruflo 多 Agent 体系中的位置配置项取值含义can_spawn[]不派生任何子 Agentcan_delegate_toanalyze-security、test-integration遇到安全分析、集成测试问题时可委派给对应专家requires_approval_fromsecurity注释标注For production pipelines——生产流水线变更需 security 角色审批shares_context_withops-deployment、ops-infrastructure与部署、基础设施两个运维角色共享上下文保证 CI 改动与部署环境信息对齐仓库其他位置印证了cicd-engineer这个角色的真实使用场景CLAUDE.md 将其列入角色名录与backend-dev、system-architect、api-docs等并列v3/claude-flow/cli/src/business-pods/pod-schema.ts 的合法角色列表中包含cicd-engineerplugins/ruflo-business-pods/templates/ops.json 运维业务 Pod 模板与 v3/mcp/tools/agent-tools.ts 的 Agent 工具实现中也引用了该角色名。可以推断在 ruflo 的 business pod 模型里cicd-engineer 是运维域 Pod 的默认成员之一而非孤立技能。八、性能优化参数optimizationoptimization段L94–L98给出执行期调优参数optimization: parallel_operations: true # 允许并行操作 batch_size: 5 # 批量大小 cache_results: true # 缓存结果 memory_limit: 256MB # 技能级内存预算对照 .agents/config.toml 的全局[performance]段max_agents 8、parallel_execution true、cache_enabled true、cache_ttl 3600、memory_limit 512MB从源码结构看技能级的 256MB 预算比全局默认值更保守属于该角色自我加压的声明并行与缓存策略则与全局配置保持一致说明技能参数是全局策略的细粒度覆盖而非另起炉灶。九、生命周期钩子项目自探测与产出校验hooks段L99–L115以 shell 脚本声明了执行前、执行后与出错时的行为还原原文$占位符后的逻辑pre_execution —— 环境盘点与技术栈识别echo GitHub CI/CD Pipeline Engineer starting... echo Checking existing workflows... find .github/workflows -name *.yml -o -name *.yaml 2/dev/null | head -10 || echo No workflows found echo Analyzing project type... test -f package.json echo Node.js project detected test -f requirements.txt echo Python project detected test -f go.mod echo Go project detected设计意图很清晰动手写工作流之前先盘点仓库已有 workflow避免重复或覆盖再通过三个指纹文件package.json/requirements.txt/go.mod推断项目类型为后续选择setup-node、setup-python或 Go 工具链 Action 提供依据。post_execution —— 产出校验遍历.github/workflows下所有 yml/yaml 文件并打印首行作为简易 YAML 校验注释中自述为 Simple YAML validationon_error —— 标准化错误回执echo ❌ Pipeline configuration error: {{error_message}} echo Check GitHub Actions documentation for syntax{{error_message}}是留给 harness 填充的模板占位符体现了钩子脚本声明式模板 运行时注入的编写方式。十、调用示例examplesfrontmatter 末尾给出两组触发/响应样例L116–L121可视为该技能的验收用例触发create GitHub Actions CI/CD pipeline for Node.js app→ 响应创建覆盖 build、test、deployment 三阶段的综合工作流触发add automated testing workflow→ 响应创建在 pull request 上运行、含测试覆盖率报告的自动化测试工作流。两条示例恰好覆盖从零建流水线与增强测试两种典型任务且与task_patterns中的句式一致。十一、正文职责、最佳实践与工作流模板frontmatter 之后的正文L123–L169是给 LLM 的提示词主体共四块Key responsibilitiesL127–L133——五项核心职责创建高效 GitHub Actions 工作流实现 build/test/deploy 流水线配置多环境测试的 job matrix搭建缓存与 artifact 管理落实安全最佳实践。Best practicesL134–L141——六条实践原则逐条对应文档中的声明用 composite action 实现工作流复用workflow reusability实施正确的密钥管理proper secret management最小化工作流执行时间选用合适的 runner如ubuntu-latest实施分支保护规则branch protection rules有效缓存依赖。Workflow patternL143–L163——文档给出的 Node.js CI 基线模板。原文以$代替 Action 引用中的/还原为标准 GitHub Actions 语法如下可复制到github/workflows/ci.yml作为起点name: CI/CD Pipeline on: push: branches: [main, develop] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 18 cache: npm - run: npm ci - run: npm test该模板本身就示范了前文多项声明cache: npm落实有效缓存依赖npm ci而非npm install保证可复现安装对应最小化执行时间触发器区分 pushmain/develop与 pull_requestmain配合最佳实践第 5 条的分支保护形成常规防线runs-on: ubuntu-latest对应第 4 条。矩阵测试、composite action 复用等进阶项正文以实践原则形式给出而非完整 YAML属于刻意留白——留给 Agent 在具体项目中按职责第 3 条现场生成。Security considerationsL165–L169——安全基线四条绝不硬编码密钥GITHUB_TOKEN使用最小权限用CODEOWNERS管控工作流文件变更使用 environment 保护规则。其中CODEOWNERS 管控 workflow 变更与第六节confirmation_required中的permission modifications互相咬合机器侧强制人审仓库侧强制指定 owner 批准双保险。十二、如何验证与延伸阅读技能目录全貌.agents/skills/ 下可对比上百个兄弟技能的双层 frontmatter 写法与本技能直接相关的还有 github-workflow-automation、security-audit、hooks-automationharness 配置.agents/config.toml 中[[skills.config]]段L83–L97显式启用了 swarm-orchestration、memory-management、sparc-methodology、security-audit 四个技能从源码结构看agent-ops-cicd-github未出现在该显式名单中其调用更可能依赖 harness 对skills/目录的扫描与$agent-ops-cicd-github语法适用前提是所用 harness 支持目录扫描式技能发现角色注册链路CLAUDE.md → pod-schema.ts → ops.json展示了cicd-engineer从文档角色到 Pod Schema 合法取值再到运维 Pod 模板的完整落地链。十三、适用性与限制最后明确几点边界这份 SKILL.md 是声明式提示词规格本身不是可执行引擎——max_execution_time: 300、memory_limit: 256MB、max_file_operations: 40等是技能向 harness 申报的预算与约束其实际强制力取决于加载方Codex CLI / Claude Code 等对这些字段的解析程度钩子脚本假定 Linux/macOS 的find/test可用on_error的{{error_message}}需 harness 完成模板注入version: 1.0.02025-07-25是静态快照角色在 business pod 中的行为还会受 pod-schema.ts 侧 Schema 约束共同限定。在 ruflo 仓库语境下阅读该文件的最佳路径是先按本文十一节的模板落地一条最小 CI 流水线再对照第四、五、六节理解一个受限、可审计、需人审的 CI/CD 专家 Agent应当声明哪些边界——这正是 agent-ops-cicd-github 技能给开发者留下的最大参考价值。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考