OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add akin-ozer/cc-devops-skills --skill gitlab-ci-generator
Create, generate, or scaffold .gitlab-ci.yml pipelines, stages, and jobs.
npx skills add akin-ozer/cc-devops-skills --skill gitlab-ci-generator
Generate production-ready GitLab CI/CD pipeline configurations following current best practices, security standards, and naming conventions. All generated resources are automatically validated using the devops-skills:gitlab-ci-validator skill to ensure syntax correctness and compliance with best practices.
Use this skill when the user asks for GitLab CI/CD generation requests such as:
.gitlab-ci.yml for..."Follow this deterministic flow in order:
targeted, lightweight, or full).If tooling is unavailable, use the documented fallback branch and report it explicitly.
| Request shape | Mode | Required references | Output profile |
|---|---|---|---|
| Simple single-file pipeline with common jobs/stages and low risk | Lightweight | Tier 1 (+ Tier 2 only if needed) | Lightweight confirmation + compact final sections |
Multi-environment deploy, advanced rules, includes/templates, security/compliance-sensitive workflow, or unclear/risky requirement | Full | Tier 1 + Tier 2 (Tier 3 only if needed) | Full confirmation + full final sections |
| Review/Q&A/snippet/focused fix (not full file generation) | Targeted | Only directly relevant files | Concise targeted response (no full boilerplate) |
When uncertain on a complete-generation request, route to Full mode.
CRITICAL: Before generating any complete GitLab CI/CD pipeline, complete these steps.
| Mode | Use When | Minimum Confirmation |
|---|---|---|
| Targeted | Review/Q&A/snippet/focused fix where full pipeline generation is not requested | Concise targeted response |
| Lightweight | Simple single-file pipeline, common stages/jobs, no advanced GitLab features, no sensitive deploy/security customization | Lightweight confirmation |
| Full | Multi-environment deploys, includes/templates, advanced rules logic, security scanning customization, compliance-sensitive workflows, or any unclear/risky request | Full confirmation |
When uncertain on a complete-generation request, default to Full mode.
Use an open/read action to load references based on the selected mode.
Targeted mode (review/Q&A/snippet/focused fix):
Tier 1 (Required for complete pipeline generation in Lightweight and Full modes):
references/best-practices.md - baseline security, performance, namingreferences/common-patterns.md - starting pattern selectionassets/templates/:
assets/templates/docker-build.ymlassets/templates/kubernetes-deploy.ymlassets/templates/multi-project.ymlassets/templates/basic-pipeline.ymlTier 2 (Required for Full mode; optional for Lightweight mode):
references/gitlab-ci-reference.md - keyword/syntax edge casesreferences/security-guidelines.md - security-sensitive controlsTier 3 (Conditional external docs lookup):
If a required local reference or template is unavailable:
Use for simple requests only.
Required format:
Example:
Use for complex or security-sensitive requests.
Required format:
Example:
Skipping confirmation is not allowed for complete pipeline generation.
Create complete, production-ready .gitlab-ci.yml files with proper structure, security best practices, and efficient CI/CD patterns.
When to use:
Process:
assets/templates/basic-pipeline.yml as structural foundationreferences/best-practices.md for implementation patternsreferences/common-patterns.md for standard pipeline patternsneeds keyword for DAG optimization when appropriaterules instead of deprecated only/excepttimeout for all jobs (10-30 minutes typically)Example structure:
Create pipelines for building, testing, and pushing Docker images to container registries.
When to use:
Process:
assets/templates/docker-build.yml as foundationExample:
Create pipelines that deploy applications to Kubernetes clusters.
When to use:
Process:
assets/templates/kubernetes-deploy.yml as foundationExample:
Create pipelines that trigger other projects or use parent-child pipeline patterns.
When to use:
Process:
assets/templates/multi-project.yml or parent-child templatesExample (Parent-Child):
Create reusable templates using extends, YAML anchors, and includes.
When to use:
Process:
extends keyword for inheritanceincludeExample:
Use this flow only when local references do not cover requested features or version-sensitive behavior.
Detection:
Process:
Identify the feature:
Check local references first (Tier 1/Tier 2):
references/common-patterns.mdreferences/gitlab-ci-reference.mdreferences/security-guidelines.mdUse Context7 first when external lookup is needed:
mcp__context7__resolve-library-idmcp__context7__query-docsFallback to web search when Context7 is unavailable or insufficient:
web.search_query"GitLab CI/CD [feature] documentation"docs.gitlab.comOpen and extract from specific docs pages when needed:
web.open for selected documentation pagesAnalyze discovered documentation for:
If network tools are unavailable (offline/constrained environment):
Generate pipeline using discovered information:
Example with GitLab templates:
Important: When using
includewith GitLab templates, the included jobs are fully defined in the template. If you need to customize them, prefer setting variables globally rather than creating partial job overrides (which will fail local validation because the validator cannot resolve the included template). GitLab merges the configuration at runtime, but local validators only see your.gitlab-ci.ymlfile.
CRITICAL: Every generated GitLab CI/CD configuration MUST be validated before presenting to the user.
Primary validation path: after generating a complete pipeline, invoke the devops-skills:gitlab-ci-validator skill:
Script fallback path (if validator skill cannot be invoked):
PIPELINE_FILE to the exact generated file path (for example, pipelines/review.yml or .gitlab-ci.yml).Manual fallback path (only if both primary and script paths are unavailable):
Validation status: Manual fallback (not fully verified).The validator skill/script checks:
Analyze validation results and take action based on severity:
| Severity | Action Required |
|---|---|
| CRITICAL | MUST fix before presenting. Pipeline is broken or severely insecure. |
| HIGH | MUST fix before presenting. Significant security or functionality issues. |
| MEDIUM | SHOULD fix before presenting. Apply fixes or explain why not applicable. |
| LOW | MAY fix or acknowledge. Inform user of recommendations. |
| SUGGESTIONS | Review and apply if beneficial. No fix required. |
Fix-and-Revalidate Loop (MANDATORY for Critical/High issues):
Before presenting to user, ensure:
When presenting the validated configuration:
Critical/High gate is strict and never optional for production-ready claims.
Pipeline is READY to present when:
Pipeline is NOT READY when:
Only skip validation when:
When the validator reports MEDIUM severity issues, you MUST either fix them OR explain why they're acceptable. This explanation is REQUIRED in your output.
Required format for MEDIUM issue handling:
Example MEDIUM issue explanations:
When to FIX vs ACCEPT:
| Scenario | Action |
|---|---|
| Production/high-security environment | FIX the issue |
| Issue has simple fix with no downside | FIX the issue |
| Fix adds significant complexity | ACCEPT with explanation |
| Fix requires external changes (e.g., CI/CD variables) | ACCEPT with explanation |
| Issue is false positive for this context | ACCEPT with explanation |
When the validator provides suggestions, you MUST briefly acknowledge them and explain whether they should be applied.
Required format:
Example suggestions review:
After validation results, include a concise freshness note for templates and documentation assumptions.
Required format:
Example:
After presenting the validated pipeline, you MUST provide usage instructions. This is NOT optional.
Required format:
Example usage instructions:
develop: Runs tests → builds Docker image → deploys to staging automaticallymain: Runs tests → builds Docker image → manual deployment to productionvX.Y.Z: Runs tests → builds Docker image → manual deployment to productionAPP_NAME variable to match your Kubernetes deployment namedeploy-staging and deploy-production jobsmcp__context7__resolve-library-id -> mcp__context7__query-docsweb.search_query scoped to docs.gitlab.comweb.open and extract only required syntax/variablesMANDATORY: Before presenting ANY generated pipeline to the user, verify ALL items:
Targeted, Lightweight, or Full)references/best-practices.md before generatingreferences/common-patterns.md before generatingassets/templates/ for the pipeline typereferences/gitlab-ci-reference.mdreferences/security-guidelines.md:latest)timeout (10-30 minutes typically)default block includes timeout if defined.template-name) include timeoutneeds keyword used for DAG optimization where appropriaterules used (not deprecated only/except)resource_group configured for deployment jobsexpire_in setdevops-skills:gitlab-ci-validator or script fallbackIf any checkbox is unchecked, DO NOT present the pipeline. Complete the missing steps first.
Use the smallest valid output profile for the selected mode.
Full mode (complete/complex pipeline):
.gitlab-ci.yml content)Lightweight mode (complete/simple pipeline):
Targeted mode (review/Q&A/snippet/focused fix):
This skill execution is done when:
Always follow this sequence when generating GitLab CI/CD pipelines:
Targeted, Lightweight, or Full mode.Targeted mode, load only directly relevant files.Lightweight/Full modes, load:
references/best-practices.mdreferences/common-patterns.mdassets/templates/Full mode, also load:
references/gitlab-ci-reference.mdreferences/security-guidelines.mdweb.search_query/web.open, with offline fallback notes when constrained.devops-skills:gitlab-ci-validator, script fallback if needed.Generate GitLab CI/CD pipelines that are:
## Reference Analysis Complete (Lightweight)
**Pattern:** Basic Build-Test-Deploy from common-patterns.md
**Template:** assets/templates/basic-pipeline.yml
**Key standards to enforce:**
- Pin runtime image versions (no `:latest`)
- Add explicit job timeouts
- Use `rules` instead of deprecated `only`/`except`## Reference Analysis Complete (Full)
**Pipeline Pattern Identified:** [Pattern name] from common-patterns.md
- [Brief description of why this pattern fits]
**Best Practices to Apply:**
- [List 3-5 key best practices relevant to this pipeline]
**Security Guidelines:**
- [List security measures to implement]
**Template Foundation:** [Template file name]
- [What will be customized from this template]## Reference Analysis Complete (Full)
**Pipeline Pattern Identified:** Docker Build + Kubernetes Deployment from common-patterns.md
- User needs containerized deployment to K8s clusters with staging/production environments
**Best Practices to Apply:**
- Pin all Docker images to specific versions (not `:latest`)
- Use caching for pip dependencies
- Implement DAG optimization with `needs` keyword
- Set explicit timeout on all jobs (15-20 minutes)
- Use `resource_group` for deployment jobs
**Security Guidelines:**
- Use masked CI/CD variables for secrets (KUBE_CONTEXT, registry credentials)
- Include container scanning with Trivy
- Never expose secrets in logs
**Template Foundation:** assets/templates/docker-build.yml + assets/templates/kubernetes-deploy.yml
- Combine Docker build pattern with K8s kubectl deployment
- Add Python-specific test jobs# Basic CI/CD Pipeline
# Builds, tests, and deploys the application
stages:
- build
- test
- deploy
# Global variables
variables:
NODE_VERSION: "20"
DOCKER_DRIVER: overlay2
# Default settings for all jobs
default:
image: node:20-alpine
timeout: 20 minutes # Default timeout for all jobs
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
before_script:
- echo "Starting job ${CI_JOB_NAME}"
tags:
- docker
interruptible: true
# Build stage - Compiles the application
build-application:
stage: build
timeout: 15 minutes
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 hour
rules:
- changes:
- src/**/*
- package*.json
when: always
- when: on_success
# Test stage
test-unit:
stage: test
needs: [build-application]
script:
- npm run test:unit
coverage: '/Coverage: \d+\.\d+%/'
artifacts:
reports:
junit: junit.xml
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml
test-lint:
stage: test
needs: [] # Can run immediately
script:
- npm run lint
allow_failure: true
# Deploy stage
deploy-staging:
stage: deploy
needs: [build-application, test-unit]
script:
- npm run deploy:staging
environment:
name: staging
url: https://staging.example.com
rules:
- if: $CI_COMMIT_BRANCH == "develop"
when: manual
deploy-production:
stage: deploy
needs: [build-application, test-unit]
script:
- npm run deploy:production
environment:
name: production
url: https://example.com
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
resource_group: productionstages:
- build
- scan
- push
variables:
DOCKER_DRIVER: overlay2
IMAGE_NAME: $CI_REGISTRY_IMAGE
IMAGE_TAG: $CI_COMMIT_SHORT_SHA
# Build Docker image
docker-build:
stage: build
image: docker:24-dind
timeout: 20 minutes
services:
- docker:24-dind
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker build
--cache-from $IMAGE_NAME:latest
--tag $IMAGE_NAME:$IMAGE_TAG
--tag $IMAGE_NAME:latest
.
- docker push $IMAGE_NAME:$IMAGE_TAG
- docker push $IMAGE_NAME:latest
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
retry:
max: 2
when:
- runner_system_failure
# Scan for vulnerabilities
container-scan:
stage: scan
image: aquasec/trivy:0.49.0
timeout: 15 minutes
script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $IMAGE_NAME:$IMAGE_TAG
needs: [docker-build]
allow_failure: true
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCHstages:
- build
- deploy
# Kubernetes deployment job
deploy-k8s:
stage: deploy
image: bitnami/kubectl:1.29
timeout: 10 minutes
before_script:
- kubectl config use-context $KUBE_CONTEXT
script:
- kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n $KUBE_NAMESPACE
- kubectl rollout status deployment/myapp -n $KUBE_NAMESPACE --timeout=5m
environment:
name: production
url: https://example.com
kubernetes:
namespace: production
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
resource_group: k8s-production
retry:
max: 2
when:
- runner_system_failure# Parent pipeline
stages:
- trigger
generate-child-pipeline:
stage: trigger
script:
- echo "Generating child pipeline config"
- |
cat > child-pipeline.yml <<EOF
stages:
- build
child-job:
stage: build
script:
- echo "Running child job"
EOF
artifacts:
paths:
- child-pipeline.yml
trigger-child:
stage: trigger
trigger:
include:
- artifact: child-pipeline.yml
job: generate-child-pipeline
strategy: depend
needs: [generate-child-pipeline]# Hidden template jobs (include timeout in templates)
.node-template:
image: node:20-alpine
timeout: 15 minutes # Default timeout for jobs using this template
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
before_script:
- npm ci
interruptible: true
.deploy-template:
timeout: 10 minutes # Deploy jobs should have explicit timeout
before_script:
- echo "Deploying to ${ENVIRONMENT}"
after_script:
- echo "Deployment complete"
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
interruptible: false # Deploys should not be interrupted
# Actual jobs using templates
build:
extends: .node-template
stage: build
script:
- npm run build
deploy-staging:
extends: .deploy-template
stage: deploy
variables:
ENVIRONMENT: staging
script:
- ./deploy.sh staging
resource_group: staging# Include GitLab's security templates (use Jobs/ prefix for current templates)
include:
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
# Customize SAST behavior via global variables
# Note: Set variables globally rather than overriding template jobs
# to avoid validation issues with partial job definitions
variables:
SAST_EXCLUDED_PATHS: "spec, test, tests, tmp, node_modules"
DS_EXCLUDED_PATHS: "node_modules, vendor"
SECURE_LOG_LEVEL: "info"stages:
- build
- test
- deploy
build-frontend:
stage: build
script: npm run build:frontend
build-backend:
stage: build
script: npm run build:backend
test-frontend:
stage: test
needs: [build-frontend]
script: npm test:frontend
test-backend:
stage: test
needs: [build-backend]
script: npm test:backend
deploy:
stage: deploy
needs: [test-frontend, test-backend]
script: make deploydeploy-staging:
script: deploy staging
rules:
- if: $CI_COMMIT_BRANCH == "develop"
when: always
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: manual
deploy-production:
script: deploy production
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
- when: nevertest:
parallel:
matrix:
- NODE_VERSION: ['18', '20', '22']
OS: ['ubuntu', 'alpine']
image: node:${NODE_VERSION}-${OS}
script:
- npm test