From rhyanz46-devops
Generate and maintain CI/CD pipelines for microservice repos that deploy to a host running HashiCorp Nomad or PM2, hosted on either a VPS or AWS (EC2). Uses GitHub Actions, set up directly via the `gh` CLI (Environments + secrets). Server- and domain-agnostic. Use this skill whenever the user asks to create, add, generate, scaffold, or edit CI/CD / a deployment pipeline / GitHub Actions for a repo. On a repo WITHOUT CI/CD it runs an interview (infra target, Nomad vs PM2, environments, single vs multi-client) then generates. On a repo WITH CI/CD it asks whether to add a pipeline for a new business/client or edit the existing one. Pairs with the microservice-devops skill for the deploy steps.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rhyanz46-devops:cicd-pipelineThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill builds and maintains **GitHub Actions** CI/CD for repos that deploy to
This skill builds and maintains GitHub Actions CI/CD for repos that deploy to
a Nomad or PM2 host, on VPS or AWS (EC2). It is the operational
companion to microservice-devops: the deploy steps follow that skill's
doctrine; this skill owns the pipeline around them.
Server- and domain-agnostic. Never hardcode IPs, hostnames, domains, tokens,
registries, or credentials into a workflow. Everything environment-specific is a
GitHub secret or environment variable, referenced by name. The skill sets
those up via gh; it never writes secret values into files.
| Infra target | Orchestration | Notes |
|---|---|---|
| VPS | Nomad or PM2 | host behind a provider firewall is common |
| AWS (EC2) | Nomad or PM2 | EC2 instance running Nomad/PM2 — not ECS/Fargate |
AWS here means Opsi 1: an EC2 host running the same Nomad/PM2 stack. The
deploy mechanism is identical to VPS; only credentials/networking differ (see
references/infra-targets.md). ECS/Fargate/Lambda are out of scope.
Step 0 Detect existing CI/CD + context
├─ .github/workflows/*.yml present?
├─ deploy target hints: *.nomad → Nomad, ecosystem.config.js → PM2
└─ gh auth + repo access OK? (gh auth status; gh repo view)
│
┌──────────┴───────────┐
│ NO CI/CD exists │ CI/CD already exists
▼ ▼
Interview (Step 1) Ask: new business/client, or edit? (Step 2)
│ ├─ new client → generate one ci/clients/<name>.yml
▼ │ + register its secrets via gh (no
Generate (Step 3) │ pipeline-logic change) — see multi-client
└─ edit → modify existing workflow/config
Ask these, in order, using structured questions (one decision per question). Do
NOT assume — auto-detected values are confirmed, not taken silently. Full
wording and conditional logic in references/interview-flow.md.
references/multi-client.md)Ask a single branching question: add a pipeline for a new business/client, or
edit the existing pipeline? Then follow references/existing-cicd.md.
Adding a client must NOT rewrite working pipeline logic (rule #5).
.github/workflows/.gh (rule #2).ci/clients/<name>.yml config + matrix workflow.generate-nomad.md /
generate-pm2.md.gh. Generate workflows AND create the
Environments/secrets via the gh CLI. Precondition: gh auth status
succeeds and the user has admin/maintain rights on the repo (verify with
gh repo view / gh api repos/:owner/:repo perms). If not, stop and tell the
user what access they need — do not produce a half-set-up pipeline.${{ secrets.NAME }} / environment vars set
via gh secret set. The skill outputs a checklist of names to populate; it
does not write the values.prod environment gets required reviewers (an approval
gate) via gh. Prod never auto-deploys without that gate. dev/staging may
auto-deploy per the chosen trigger convention.develop→dev, main→staging, tag v*→prod; OR
environment-pick on manual workflow_dispatch; OR PR-merge gates). Record the
chosen mapping; make it visible at the top of the workflow.ci/clients/<name>.yml, consumed by a matrix. "New
business" = add one config file + its secrets; pipeline logic is untouched.
See references/multi-client.md.microservice-devops:
Nomad = build → push image → nomad job run; PM2 = build → sync → pm2 reload. Do not invent a divergent deploy path.gh secret list, gh api .../environments, existing workflow files) and
only add what's missing — never blindly overwrite a working pipeline without
confirming (rule #2 of microservice-devops: confirm prod-affecting changes).| Situation | Read |
|---|---|
| Conducting the interview | references/interview-flow.md |
| VPS vs AWS(EC2) credential/networking differences | references/infra-targets.md |
| Creating environments/secrets via gh | references/github-setup.md |
| Generating a Nomad-deploy workflow | references/generate-nomad.md |
| Generating a PM2-deploy workflow | references/generate-pm2.md |
| Modeling/serving multiple clients | references/multi-client.md |
| Repo already has CI/CD (edit vs new client) | references/existing-cicd.md |
npx claudepluginhub rhyanz46/devops-microservice-skills --plugin rhyanz46-devopsProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.