Cicd orchestrator

Skill Ow1onp/hermes-agent-skills/skills/ship/cicd-orchestrator

Production-grade skills for Hermes Agent - self-evolving, persona-aware, slash-command native

Install

npx -y skills add Ow1onp/hermes-agent-skills --skill cicd-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when setting up or optimizing CI/CD pipelines. Generates GitHub Actions workflow configurations following best practices — matrix builds, caching, artifact management, and deployment gates.

SKILL.md

4.6 KB, as published. Nobody here has run it

CI/CD 编排器 (CI/CD Orchestrator)

1. 概述

CI/CD 流水线是现代软件工程的脊柱。一个设计良好的流水线在 5 分钟内给出反馈，差的流水线让开发者等 30 分钟却只得到一个无关紧要的 lint 警告。本技能基于 .github/workflows/ 规范，生成经过实战验证的 CI/CD 配置。

融入 Hermes Agent 的优势：利用 terminal 验证 workflow 语法，利用 cronjob 设置定时流水线，利用 webhook 触发外部构建系统。

2. 核心流程

2.1 流水线设计原则

快速反馈原则：
  Lint (30s) → Unit Test (2min) → Integration Test (5min) → Deploy Preview (8min)
   └─ 快速失败 — 如果 lint 不过，不跑测试
  
并行原则：
  ┌─ Lint ──────────────┐
  ├─ Unit Test (py3.10) ─┤
  ├─ Unit Test (py3.11) ─┼─→ Integration Test → Deploy
  ├─ Unit Test (py3.12) ─┤
  └─ Security Scan ─────┘

幂等原则：
  同样的 commit 跑 100 次，结果不变

2.2 GitHub Actions 模板生成

本技能自动生成以下标准 workflow：

1. CI (Continuous Integration)

name: CI
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [checkout, setup-python, ruff check]
  
  test:
    needs: lint
    strategy:
      matrix:
        python-version: ["3.10", "3.11", "3.12"]
    steps: [checkout, setup-python, pytest --cov]
  
  security:
    needs: lint
    steps: [checkout, pip-audit, bandit]

2. CD (Continuous Deployment)

name: CD
on:
  push:
    tags: ["v*"]
jobs:
  build:
    steps: [checkout, build-package]
  publish:
    needs: build
    steps: [publish-to-pypi / docker-push]
  deploy:
    needs: publish
    steps: [deploy-to-production]

3. Scheduled Tasks (Cron)

name: Nightly
on:
  schedule: [{cron: "0 3 * * *"}]
jobs:
  full-suite: [runs full test suite]
  dependency-audit: [pip-audit, npm audit]

2.3 Hermes 工具链集成

# 验证 workflow 语法
terminal(command="act --dryrun -W .github/workflows/ci.yml")

# 使用 Hermes cronjob 设置定时质量检查
cronjob(
    action="create",
    schedule="0 9 * * *",
    prompt="Run full test suite and report coverage",
    skills=["test-driven-dev"],
    name="Daily Test Suite"
)

# 利用 Hermes webhook 触发部署
# 配置 webhook 接收 GitHub release 事件
webhook(
    action="subscribe",
    name="release-webhook"
)

2.4 自进化机制

构建时间优化：追踪每次 CI 运行时间，自动建议缓存优化和并行化机会
失败模式学习：分析 CI 失败日志，识别常见失败原因并建议预防措施
流水线模板升级：根据 GitHub Actions 的最新特性和最佳实践，自动建议 workflow 升级
资源利用率优化：分析 matrix build 的实际需求，建议减少不必要的组合

2.5 身份感知

读取 SOUL.md 中的部署偏好（如 "偏好蓝绿部署" 或 "偏好滚动更新"）
CD 策略自动适配偏好
通知方式适配（Slack / Discord / Email）

3. 门禁标准

CI workflow 包含 lint + test + security 三个基础 job
测试矩阵覆盖项目支持的所有主要版本
有明确的缓存策略（pip cache, node_modules cache）
CD workflow 有明确的回滚方案（或回滚文档链接）
敏感信息（API Key, Token）通过 GitHub Secrets 管理，不硬编码
Workflow 语法已验证通过

4. 常见逃避借口与反驳

借口	反驳
"先手动部署，CI/CD 以后再加"	第一次手动部署的 10 分钟 = 第 100 次的 1000 分钟。自动化投资回报是指数级的。
"我们的项目太小，不需要 CI"	小项目今天不需要，但明天就会长大。CI 配起来只需要 30 分钟，却能用 3 年。
"GitHub Actions 免费额度够吗"	公开仓库无限免费。私人仓库每月 2000 分钟，对于 90% 的项目绰绰有余。
"CI 跑得太慢了"	慢说明你的流水线设计有问题，而不是 CI 本身的问题。优化它，别放弃它。
"我只是一个人开发，不需要 CD"	一个人开发更需要自动化——你没有队友帮你 catch 部署失误。