Cicd Engineer

CI/CD Engineer

When to Use

• Design or implement CI/CD for a skills monorepo (validate on PR, package on release)
• Add or fix GitHub Actions workflows for skill folders, changed-path detection, and matrix validation
• Wire skill-creator scripts (quick_validate.py, package_skill.py) into pipelines
• Define quality gates: frontmatter, description length, reference layout, batch validate
• Plan release and promotion for .skill artifacts (tags, environments, changelogs)
• Document secrets, OIDC, and fork-safe PR checks for skill repos
• Write rollback and change-management steps for a bad skill release
• Produce runbooks for on-call during skill publish failures

When NOT to Use

• Application/service CI only (containers, K8s deploy, app test suites) without skill packaging → devops
• Pre-flight architecture or build go/no-go before execution → build-validator
• Internal developer platform, golden paths, Backstage, paved-road templates → platform-engineer
• SLI/SLO programs, error budgets, burn-rate alerting, PRR without pipeline work → site-reliability-engineer
• Skill catalog inventory, overlap dedup, deprecate/split governance without CI YAML → ai-skill-manager
• Security gates (SBOM, SAST policy, supply-chain signing) as the primary task → devsecops
• Author a single new skill from scratch (content only) → skill-creator / init_skill.py

Related skills

Core Workflows

1. Pipeline topology for skills repos

Standard stage order:

checkout → detect changed skills → validate (quick_validate) → optional lint/scripts → package on release tag → publish artifact → notify

Checklist:

• Pipeline as code under .github/workflows/; versioned with repo
• PR jobs run on changed skill directories only when possible
• quick_validate.py gates merge; fail closed on invalid frontmatter
• Release job runs package_skill.py only after validation passes
• Artifacts immutable (tag + commit SHA in name or metadata)
• Manual or environment approval before org-wide distribution

See references/pipeline_design_and_workflow.md.

2. GitHub Actions implementation

1. Use paths / paths-filter for **/SKILL.md and references/**
2. Matrix or loop per changed skill directory
3. Cache nothing sensitive; use GITHUB_TOKEN with least scope
4. Fork PRs: read-only checks; no secrets on pull_request_target without hardening
5. Reusable workflow (workflow_call) for validate + package jobs

See references/github_actions_and_build.md.

3. Testing and quality gates

See references/testing_gates_and_quality.md.

4. Skill validation and packaging CI

python3 ~/.claude/skills/skill-creator/scripts/quick_validate.py path/to/skill-dir
python3 ~/.claude/skills/skill-creator/scripts/package_skill.py path/to/skill-dir ./dist

• PR: validate changed skills only
• Release: package validated skills; attach .skill to GitHub Release or internal registry
• Do not package every skill on every PR unless releasing a bundle

See references/skill_validation_and_packaging_ci.md.

5. Deployment, promotion, and operations

1. Dev/staging: auto-validate on PR merge to main
2. Release: tag skill-v* or calendar version; package and publish
3. Promotion: copy artifacts to consumer paths (plugin cache, internal registry) with checksum
4. Rollback: re-publish previous tag artifacts; document superseded skill description if needed
5. Runbook: who approves, how to verify install, comms for broken bundle

See references/deployment_promotion_and_operations.md.

6. Scope and boundaries

Confirm the ask is skills-repo CI/CD, not generic platform ops. Load references/cicd_engineer_scope.md when routing or scoping engagements.

When to load references