gitlab-ci-kiro-pipelinelisted

Build, extend, or debug GitLab CI/CD pipelines (.gitlab-ci.yml) that run Kiro CLI in headless mode for AI-powered merge-request review, security scanning, test-failure analysis, config-drift detection, code-duplication sync checks, and change-impact/risk analysis — including integrating the customer's MCP servers (SonarQube SAST, Jira, internal tools) into CI jobs. Use this skill whenever the user mentions GitLab CI, .gitlab-ci.yml, GitLab pipelines, merge-request automation, AI code review in CI, Kiro CLI in CI/CD, kiro-cli headless or non-interactive mode, MCP servers in pipelines, or wants agentic/LLM checks in a pipeline — even if they don't say "Kiro" or "GitLab CI" explicitly (e.g. "add an AI reviewer to my MRs", "hook SonarQube into the AI review", "make the pipeline catch config drift").
timwukp/agent-skills-best-practice · ★ 11 · Code & Development · score 80

Install: claude install-skill timwukp/agent-skills-best-practice

# GitLab CI/CD Pipelines with Kiro CLI Headless Mode Build `.gitlab-ci.yml` pipelines where Kiro CLI acts as an AI reviewer/analyst on merge requests. The pattern: each job installs Kiro CLI in a throwaway container, gathers context (the MR diff, config files, failure logs), and runs `kiro-cli chat --no-interactive` with a role-scoped prompt. Output goes to the job log and optionally gates the merge. ## Workflow 1. **Understand the repo and goals.** Ask (or infer from the repo) which checks the user wants: advisory review only, or merge-blocking gates? Which languages/config layouts exist? Is there an existing `.gitlab-ci.yml` to extend? 2. **Pick jobs from the recipe catalog.** Read `references/job-recipes.md` for nine proven job patterns (code review, PII/secrets scan, test-failure analysis, diff issue detection, build-failure remediation, config drift, cross-repo config validation, duplication sync check, change-impact analysis). Copy only the ones the user needs. 3. **Start from the template.** `assets/gitlab-ci-template.yml` is a complete, working pipeline skeleton. Adapt stages and jobs rather than writing from scratch. 4. **Decide advisory vs. gating per job** (see below) and set `allow_failure` accordingly. 5. **Verify prerequisites with the user**: the `KIRO_API_KEY` CI/CD variable must be set (masked, protected) in GitLab → Settings → CI/CD → Variables, and confirm your runners have internet access to `https://cli.kiro.dev/install`. If your GitLab Runner sandbox