# CI CD Pilot

> Diseña y optimiza pipelines de CI/CD para GitHub Actions y GitLab CI, incluyendo automatización de tests, linting, builds y deploys.

- Skill: `leandrobenjaminl/ci-cd-pilot` (Agent Skill)
- Install (CLI): `npx skillmds@latest add leandrobenjaminl/ci-cd-pilot`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leandrobenjaminl/ci-cd-pilot/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra, CI/CD
- Tags: Build, Caching, Deployment, Github Actions, Gitlab Ci, Linting, Secrets, Testing
- License: MIT
- Author: LeandroBenjaminL (https://skillmd.com/u/leandrobenjaminl)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/leandrobenjaminl/ci-cd-pilot

---


# Skill: ci-cd-pilot

Pipelines que no se rompen los viernes a las 18.

## Trigger

- Querés que los tests corran solos en cada PR
- Necesitás automatizar el deploy a staging/prod
- Hay que configurar linting + type checking en CI
- Un pipeline existente tarda 20 minutos y hay que optimizarlo
- Vas a mergear y querés que pase por controles automáticos

## Workflow LEND

```
1. ANALIZAR
   ├── Stack: Python (ruff, pytest), Node (eslint, vitest), Go (golangci-lint)
   ├── ¿Hay tests? ¿Hay linter? ¿Hay type checker?
   ├── ¿Dónde deploya? (Railway, Vercel, AWS, Docker Hub)
   └── ¿Ambientes? (dev, staging, prod)

2. OFRECER (Menú del Senior)
   ├── A) Scout: lint + type check + build. Rápido, mínimo.
   ├── B) Guardian: lint + tests + build + security scan. No mergea si falla.
   └── C) Ironclad: todo + auto-deploy + notificaciones + matrix builds

3. ELEGIR → el usuario confirma

4. HACER
   ├── .github/workflows/main.yml o .gitlab-ci.yml
   ├── Secrets bien configurados (nunca hardcodeados)
   ├── Dependency caching (pip cache, npm cache, go mod cache)
   ├── Matrix builds si aplica (3.10, 3.11, 3.12)
   └── Documentación en inglés técnico del pipeline

5. VERIFICAR
   ├── El workflow corre sin errores
   ├── Los secrets están configurados en GitHub/GitLab
   └── El caché funciona (segundo run es más rápido)
```

## Patrones

- **Caching**: siempre cachear dependencias entre runs
- **Secrets**: usar GitHub Secrets / GitLab CI variables, nunca en el yaml
- **Fail fast**: primero lint, después tests, después build
- **Matrix**: testear contra 2-3 versiones del runtime
- **Trigger condicional**: CI en PRs y push a main; CD solo en tags o main
- **Notificaciones**: solo fallos, no saturar con éxitos

## Anti-patrones

- Hardcodear API keys o tokens en el workflow yaml
- CI que tira warning pero pasa igual (poné `--error-on-warning`)
- Deploy automático sin pasar por PR
- Un solo workflow de 500 líneas — partí en workflows reusables
- Cachear sin key — la cache se vuelve obsoleta