/dockerize
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
$ npx -y skills add 686f6c61/alfred-dev --skill dockerize --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.
- You can call itInvoke it directly when you want it.
- Slash command
/dockerize
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
SKILL.md
dockerize.SKILL.mdname: dockerize
description: "Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage."
Generar Dockerfile optimizado
Resumen
Este skill genera un Dockerfile siguiendo las mejores prácticas de la industria: multi-stage builds para reducir el tamaño de la imagen final, ejecución con usuario no-root para seguridad, capas optimizadas para aprovechar la caché y health checks para la orquestación.
Un buen Dockerfile no es solo "que funcione", sino que sea seguro, rápido de construir, pequeño y mantenible.
Proceso
1. **Detectar el stack del proyecto.** Consultar el stack detectado en la configuración de Alfred para seleccionar la imagen base adecuada. Identificar el lenguaje, framework y runtime necesarios:
- Node.js: `node:XX-alpine` o `node:XX-slim`.
- Python: `python:XX-slim` o `python:XX-alpine`.
- Rust: multi-stage con `rust:XX` para build y `debian:XX-slim` o `gcr.io/distroless` para runtime.
- Go: multi-stage con `golang:XX` para build y `scratch` o `gcr.io/distroless` para runtime.
2. **Diseñar multi-stage build.** Separar la fase de construcción de la de ejecución:
# Fase de build: incluye herramientas de compilación
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
# Fase de runtime: solo lo necesario para ejecutar
FROM node:20-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
3. **Optimizar el orden de capas para caché.** Las capas que cambian menos van primero:
- Primero: ficheros de dependencias (package.json, requirements.txt, Cargo.toml).
- Segundo: instalación de dependencias.
- Tercero: copia del código fuente.
- Cuarto: build.
Esto asegura que un cambio en el código no invalida la caché de dependencias.
4. **Configurar usuario no-root.** Nunca ejecutar la aplicación como root dentro del contenedor:
RUN addgroup --system app && adduser --system --ingroup app app
USER app
5. **Añadir health check.** Permitir al orquestador (Docker Compose, Kubernetes) verificar que la aplicación está sana:
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
CMD curl -f http://localhost:3000/health || exit 16. **Generar .dockerignore.** Excluir todo lo que no es necesario en la imagen:
node_modules
.git
.env
*.md
tests/
.github/
7. **Configurar variables de entorno.** Usar `ENV` para valores por defecto y documentar qué variables se deben pasar en runtime con `ARG` o `-e`.
8. **Verificar la imagen resultante.** Comprobar el tamaño final, que no incluye herramientas de build innecesarias y que arranca correctamente.
Criterios de éxito
- El Dockerfile usa multi-stage build.
- La imagen base es mínima (alpine, slim o distroless).
- La aplicación se ejecuta con usuario no-root.
- Las capas están ordenadas para maximizar el uso de caché.
- Hay un health check configurado.
- Existe un .dockerignore que excluye ficheros innecesarios.
- La imagen final no incluye herramientas de build, tests ni código fuente innecesario.
Que NO hacer
- No usar `latest` como tag de imagen base. Siempre fijar la versión concreta (por ejemplo, `node:20.11-alpine`) para mejorar la reproducibilidad de los builds.
- No ejecutar la aplicación como root dentro del contenedor. Crear un usuario de sistema dedicado con los permisos mínimos necesarios.
- No copiar `node_modules` al contenedor desde el host. Instalar las dependencias dentro del contenedor para evitar incompatibilidades de plataforma y binarios nativos.
- No incluir secretos en la imagen (ficheros `.env`, claves privadas, tokens). Los secretos se pasan en runtime como variables de entorno o mediante sistemas de gestión de secretos.
Read more
name: dockerize description: "Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage."
Generar Dockerfile optimizado
Resumen
Este skill genera un Dockerfile siguiendo las mejores prácticas de la industria: multi-stage builds para reducir el tamaño de la imagen final, ejecución con usuario no-root para seguridad, capas optimizadas para aprovechar la caché y health checks para la orquestación.
Un buen Dockerfile no es solo "que funcione", sino que sea seguro, rápido de construir, pequeño y mantenible.
Proceso
1. **Detectar el stack del proyecto.** Consultar el stack detectado en la configuración de Alfred para seleccionar la imagen base adecuada. Identificar el lenguaje, framework y runtime necesarios:
- Node.js: `node:XX-alpine` o `node:XX-slim`.
- Python: `python:XX-slim` o `python:XX-alpine`.
- Rust: multi-stage con `rust:XX` para build y `debian:XX-slim` o `gcr.io/distroless` para runtime.
- Go: multi-stage con `golang:XX` para build y `scratch` o `gcr.io/distroless` para runtime.
2. **Diseñar multi-stage build.** Separar la fase de construcción de la de ejecución:
# Fase de build: incluye herramientas de compilación FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build # Fase de runtime: solo lo necesario para ejecutar FROM node:20-alpine AS runtime WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules
3. **Optimizar el orden de capas para caché.** Las capas que cambian menos van primero:
- Primero: ficheros de dependencias (package.json, requirements.txt, Cargo.toml).
- Segundo: instalación de dependencias.
- Tercero: copia del código fuente.
- Cuarto: build.
Esto asegura que un cambio en el código no invalida la caché de dependencias.
4. **Configurar usuario no-root.** Nunca ejecutar la aplicación como root dentro del contenedor:
RUN addgroup --system app && adduser --system --ingroup app app USER app
5. **Añadir health check.** Permitir al orquestador (Docker Compose, Kubernetes) verificar que la aplicación está sana:
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
CMD curl -f http://localhost:3000/health || exit 16. **Generar .dockerignore.** Excluir todo lo que no es necesario en la imagen:
node_modules .git .env *.md tests/ .github/
7. **Configurar variables de entorno.** Usar `ENV` para valores por defecto y documentar qué variables se deben pasar en runtime con `ARG` o `-e`.
8. **Verificar la imagen resultante.** Comprobar el tamaño final, que no incluye herramientas de build innecesarias y que arranca correctamente.
Criterios de éxito
- El Dockerfile usa multi-stage build.
- La imagen base es mínima (alpine, slim o distroless).
- La aplicación se ejecuta con usuario no-root.
- Las capas están ordenadas para maximizar el uso de caché.
- Hay un health check configurado.
- Existe un .dockerignore que excluye ficheros innecesarios.
- La imagen final no incluye herramientas de build, tests ni código fuente innecesario.
Que NO hacer
- No usar `latest` como tag de imagen base. Siempre fijar la versión concreta (por ejemplo, `node:20.11-alpine`) para mejorar la reproducibilidad de los builds.
- No ejecutar la aplicación como root dentro del contenedor. Crear un usuario de sistema dedicado con los permisos mínimos necesarios.
- No copiar `node_modules` al contenedor desde el host. Instalar las dependencias dentro del contenedor para evitar incompatibilidades de plataforma y binarios nativos.
- No incluir secretos en la imagen (ficheros `.env`, claves privadas, tokens). Los secretos se pasan en runtime como variables de entorno o mediante sistemas de gestión de secretos.
Plugin de Claude Code: 18 agentes especializados, 60 skills, 25 comandos, 13 hooks, memoria persistente, Memory UI local, quality gates, evidence guard, continuidad operativa y modo autopilot.
Repo: 686f6c61/alfred-dev
Other skills on alfred-dev.
- /alfred
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Open skill - /choose-stack
Usar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o
Open skill - /design-system
Usar para diseñar la arquitectura de un sistema con diagramas y contratos. Activar cuando el usuario quiera diseñar arquitectura, definir componentes del sistema, crear un diagrama de flujo, establecer contratos entre módulos, planificar la estructura del proyecto o decidir cómo
Open skill - /evaluate-dependencies
Usar para evaluar si una dependencia merece la pena antes de añadirla. Activar cuando el usuario quiera añadir una librería, saber si merece la pena esta dependencia, evaluar un paquete antes de instalarlo, hacer npm install o pip install de algo nuevo, buscar alternativas a una
Open skill - /write-adr
Usar para documentar decisiones arquitectónicas como ADR. Activar cuando el usuario quiera documentar por qué se tomó una decisión, registrar alternativas descartadas, crear un ADR, un decision record, dejar constancia de una elección técnica o justificar una decisión de diseño
Open skill - /code-review
Usar para revisar código con foco en calidad, legibilidad y errores lógicos. También: revisar código, buscar errores, calidad del código, revisión de PR, pull request review.
Open skill

