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: Example: Full Confirmation Mode Use for complex or security sensitive requests. Required format: Example: Skipping confirmation is not allowed for complete pipeline generation. Core Capabilities 1. Generate Basic CI/CD Pipelines Create complete, production ready .gitlab ci.yml files with proper structure, security best practices, and efficient CI/CD patterns. When to use: User requests: "Create a GitLab pipeline for...", "Build a CI/CD pipeline...", "Generate GitLab CI config..." Scenarios: CI/CD pipelines, automated testing, build automation, deployment pipelines Process: 1. Understand the user's requirements (what needs to be automated) 2. Identify stages, jobs, dependencies, and artifacts 3. Use assets/templates/basic pipeline.yml as structural foundation 4. Reference references/best practices.md for implementation patterns 5. Reference references/common patterns.md for standard pipeline patterns 6. Generate the pipeline following these principles: Use semantic stage and job names Pin Docker images to specific versions (not :latest) Implement proper secrets management with masked variables Use caching for dependencies to improve performance Implement proper artifact handling with expiration Use needs keyword for DAG optimization when appropriate Add proper error handling with retry and allow failure Use rules instead of deprecated only/except Set explicit timeout for all jobs (10 30 minutes typically) Add meaningful job descriptions in comments 7. ALWAYS validate the generated pipeline using the devops skills:gitlab ci validator skill 8. If validation fails, fix the issues and re validate Example structure: 2. Generate Docker Build Pipelines Create pipelines for building, testing, and pushing Docker images to container registries. When to use: User requests: "Create a Docker build pipeline...", "Build and push Docker images..." Scenarios: Container builds, multi stage Docker builds, registry pushes Process: 1. Understand the Docker build requirements (base images, registries, tags) 2. Use assets/templates/docker build.yml as foundation 3. Implement Docker in Docker or Kaniko for builds 4. Configure registry authentication 5. Implement image tagging strategy 6. Add security scanning if needed 7. ALWAYS validate using devops skills:gitlab ci validator skill Example: 3. Generate Kubernetes Deployment Pipelines Create pipelines that deploy applications to Kubernetes clusters. When to use: User requests: "Deploy to Kubernetes...", "Create K8s deployment pipeline..." Scenarios: Kubernetes deployments, Helm deployments, kubectl operations Process: 1. Identify the Kubernetes deployment method (kubectl, Helm, Kustomize) 2. Use assets/templates/kubernetes deploy.yml as foundation 3. Configure cluster authentication (service accounts, kubeconfig) 4. Implement proper environment management 5. Add rollback capabilities 6. ALWAYS validate using devops skills:gitlab ci validator skill Example: 4. Generate Multi Project Pipelines Create pipelines that trigger other projects or use parent child pipeline patterns. When to use: User requests: "Create multi project pipeline...", "Trigger other pipelines..." Scenarios: Monorepos, microservices, orchestration pipelines Process: 1. Identify the pipeline orchestration needs 2. Use assets/templates/multi project.yml or parent child templates 3. Configure proper artifact passing 4. Implement parallel execution where appropriate 5. ALWAYS validate using devops skills:gitlab ci validator skill Example (Parent Child): 5. Generate Template Based Configurations Create reusable templates using extends, YAML anchors, and includes. When to use: User requests: "Create reusable templates...", "Build modular pipeline config..." Scenarios: Template libraries, DRY configurations, shared CI/CD logic Process: 1. Identify common patterns to extract 2. Create hidden jobs (prefixed with .) 3. Use extends keyword for inheritance 4. Organize into separate files with include 5. ALWAYS validate using devops skills:gitlab ci validator skill Example: 6. Handling GitLab CI/CD Documentation Lookup Use this flow only when local references do not cover requested features or version sensitive behavior. Detection: User mentions specific GitLab features (e.g., "Auto DevOps", "SAST", "dependency scanning") User requests integration with GitLab templates Pipeline requires specific GitLab runner features Process: 1. Identify the feature: Extract the GitLab feature or template name Determine if version specific information is needed 2. Check local references first (Tier 1/Tier 2): references/common patterns.md references/gitlab ci reference.md references/security guidelines.md 3. Use Context7 first when external lookup is needed: Resolve library: mcp context7 resolve library id Query docs: mcp context7 query docs Prefer GitLab official/library docs over secondary sources 4. Fallback to web search when Context7 is unavailable or insufficient: Use web.search query Query pattern: "GitLab CI/CD [feature] documentation" Prefer results from docs.gitlab.com 5. Open and extract from specific docs pages when needed: Use web.open for selected documentation pages Capture required syntax, variables, and version constraints 6. Analyze discovered documentation for: Current recommended approach Required variables and configuration Template include syntax Best practices and security recommendations Example usage 7. If network tools are unavailable (offline/constrained environment): Continue using local references only State that external version verification could not be performed Add a version assumption note in the final output 8. Generate pipeline using discovered information: Use correct template include syntax Configure required variables Add security best practices Include comments about versions and choices Example with GitLab templates: Important: When using include with 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.yml file. Validation Workflow CRITICAL: Every generated GitLab CI/CD configuration MUST be validated before presenting to the user. Validation Process 1. Primary validation path: after generating a complete pipeline, invoke the devops skills:gitlab ci validator skill: 2. Script fallback path (if validator skill cannot be invoked): Set PIPELINE FILE to the exact generated file path (for example, pipelines/review.yml or .gitlab ci.yml ). Fail fast if that file does not exist: If the script is not executable: Optional API lint fallback when GitLab project context is available: 3. Manual fallback path (only if both primary and script paths are unavailable): Run manual checks for YAML validity, stage/job references, and obvious secret exposure. Mark output as Validation status: Manual fallback (not fully verifie

gitlab-ci-generator