/gitlab-ci-generator
Create, generate, or scaffold .gitlab-ci.yml pipelines, stages, and jobs.
$ npx -y skills add akin-ozer/cc-devops-skills --skill gitlab-ci-generator --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/gitlab-ci-generator
Context preview
The summary Claude sees to decide when to auto-load this skill.
Create, generate, or scaffold .gitlab-ci.yml pipelines, stages, and jobs.
SKILL.md
gitlab-ci-generator.SKILL.mdname: gitlab-ci-generator
description: Create, generate, or scaffold .gitlab-ci.yml pipelines, stages, and jobs.
GitLab CI/CD Pipeline Generator
Overview
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.
---
Trigger Phrases
Use this skill when the user asks for GitLab CI/CD generation requests such as:
- "Create a `.gitlab-ci.yml` for..."
- "Build a GitLab pipeline for Node/Python/Java..."
- "Add Docker build and deploy jobs in GitLab CI"
- "Set up GitLab parent-child or multi-project pipelines"
- "Include SAST/dependency scanning templates in GitLab CI"
Execution Model
Follow this deterministic flow in order: 1. Classify request complexity (`targeted`, `lightweight`, or `full`). 2. Load only the required reference tier for that complexity. 3. Output the matching response profile for the selected mode. 4. For complete pipeline generation, start from the closest template and customize. 5. Validate complete pipelines with strict Critical/High gates. 6. Present output with validation status and template/version notes.
If tooling is unavailable, use the documented fallback branch and report it explicitly.
Mode Routing (Quick Decision)
| 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.
MANDATORY PRE-GENERATION STEPS
**CRITICAL:** Before generating any complete GitLab CI/CD pipeline, complete these steps.
Step 1: Classify Complexity (REQUIRED)
| 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.
Step 2: Load References by Tier (REQUIRED)
Use an open/read action to load references based on the selected mode.
**Targeted mode (review/Q&A/snippet/focused fix):**
- Load only directly relevant references/templates for the scoped request.
- Do not enforce Full-generation Tier 1/Tier 2 checklist items.
**Tier 1 (Required for complete pipeline generation in Lightweight and Full modes):** 1. `references/best-practices.md` - baseline security, performance, naming 2. `references/common-patterns.md` - starting pattern selection 3. Matching template from `assets/templates/`:
- Docker pipelines -> `assets/templates/docker-build.yml`
- Kubernetes deployments -> `assets/templates/kubernetes-deploy.yml`
- Multi-project pipelines -> `assets/templates/multi-project.yml`
- Basic pipelines -> `assets/templates/basic-pipeline.yml`
**Tier 2 (Required for Full mode; optional for Lightweight mode):** 1. `references/gitlab-ci-reference.md` - keyword/syntax edge cases 2. `references/security-guidelines.md` - security-sensitive controls
**Tier 3 (Conditional external docs lookup):**
- Use only when local references do not cover requested features or version-specific behavior.
- Follow the lookup flow in "Handling GitLab CI/CD Documentation Lookup."
**If a required local reference or template is unavailable:**
- Report the exact missing path.
- Continue with available references and mark assumptions explicitly.
- Do not claim production-ready confidence until missing critical inputs are resolved.
Step 3: Confirm Understanding (EXPLICIT OUTPUT REQUIRED)
Lightweight Confirmation Mode
Use for simple requests only.
**Required format:**
## Reference Analysis Complete (Lightweight)
**Pattern:** [Pattern name] from common-patterns.md
**Template:** [Template file]
**Key standards to enforce:**
- [2-3 concrete standards]
**Example:**
## 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`
Full Confirmation Mode
Use for complex or security-sensitive requests.
**Required format:**
## 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]
**Example:**
## Reference Analysis Complete (Full)
**Pipeline Pattern Identified:** Docker Build + Kubernetes Deployment from common-patterns.md
- User needs containerized deployment to K8s clusters with staging/
Read more
name: gitlab-ci-generator description: Create, generate, or scaffold .gitlab-ci.yml pipelines, stages, and jobs.
GitLab CI/CD Pipeline Generator
Overview
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.
---
Trigger Phrases
Use this skill when the user asks for GitLab CI/CD generation requests such as:
- "Create a `.gitlab-ci.yml` for..."
- "Build a GitLab pipeline for Node/Python/Java..."
- "Add Docker build and deploy jobs in GitLab CI"
- "Set up GitLab parent-child or multi-project pipelines"
- "Include SAST/dependency scanning templates in GitLab CI"
Execution Model
Follow this deterministic flow in order: 1. Classify request complexity (`targeted`, `lightweight`, or `full`). 2. Load only the required reference tier for that complexity. 3. Output the matching response profile for the selected mode. 4. For complete pipeline generation, start from the closest template and customize. 5. Validate complete pipelines with strict Critical/High gates. 6. Present output with validation status and template/version notes.
If tooling is unavailable, use the documented fallback branch and report it explicitly.
Mode Routing (Quick Decision)
| 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.
MANDATORY PRE-GENERATION STEPS
**CRITICAL:** Before generating any complete GitLab CI/CD pipeline, complete these steps.
Step 1: Classify Complexity (REQUIRED)
| 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.
Step 2: Load References by Tier (REQUIRED)
Use an open/read action to load references based on the selected mode.
**Targeted mode (review/Q&A/snippet/focused fix):**
- Load only directly relevant references/templates for the scoped request.
- Do not enforce Full-generation Tier 1/Tier 2 checklist items.
**Tier 1 (Required for complete pipeline generation in Lightweight and Full modes):** 1. `references/best-practices.md` - baseline security, performance, naming 2. `references/common-patterns.md` - starting pattern selection 3. Matching template from `assets/templates/`:
- Docker pipelines -> `assets/templates/docker-build.yml`
- Kubernetes deployments -> `assets/templates/kubernetes-deploy.yml`
- Multi-project pipelines -> `assets/templates/multi-project.yml`
- Basic pipelines -> `assets/templates/basic-pipeline.yml`
**Tier 2 (Required for Full mode; optional for Lightweight mode):** 1. `references/gitlab-ci-reference.md` - keyword/syntax edge cases 2. `references/security-guidelines.md` - security-sensitive controls
**Tier 3 (Conditional external docs lookup):**
- Use only when local references do not cover requested features or version-specific behavior.
- Follow the lookup flow in "Handling GitLab CI/CD Documentation Lookup."
**If a required local reference or template is unavailable:**
- Report the exact missing path.
- Continue with available references and mark assumptions explicitly.
- Do not claim production-ready confidence until missing critical inputs are resolved.
Step 3: Confirm Understanding (EXPLICIT OUTPUT REQUIRED)
Lightweight Confirmation Mode
Use for simple requests only.
**Required format:**
## Reference Analysis Complete (Lightweight) **Pattern:** [Pattern name] from common-patterns.md **Template:** [Template file] **Key standards to enforce:** - [2-3 concrete standards]
**Example:**
## 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`
Full Confirmation Mode
Use for complex or security-sensitive requests.
**Required format:**
## 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]
**Example:**
## Reference Analysis Complete (Full) **Pipeline Pattern Identified:** Docker Build + Kubernetes Deployment from common-patterns.md - User needs containerized deployment to K8s clusters with staging/
A practical skill pack for DevOps work in Claude Code and Codex desktop. This repository ships 31 skills: 16 generators for scaffolding production-ready configs 14 validators for linting, security checks, and dry-run validation 1 debugger (k8s-debug) for
Repo: akin-ozer/cc-devops-skills
Other skills on cc-devops-skills.
- /ansible-generator
Generate, create, or scaffold Ansible playbooks, roles, tasks, handlers, inventory, vars.
Open skill - /ansible-validator
Validate, lint, audit, or debug Ansible playbooks, roles, inventories, FQCN, tasks.
Open skill - /azure-pipelines-generator
Generate/create/scaffold azure-pipelines.yml, stages, jobs, steps, or reusable templates.
Open skill - /azure-pipelines-validator
Validate, lint, audit, or review azure-pipelines.yml — syntax, security, best practices.
Open skill - /bash-script-generator
Create, generate, write, or scaffold bash/shell scripts (.sh), automation, or CLI tools.
Open skill - /bash-script-validator
Validate, lint, audit, or fix bash/shell/.sh scripts via ShellCheck.
Open skill

