gitlab-ci-quality-gateslisted

Wires Cinetic's reusable GitLab CI/CD Components (gitlab.com/educlopezcinetic/ci-templates — lint, typecheck, test, semantic MR titles, agent guardrails, secret scanning, dependency audits) into a project's .gitlab-ci.yml, adds the stack's static-analysis job (PHPStan for PrestaShop, Larastan for Laravel — not yet a ci-templates component, wired repo-local), and configures branch protection + merge checks to match how the project is actually worked. Use when the user asks to "set up CI quality gates", "montar CI en este proyecto", "añadir ci-templates", wants PHPStan/Larastan added, or wants MR-based branch protection on a GitLab project. Covers PrestaShop, Laravel, Astro, and Next.js — add a new reference file the same shape when another stack needs this, don't build ahead of need. Distinct from gitlab-security-setup (scheduled Trivy/pnpm supply-chain email report) and ps-security-audit — this is about MR-time quality/security GATES, not scheduled reports. Do NOT use for GitHub-hosted projects.
educlopez/mallard · ★ 3 · Code & Development · score 72

Install: claude install-skill educlopez/mallard

# GitLab CI Quality Gates (ci-templates) Wires the already-built, versioned components from [`educlopezcinetic/ci-templates`](https://gitlab.com/educlopezcinetic/ci-templates) into a project, plus the one piece that repo doesn't cover yet (PHP static analysis), and sets branch protection to match how the project is really worked. Validated end-to-end against `educlopezcinetic/prestashop-demo` and `laravel-demo` (real deliberate-failure smoke tests for every gate, not just "pipeline ran"). The stack-specific include blocks and static-analysis job live in `references/` — this file is the shared decision tree and gotchas, identical regardless of stack. Load the matching reference file for Step 1 and Step 2: - `references/prestashop.md` - `references/laravel.md` - `references/astro.md` - `references/nextjs.md` - (No other stack references exist yet — add one following the same shape when a new stack actually needs this, don't build ahead of need.) ## Step 0 — ask, don't assume: blocking or informational? This is the one decision that changes everything else. Ask the user: > "¿Este proyecto lo trabajás solo con hábito de PR, o el equipo mergea ramas > directo a `test` sin MR?" - **Solo / personal workflow, real PR habit** → gates are **blocking**. Enable `only_allow_merge_if_pipeline_succeeds`, protect `test`/`main` with push access "No one" (merge via MR only). This is the Eduardo-personal-project case — see Step 3. - **Team client project** (coworkers merge branch