Menu
Use when designing, debugging, or fixing CI/CD pipelines — GitHub Actions, GitLab CI, Jenkins
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | ci-cd-pipeline |
| description | Use when designing, debugging, or fixing CI/CD pipelines — GitHub Actions, GitLab CI, Jenkins |
tooling/ci/. Scaffold or modify pipeline configs.lint → test → build → push image → deploy staging → smoke test → deploy production
# Enable debug logging by setting repository secret:
ACTIONS_STEP_DEBUG = true
ACTIONS_RUNNER_DEBUG = true
Common issues:
| Issue | Fix |
|---|---|
Context access might be invalid | Check secret/var name spelling |
Resource not accessible by integration | Add permissions: block to workflow |
Process completed with exit code 1 | Read that step's full log output |
| Workflow not triggering | Check on: trigger matches branch/event |
# Run only on main branch
on:
push:
branches: [main]
# Matrix builds
strategy:
matrix:
node-version: [18, 20, 22]
# Reuse secrets
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
Common issues:
| Issue | Fix |
|---|---|
| Job stuck in pending | Check runner availability and tags |
artifacts not found in later stage | Define artifacts: in the producing job |
| Cache not working | Check cache: key is consistent |
Common issues:
| Issue | Fix |
|---|---|
| Build never starts | Check agent availability and labels |
| Credentials not found | Verify credential ID in Jenkins credentials store |
| Workspace dirty | Add cleanWs() at start of pipeline |
tooling/ci/github-actions/ — reusable workflow templatestooling/ci/gitlab-ci/ — .gitlab-ci.yml templatestooling/ci/jenkins/ — Jenkinsfile templatestooling/ci/starters/ — full CI/CD setups by stackUse before any DevOps build, change, or new feature — refine requirements through dialogue before touching infrastructure or code
Use when working with Docker — building images, writing Dockerfiles, debugging container issues
Use to execute a written implementation plan via subagents with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when working with Kubernetes or Helm — authoring, reviewing, hardening, or debugging manifests, Deployments, Services, Ingress, RBAC, NetworkPolicy, or cluster operations
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation