DEV Community: carlosp5751258-lgtm

Formularios de issues en GitHub: deja de recibir reportes de error incompletos

carlosp5751258-lgtm — Wed, 28 Oct 2026 21:12:32 +0000

"No funciona." Sin versión, sin pasos, sin logs. Si mantienes un repositorio, conoces ese issue. La solución es que GitHub obligue a dar la información antes de enviar: los issue forms, formularios definidos en YAML que sustituyen al cuadro de texto libre.

Dónde van

Los formularios viven en .github/ISSUE_TEMPLATE/ de la rama por defecto, con extensión .yml. Cada archivo es una opción que aparece al pulsar New issue.

.github/
└── ISSUE_TEMPLATE/
    ├── bug_report.yml
    ├── feature_request.yml
    └── config.yml

Anatomía de un formulario

Un formulario necesita name, description y body. Opcionalmente, title (prefijo del título) y labels (etiquetas que se aplican solas). Este es el inicio de un reporte de error:

name: 🐛 Reporte de error
description: Algo no funciona como debería.
title: "[Error]: "
labels: ["bug", "por-clasificar"]
body:
  - type: textarea
    id: pasos
    attributes:
      label: Pasos para reproducirlo
      placeholder: |
        1. Ejecuta `...`
        2. Abre `...`
    validations:
      required: true
  - type: input
    id: version
    attributes:
      label: Versión
      placeholder: "1.4.2"
    validations:
      required: true

Los tipos de campo disponibles son cinco:

markdown: texto informativo que no se envía (ideal para instrucciones).
input: una línea (versión, URL).
textarea: varias líneas. Con render: shell el contenido se formatea como bloque de código, perfecto para logs.
dropdown: lista de opciones, con multiple: true si se pueden marcar varias.
checkboxes: casillas; cada una puede ser obligatoria.

validations.required: true impide enviar el formulario sin ese campo. Úsalo en lo imprescindible (pasos, versión, resultado esperado) y deja el resto opcional: un formulario demasiado largo hace que la gente abandone.

Cada id debe ser único dentro del formulario. Las etiquetas de labels deberían existir en el repositorio; créalas antes en Issues → Labels.

Un truco para logs

  - type: textarea
    id: logs
    attributes:
      label: Logs o mensajes de error
      description: Revisa que no incluya contraseñas ni tokens.
      render: shell

La advertencia sobre tokens no es decorativa: mucha gente pega su configuración completa sin pensarlo.

config.yml: ordena la entrada

Este archivo no es un formulario; controla la pantalla de selección:

blank_issues_enabled: false
contact_links:
  - name: ❓ Preguntas y ayuda
    url: https://github.com/USUARIO/REPO/discussions
    about: Para dudas de uso, abre una discusión en lugar de un issue.
  - name: 🔒 Reportar una vulnerabilidad
    url: https://github.com/USUARIO/REPO/security/advisories/new
    about: Reporta problemas de seguridad de forma privada.

Con blank_issues_enabled: false se oculta la opción de issue en blanco, y los contact_links desvían preguntas y vulnerabilidades a sus canales. El enlace de seguridad funciona si activas Private vulnerability reporting en Settings → Security.

Validar antes de hacer push

Un error de YAML hace que el formulario no aparezca, sin aviso claro. Revisa la sintaxis en local:

python3 -c "import yaml,sys; [yaml.safe_load(open(f)) for f in sys.argv[1:]]; print('OK')" .github/ISSUE_TEMPLATE/*.yml

Después del push, abre New issue en tu repo y prueba cada formulario. Si alguno falta, GitHub suele mostrar el error al abrir el archivo .yml en la interfaz web.

Con esto, tu próximo "No funciona" llegará con versión, pasos y logs.

¿Te sirvió? Este ejemplo es parte de las Plantillas de Documentación para GitHub en Español: paga lo que quieras, desde 2 USD. Más recursos gratis en GitHub.

Crea una skill de Claude Code para migraciones de base de datos sin sustos

carlosp5751258-lgtm — Wed, 28 Oct 2026 21:07:13 +0000

Pide a cualquier asistente "renombra la columna nombre a nombre_completo" y lo más probable es que genere un ALTER TABLE ... RENAME COLUMN. Funciona en tu máquina. En producción, el código que sigue desplegado busca nombre y empieza a fallar hasta que termine el despliegue.

En este tutorial vas a crear una skill de Claude Code que le enseña a hacer migraciones seguras por defecto.

Qué es una skill

Una skill es una carpeta con un archivo SKILL.md dentro de .claude/skills/ (en tu proyecto) o ~/.claude/skills/ (para todos tus proyectos). El archivo empieza con un frontmatter YAML:

---
name: migraciones-bd
description: "Crea y revisa migraciones de base de datos seguras para producción (sin bloqueos largos, sin pérdida de datos, reversibles y compatibles con el código desplegado). Úsala cuando el usuario pida crear una migración, cambiar el esquema, renombrar o borrar columnas, añadir índices o revisar una migración existente."
---

La description es la parte más importante: Claude Code la usa para decidir cuándo cargar la skill. Escríbela con las frases que de verdad usas ("renombra esta columna", "añade un índice"). Debajo del frontmatter va el método, en Markdown.

El método: expandir y contraer

La idea central es que, durante un despliegue, conviven la versión actual del código y la nueva, así que el esquema debe servir a las dos. En la skill lo expresamos como una tabla que Claude puede consultar:

| Operación | Forma segura |
|---|---|
| Añadir columna | Nullable o con default constante. Luego rellenar en lotes. Luego `NOT NULL` si hace falta |
| Renombrar columna | Añadir nueva → escribir en ambas → rellenar → leer de la nueva → (otro despliegue) borrar la vieja |
| Borrar columna | Primero dejar de usarla en el código y desplegar; después borrarla en otra migración |
| Añadir índice | PostgreSQL: `CREATE INDEX CONCURRENTLY` (fuera de transacción) |

Así, ante "renombra la columna", Claude propone un cambio en fases y el orden de despliegue.

Una checklist que obliga a pensar

Las instrucciones vagas ("ten cuidado con las migraciones") no cambian nada. Las preguntas concretas sí:

- [ ] ¿Bloquea la tabla mucho tiempo (reescritura, índice no concurrente, validación completa)?
- [ ] ¿Puede perder datos (`DROP`, truncar tipo, `NOT NULL` sin rellenar)?
- [ ] ¿El código actualmente en producción sigue funcionando tras aplicarla?
- [ ] ¿Tiene reversión y se ha probado `up` → `down` → `up` en local?

Pide también el SQL real que generará el ORM (alembic upgrade --sql, python manage.py sqlmigrate): muchos problemas solo se ven ahí.

Límites explícitos

Termina la skill con lo que nunca debe hacer sin tu permiso: ejecutar migraciones fuera de local, migrate:fresh, db:reset, prisma migrate reset o cualquier DROP. Una skill orienta a Claude, pero no es una barrera técnica: si quieres bloquear comandos de verdad, combínala con reglas deny en .claude/settings.json.

Pruébala

Guarda el archivo en .claude/skills/migraciones-bd/SKILL.md.
Abre una sesión nueva de Claude Code.
Pide: "Necesito renombrar usuarios.nombre a nombre_completo".

Si la skill se activó, verás un plan en fases, la migración de la primera fase, el SQL generado y el orden de despliegue, en lugar de un RENAME directo.

¿Te sirvió? Este ejemplo es parte del Pack 8 Skills Avanzadas para Claude Code (en español): paga lo que quieras, desde 3 USD. Más recursos gratis en GitHub.

Un CLAUDE.md que Claude Code sí respeta: ejemplo real con Terraform

carlosp5751258-lgtm — Wed, 28 Oct 2026 21:00:08 +0000

Claude Code lee el archivo CLAUDE.md de la raíz de tu repositorio al iniciar cada sesión. Es su memoria de proyecto: lo que escribas ahí lo tendrá presente sin que lo repitas. El problema es que la mayoría de los CLAUDE.md que veo son listas de buenas intenciones ("escribe código limpio", "sigue las buenas prácticas") que no cambian nada.

Vamos a escribir uno que sí funcione, con un caso donde equivocarse cuesta caro: infraestructura con Terraform.

1. Comandos exactos, no descripciones

Claude va a ejecutar comandos. Dale los que son seguros y dile exactamente cómo:

## Comandos (seguros, de solo lectura o locales)
- Formato: `terraform fmt -recursive`
- Validar: `terraform validate`
- Lint: `tflint --recursive`
- Plan: `terraform plan -out=tfplan` y revisar con `terraform show tfplan`

"Valida el código" es ambiguo. terraform validate no lo es. Si tu equipo usa OpenTofu, cámbialo por tofu: los comandos son iguales.

2. Convenciones que el modelo no puede adivinar

Claude ya sabe Terraform. Lo que no sabe es cómo lo usa tu equipo. Escribe solo eso, y añade el porqué cuando la regla no sea obvia:

- `for_each` con claves estables en lugar de `count` (con `count`, reordenar la lista recrea recursos).
- Para renombrar recursos usa bloques `moved {}` en vez de destruir y recrear.
- Variables sensibles con `sensitive = true`; secretos desde el gestor de secretos, nunca en `.tfvars`.

El motivo entre paréntesis importa: con él, Claude aplica la idea a casos que no listaste.

3. Un flujo con punto de parada

La clave en IaC es decir dónde termina el trabajo de Claude y empieza el tuyo:

## Flujo
1. Lee el módulo y el entorno afectados.
2. Haz el cambio mínimo.
3. `fmt` + `validate` + `tflint` + `plan`.
4. Resume el plan: qué se crea, cambia y **destruye**. La aplicación la hace una persona.

El paso 4 convierte un plan de 300 líneas en un resumen que puedes revisar en un minuto, y deja claro que el apply no le corresponde.

4. La sección "No hacer"

Es la más importante y la que casi todos olvidan:

## No hacer
- **Nunca** ejecutar `terraform apply`, `terraform destroy`, `-auto-approve`,
  `terraform state rm/mv` ni `terraform import` sin aprobación explícita.
- No editar el `.tfstate` a mano ni commitearlo.
- Sí commitear `.terraform.lock.hcl`.

Un detalle: CLAUDE.md guía el comportamiento, pero no es una barrera técnica. Para bloquear de verdad un comando, combínalo con reglas de permisos (deny) en .claude/settings.json o con un hook PreToolUse. Lo ideal es usar las dos capas.

5. Mantenlo corto y vivo

Apunta a 30-80 líneas: todo se carga en cada sesión.
Si corriges a Claude dos veces por lo mismo, esa corrección va al CLAUDE.md.
Usa /memory dentro de Claude Code para editarlo sin salir de la sesión.
En monorepos, pon un CLAUDE.md por paquete (infra/CLAUDE.md, api/CLAUDE.md): Claude lo lee cuando trabaja en esa carpeta.

Prueba rápida

Después de escribirlo, abre una sesión nueva y pide: "Añade un bucket S3 para logs en el entorno dev". Si Claude formatea, valida, genera el plan, te lo resume y se detiene sin aplicar, tu CLAUDE.md está funcionando.

¿Te sirvió? Este ejemplo es parte de las 15 Plantillas CLAUDE.md por Stack para Claude Code (en español): paga lo que quieras, desde 3 USD. Más recursos gratis en GitHub.

Dockerfile multi-stage para Go: de 800 MB a menos de 20 MB

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:52:01 +0000

Si tu Dockerfile de Go empieza con FROM golang y termina con CMD ["./app"], tu imagen probablemente pesa más de 800 MB: incluye el compilador, el código fuente y la caché de módulos. Nada de eso hace falta para ejecutar un binario. Con un build multi-stage compilamos en una imagen y copiamos solo el binario a otra mínima.

El Dockerfile

# syntax=docker/dockerfile:1
ARG GO_VERSION=1.24

FROM --platform=$BUILDPLATFORM golang:${GO_VERSION}-alpine AS build
WORKDIR /src

COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download

COPY . .

ARG TARGETOS
ARG TARGETARCH
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} \
    go build -trimpath -ldflags="-s -w" -o /out/app .

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /out/app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

Qué hace cada parte

Dos FROM = dos etapas. La primera (build) tiene Go completo. La segunda parte de una imagen casi vacía y solo recibe /out/app con COPY --from=build. Todo lo demás se descarta.

go.mod y go.sum antes que el código. Docker cachea cada instrucción. Si copias todo de una vez, cualquier cambio en un .go invalida la descarga de módulos. Separándolos, go mod download solo se repite cuando cambian tus dependencias.

RUN --mount=type=cache. Es una función de BuildKit (activado por defecto desde Docker 23). Monta una caché persistente durante el build sin guardarla en la imagen. La caché de compilación de Go (/root/.cache/go-build) hace que recompilar tras un cambio pequeño tarde segundos.

CGO_ENABLED=0. Genera un binario estático que no depende de la libc del sistema. Es lo que permite usar una imagen final sin libc.

-trimpath -ldflags="-s -w". -trimpath quita las rutas de tu máquina del binario y -s -w elimina la tabla de símbolos y la información de depuración. El binario queda notablemente más chico.

--platform=$BUILDPLATFORM + TARGETOS/TARGETARCH. Go compila de forma cruzada sin esfuerzo. Con esto, el compilador corre nativo en tu máquina y genera el binario para la arquitectura que pidas, sin emular con QEMU:

docker buildx build --platform linux/amd64,linux/arm64 -t mi-servicio .

distroless/static-debian12:nonroot. Una imagen de unos 2 MB que contiene certificados CA (para llamar APIs HTTPS), datos de zona horaria y un usuario sin privilegios. No tiene shell ni gestor de paquetes: si alguien compromete tu app, no tiene herramientas para moverse.

Un detalle importante

Como distroless no tiene shell, no puedes usar HEALTHCHECK CMD curl .... Define el healthcheck en Kubernetes o compose apuntando a tu endpoint, o haz que tu binario acepte un flag como -healthcheck y usa HEALTHCHECK CMD ["/app", "-healthcheck"].

Compruébalo

docker build -t mi-servicio .
docker images mi-servicio

Para un servicio HTTP típico verás una imagen de entre 10 y 25 MB. Menos tamaño significa despliegues más rápidos, menos costo de almacenamiento y menos superficie de ataque.

¿Te sirvió? Este ejemplo es parte del Pack Dockerfiles Optimizados: paga lo que quieras, desde 2 USD. Más recursos gratis en GitHub.

Valida Conventional Commits con un hook de git en bash (sin instalar nada)

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:48:56 +0000

Un historial con mensajes como "cambios", "arreglos" o "ahora sí" no sirve para nada cuando necesitas encontrar qué commit rompió producción. La convención Conventional Commits resuelve esto con un formato simple:

tipo(alcance opcional): descripción

Por ejemplo: feat(auth): agregar login con Google o fix: corregir cálculo de impuestos. Además de ordenar el historial, permite generar changelogs y versiones semánticas de forma automática.

La forma más directa de exigirlo es un hook commit-msg: un script que git ejecuta justo después de que escribes el mensaje y que puede rechazar el commit. Lo vamos a hacer en bash puro, sin Node ni Python.

1. El hook

Crea una carpeta .githooks/ en tu repo y dentro un archivo commit-msg:

#!/usr/bin/env bash
set -euo pipefail

TIPOS="feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert"
MAX_LARGO=72

# Git pasa como $1 la ruta del archivo con el mensaje.
encabezado="$(grep -v '^#' "$1" | sed '/^[[:space:]]*$/d' | head -n 1 || true)"

# Deja pasar los mensajes que genera git (merge, fixup...).
if [[ "$encabezado" =~ ^(Merge|Revert\ \"|fixup!|squash!) ]]; then
  exit 0
fi

patron="^(${TIPOS})(\([a-z0-9._/-]+\))?!?: [^[:space:]].*$"
if [[ ! "$encabezado" =~ $patron ]]; then
  echo "✖ Formato esperado: tipo(alcance): descripción" >&2
  echo "  Tipos: ${TIPOS//|/, }" >&2
  exit 1
fi

if (( ${#encabezado} > MAX_LARGO )); then
  echo "✖ Encabezado de ${#encabezado} caracteres (máx. ${MAX_LARGO})." >&2
  exit 1
fi

2. Cómo funciona

$1: git no te pasa el mensaje, sino la ruta a un archivo temporal que lo contiene. Por eso leemos el archivo.
grep -v '^#': cuando usas el editor, git agrega líneas de ayuda que empiezan con #. Las quitamos, junto con las líneas vacías, y nos quedamos con la primera: el encabezado.
El patrón: ($[a-z0-9._/-]+$)? hace opcional el alcance, !? permite marcar cambios incompatibles (feat!: ...) y : [^[:space:]] exige un espacio después de los dos puntos y una descripción real.
=~ sin comillas en el patrón: en bash, si pones comillas a la derecha de =~, se compara como texto literal y no como expresión regular. Por eso el patrón vive en una variable.
Código de salida: si el hook termina con algo distinto de 0, git cancela el commit.

3. Activarlo para todo el equipo

En lugar de copiar el script a .git/hooks/ (que no se versiona), dile a git que use tu carpeta:

chmod +x .githooks/commit-msg
git config core.hooksPath .githooks
git add .githooks && git commit -m "chore: agregar hook commit-msg"

Cada persona del equipo solo ejecuta git config core.hooksPath .githooks una vez después de clonar.

4. Probarlo

git commit --allow-empty -m "cambios varios"        # rechazado
git commit --allow-empty -m "feat: agregar buscador" # aceptado

Si alguna vez necesitas saltarlo, existe git commit --no-verify, pero úsalo con moderación: el hook está ahí para cuidarte.

¿Te sirvió? Este ejemplo es parte del Pack Git Hooks y Pre-commit: paga lo que quieras, desde 2 USD. Más recursos gratis en GitHub.

Tu primer CI en GitHub Actions con matriz de versiones (explicado en español)

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:44:42 +0000

Si tu proyecto no tiene integración continua, cada push es una apuesta: "en mi máquina funciona". Con GitHub Actions puedes ejecutar tu linter y tus tests automáticamente en cada push y en cada pull request, gratis en repositorios públicos. En este tutorial armamos un workflow para Node.js que prueba tu código en dos versiones de Node a la vez, y explico cada línea para que lo adaptes a cualquier lenguaje.

1. Dónde va el archivo

GitHub busca workflows en .github/workflows/ dentro de tu repositorio. Cualquier archivo .yml ahí se convierte en un workflow. Crea .github/workflows/node-ci.yml.

2. El workflow completo

name: Node.js CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    strategy:
      fail-fast: false
      matrix:
        node-version: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test

3. Qué hace cada parte

on: define cuándo se ejecuta. Aquí, en cada push a main y en cada PR dirigido a main. Si tu rama principal se llama master, cámbialo.

concurrency: si haces tres push seguidos a un PR, no tiene sentido terminar las dos primeras ejecuciones. Esta sección agrupa las ejecuciones por workflow y rama, y cancela las viejas. Ahorras minutos y obtienes feedback más rápido.

permissions: por defecto, el token del workflow puede tener permisos de escritura. Un CI solo necesita leer el código, así que lo limitamos a contents: read. Si alguna dependencia maliciosa intenta usar el token, no podrá modificar tu repo.

strategy.matrix: el truco más útil. GitHub crea un job por cada valor de la matriz, en paralelo. Con [20, 22] pruebas en ambas versiones LTS sin duplicar código. fail-fast: false evita que, si falla Node 20, se cancele Node 22: quieres ver ambos resultados para saber si el problema depende de la versión.

timeout-minutes: el límite por defecto es de 6 horas. Un test colgado puede consumir tus minutos gratuitos. 15 minutos es un tope razonable para la mayoría de los proyectos.

cache: npm: setup-node guarda la caché de npm usando el hash de tu package-lock.json como clave. Si el lockfile no cambia, la instalación es mucho más rápida.

npm ci en lugar de npm install: npm ci instala exactamente lo que dice el lockfile y falla si no coincide con package.json. Es reproducible, que es justo lo que quieres en CI.

4. Siguiente paso: protege tu rama

Una vez que el workflow pase, ve a Settings > Branches (o Rules) y exige que los checks pasen antes de hacer merge. A partir de ahí, nadie (ni tú con prisa un viernes) podrá fusionar código que rompe los tests.

El mismo patrón sirve para Python (setup-python o setup-uv con matriz ["3.11", "3.12", "3.13"], ¡entre comillas!) o Go (setup-go con go-version-file: go.mod).

¿Te sirvió? Este ejemplo es parte del Pack GitHub Actions CI en Español: paga lo que quieras, desde 2 USD. Más recursos gratis en GitHub.

Cómo borrar ramas de git ya fusionadas sin miedo (script Bash con dry-run)

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:41:05 +0000

Si llevas unos meses en un proyecto, seguramente git branch te devuelve una lista eterna: fix-login, feature/pagos, prueba-2... La mayoría ya se fusionaron hace tiempo, pero nadie se atreve a borrarlas por miedo a perder trabajo. En este tutorial vamos a construir un script pequeño que las limpia de forma segura.

La idea clave: `--merged`

Git ya sabe qué ramas están fusionadas. Una rama está "fusionada" en main cuando su último commit es alcanzable desde main, es decir, borrarla no hace que se pierda ningún commit.

git branch --merged main

Ese comando funciona, pero su salida está pensada para humanos (marca la rama actual con * y añade espacios). Para scripts es mejor git for-each-ref, que permite elegir el formato exacto:

git for-each-ref --merged=main --format='%(refname:short)' refs/heads/

Ahora tenemos un nombre por línea, sin adornos.

Proteger las ramas importantes

Nunca queremos borrar main, develop ni la rama en la que estamos. Un truco limpio en Bash es rodear la lista con espacios y comparar con un patrón:

#!/usr/bin/env bash
set -euo pipefail

BASE="main"
PROTEGIDAS="main master develop staging production"
actual="$(git symbolic-ref --short -q HEAD || true)"

es_protegida() {
  [[ "$1" == "$BASE" || "$1" == "$actual" || " $PROTEGIDAS " == *" $1 "* ]]
}

locales=()
while IFS= read -r rama; do
  es_protegida "$rama" || locales+=("$rama")
done < <(git for-each-ref --merged="$BASE" --format='%(refname:short)' refs/heads/)

echo "Ramas fusionadas en $BASE (${#locales[@]}):"
if [[ ${#locales[@]} -gt 0 ]]; then printf '  %s\n' "${locales[@]}"; fi

Algunos detalles que vale la pena entender:

set -euo pipefail hace que el script se detenga ante errores, variables sin definir o fallos dentro de una tubería.
|| true en symbolic-ref evita que el script muera si estás en "HEAD separado".
< <(...) (sustitución de procesos) permite que el array locales siga existiendo después del bucle; con una tubería | while se perdería, porque el bucle correría en un subshell.

Borrar, pero con red de seguridad

El último paso es borrar. Hay dos decisiones importantes:

Dry-run por defecto: el script solo lista. Para borrar hay que pasar --ejecutar y además confirmar.
Usar git branch -d, no -D: la -d minúscula se niega a borrar una rama que no esté fusionada. Aunque nuestra lógica fallara, git nos frena.

read -r -p "¿Borrar estas ramas? [s/N] " resp || resp=""
[[ "$resp" =~ ^[sS]$ ]] || { echo "Cancelado."; exit 0; }
for rama in "${locales[@]}"; do
  git branch -d -- "$rama"
done

El -- antes del nombre indica a git que lo que sigue no es una opción, por si alguna rama tuviera un nombre raro que empiece con guion.

Un aviso sobre squash y rebase

Si tu equipo fusiona los pull requests con "Squash and merge" o "Rebase and merge" en GitHub, los commits originales de la rama no llegan a main, así que git no las detecta como fusionadas. Esas ramas tendrás que revisarlas a mano (o con git cherry). No es un fallo del script: es la forma en que funcionan esos tipos de merge.

Con estas pocas líneas puedes pasar de 40 ramas a 5 en un minuto, sin el miedo de perder trabajo.

¿Te sirvió? Este script es parte del Pack 12 Scripts Bash para Desarrolladores (Linux): paga lo que quieras, desde 2 USD. Más recursos gratis en GitHub.

Cómo pedirle a la IA que depure tu código (sin que adivine)

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:37:17 +0000

Si alguna vez pegaste un error en un asistente de IA y recibiste un "prueba esto" que no funcionó, seguido de otro "prueba esto otro", ya conoces el problema: el modelo salta directo a la solución sin entender la causa. El resultado es un ciclo de parches al azar.

La buena noticia es que se arregla casi siempre con la forma en que pides las cosas. En este artículo te muestro dos prompts que uso para depurar y por qué funcionan.

El error más común: pedir el arreglo primero

Un prompt como "arregla este error: TypeError..." invita al modelo a adivinar. No sabe tu versión del lenguaje, ni qué esperabas, ni qué ya intentaste. Y como le pediste un arreglo, te dará uno, aunque no tenga suficiente información.

La alternativa es separar diagnóstico de solución y obligar a que el razonamiento ocurra antes del código.

Prompt 1: diagnóstico a partir del stack trace

Actúa como desarrollador senior de [LENGUAJE]. Te paso un error y su stack trace:
[ERROR_Y_STACK_TRACE]
Y el código relevante:
[CÓDIGO]
Explica en orden: 1) qué significa el error, 2) la línea exacta donde se origina
y por qué, 3) las 3 causas más probables ordenadas por probabilidad, 4) cómo
confirmar cada una con un experimento mínimo. No propongas el arreglo hasta
haber razonado la causa.

Fíjate en tres detalles:

Pide hipótesis ordenadas, no una sola respuesta. Así ves el razonamiento y puedes descartar rápido lo que no aplica a tu caso.
Pide un experimento por hipótesis. Un print, un assert o un test mínimo te dan evidencia real en lugar de confianza ciega.
Prohíbe el arreglo prematuro. Esa última frase cambia mucho la calidad de la respuesta.

Reemplaza los marcadores con información completa: el stack trace entero (no solo la última línea) y el código de las funciones que aparecen en la traza.

Prompt 2: cuando llevas horas atascado

A veces el problema no es el error, sino que ya perdiste el método. Para esos momentos:

Llevo [TIEMPO] atascado con este problema: [DESCRIPCIÓN]. Ya probé:
[LO_QUE_YA_PROBÉ]. No me des la solución directamente: ayúdame a construir un
plan de depuración con hipótesis numeradas, el experimento que confirma o
descarta cada una y el orden óptimo para ejecutarlos.

La clave está en [LO_QUE_YA_PROBÉ]. Si no lo incluyes, el asistente te recomendará exactamente lo que ya hiciste. Si lo incluyes, se ve obligado a buscar en otra dirección. Y pedir "el orden óptimo" hace que priorice primero los experimentos baratos.

Buenas prácticas que aplican a cualquier prompt de depuración

Incluye versiones: del lenguaje, del framework y del sistema operativo. Muchos bugs dependen de ellas.
Di qué esperabas y qué obtuviste. "No funciona" no es un síntoma.
Reduce el código al mínimo que reproduce el problema. Muchas veces encontrarás el bug tú mismo en ese proceso.
Nunca pegues secretos: tokens, contraseñas o variables de entorno reales. Reemplázalos por valores ficticios.
Verifica antes de confiar. Ejecuta el experimento propuesto; no aceptes una explicación solo porque suena convincente.

Con este enfoque, la IA deja de ser una máquina de parches y se convierte en un compañero que piensa contigo el problema.

¿Te sirvió? Estos dos prompts son parte de 100 Prompts para Programadores (en español): paga lo que quieras, desde 2 USD. Más recursos gratis en GitHub.

Hooks en Claude Code: bloquea comandos peligrosos con un script de 20 líneas

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:33:33 +0000

Si usas Claude Code a diario, seguramente tienes reglas en tu CLAUDE.md del tipo "nunca leas el .env" o "no hagas git push --force". El problema es que una instrucción en texto es una sugerencia: el modelo la sigue casi siempre, pero "casi" no basta cuando hablamos de secretos o de borrar carpetas.

Para eso existen los hooks: comandos de shell que Claude Code ejecuta automáticamente en momentos concretos. A diferencia de un prompt, un hook siempre se ejecuta.

Los cuatro eventos que más vas a usar

PreToolUse: antes de que Claude use una herramienta (Bash, Read, Edit...). Ideal para validar o bloquear.
PostToolUse: después de que la herramienta termina. Ideal para formatear o pasar el linter.
Notification: cuando Claude necesita tu atención.
Stop: cuando Claude termina de responder.

El hook recibe por entrada estándar un JSON con, entre otros campos, tool_name y tool_input. Y la regla clave: si el script sale con código 2, la acción se bloquea y lo que escribas en stderr le llega a Claude como explicación, para que busque otra alternativa.

El script

Guárdalo como .claude/hooks/proteger.py en tu proyecto:

#!/usr/bin/env python3
"""Bloquea comandos destructivos y el acceso a archivos de secretos."""
import json, re, sys

datos = json.load(sys.stdin)
herramienta = datos.get("tool_name", "")
entrada = datos.get("tool_input", {})

PELIGROSOS = [r"\brm\s+-[a-zA-Z]*r[a-zA-Z]*f", r"\bgit\s+push\s+.*--force",
              r"\bmkfs\b", r"\bdd\s+if=", r">\s*/dev/sd"]
if herramienta == "Bash":
    comando = entrada.get("command", "")
    for patron in PELIGROSOS:
        if re.search(patron, comando):
            print(f"Bloqueado por política: '{comando}'. Propón una alternativa "
                  "segura o pide al usuario que lo ejecute manualmente.", file=sys.stderr)
            sys.exit(2)

if herramienta in ("Read", "Edit", "Write"):
    ruta = entrada.get("file_path", "")
    if re.search(r"(^|/)\.env(\.|$)|/secrets/|\.pem$", ruta):
        print(f"Acceso denegado a archivo sensible: {ruta}", file=sys.stderr)
        sys.exit(2)

sys.exit(0)

Registrarlo

En .claude/settings.json (o de forma interactiva con /hooks):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Read|Edit|Write",
        "hooks": [
          { "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/proteger.py" }
        ]
      }
    ]
  }
}

matcher filtra por nombre de herramienta y $CLAUDE_PROJECT_DIR apunta a la raíz del proyecto, así que funciona aunque Claude cambie de carpeta.

Pruébalo sin abrir Claude

Como el hook solo lee JSON por stdin, puedes probarlo directamente en la terminal:

echo '{"tool_name":"Bash","tool_input":{"command":"rm -rf build"}}' \
  | python3 .claude/hooks/proteger.py; echo "salida=$?"
# Bloqueado por política: 'rm -rf build'. ...
# salida=2

Haz lo mismo con {"tool_name":"Read","tool_input":{"file_path":"/app/.env"}} y con un comando inocente como ls -la (este debe devolver 0).

Tres consejos

No es un sandbox. Un patrón puede esquivarse con un comando creativo. Combínalo con reglas deny en los permisos y, si quieres autonomía total, trabaja dentro de un contenedor.
Mantén los hooks rápidos. Se ejecutan en cada llamada a la herramienta.
Revisa los hooks de repos ajenos. Viajan con el proyecto y se ejecutan con tus permisos.

Si una regla de tu CLAUDE.md es crítica, conviértela en hook. Es la diferencia entre "por favor, no lo hagas" y "no puedes hacerlo".

¿Te sirvió? Este ejemplo es parte del Guía Claude Code de Cero a Experto (PDF en español): paga lo que quieras, desde 3 USD. Más recursos gratis en GitHub.

El CLAUDE.md perfecto para proyectos Python (plantilla lista para copiar)

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:15:54 +0000

CLAUDE.md es el archivo que Claude Code lee al empezar cada sesión. Es tu oportunidad de decirle cómo se trabaja en tu proyecto, para no repetirlo cada vez.

El error típico es llenarlo de prosa. Lo que funciona: comandos exactos, convenciones concretas y prohibiciones claras.

Plantilla

# CLAUDE.md — Proyecto Python

## Entorno
- Gestor: `uv`
- Ejecutar: `uv run python -m paquete`
- Tests: `uv run pytest -q` (uno: `uv run pytest tests/test_x.py::test_y`)
- Formato y lint: `uv run ruff format . && uv run ruff check --fix .`
- Tipos: `uv run mypy src/`

## Convenciones
- Type hints en toda función pública.
- `pathlib` en vez de `os.path`.
- `logging.getLogger(__name__)`, nunca `print` en código de librería.

## Flujo
1. Escribe o ajusta el test primero.
2. Implementa.
3. ruff + mypy + pytest antes de dar la tarea por terminada.

## No hacer
- No usar `except:` sin tipo.
- No commitear `.env` ni `data/raw/`.

Por qué funciona

Comandos copiables: Claude no tiene que adivinar si usas pip, poetry o uv.
El comando para un solo test le ahorra ejecutar toda la suite en cada cambio.
"No hacer" previene los errores que más te molestan.

Extra: CLAUDE.md por carpetas

Puedes tener un CLAUDE.md en subcarpetas (por ejemplo tests/CLAUDE.md) con reglas locales. Claude lo carga cuando trabaja con archivos de esa carpeta.

Mantenlo corto: si pasa de ~100 líneas, probablemente algo debería ser una skill.

¿Te sirvió? Los hooks de seguridad están gratis en GitHub. Si quieres todo listo (6 skills, 4 comandos, 5 plantillas CLAUDE.md, hooks e instalador), está el Kit Claude Code en Español: paga lo que quieras, desde 3 USD.

Tu primera skill de Claude Code en 10 minutos (en español)

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:15:21 +0000

Las skills son la forma más sencilla de enseñarle a Claude Code a hacer una tarea siempre igual: revisar código, escribir commits, generar tests… Son simples archivos Markdown y Claude decide solo cuándo usarlas.

Dónde van

.claude/skills/<nombre>/SKILL.md      # solo este proyecto
~/.claude/skills/<nombre>/SKILL.md    # todos tus proyectos

Anatomía de una skill

---
name: commits-convencionales
description: "Genera mensajes de commit siguiendo Conventional Commits a partir de los cambios en stage. Úsala cuando el usuario pida \"haz commit\" o \"mensaje de commit\"."
---

# Commits convencionales
1. Lee `git diff --staged`.
2. Elige tipo: feat, fix, refactor, docs, test, chore.
3. Formato: `tipo(ámbito): resumen en imperativo, ≤ 72 caracteres`.
4. Si el diff mezcla cambios no relacionados, propone dividirlo.

La línea clave es description: Claude la lee para decidir si la skill aplica. Escríbela pensando en qué diría el usuario ("haz commit", "revisa mi código"), no en lo que hace internamente.

Consejos que marcan la diferencia

Pasos numerados y verificables. "Ejecuta los tests" es mejor que "asegúrate de que funcione".
Di qué NO hacer. Por ejemplo: "no hagas git add -A sin permiso".
Una skill, una tarea. Si crece demasiado, divídela.
Pruébala: pide la tarea con tus propias palabras y comprueba que se activa.

Probarla

Reinicia Claude Code y escribe: "haz commit de esto". Si la description está bien escrita, verás que Claude sigue tus pasos al pie de la letra.

Cómo evitar que Claude Code borre tu proyecto: hooks de seguridad en 5 minutos

carlosp5751258-lgtm — Wed, 28 Oct 2026 20:02:56 +0000

Los agentes de código son increíbles… hasta que ejecutan git reset --hard sobre una tarde de trabajo sin commitear.
Claude Code tiene una función poco conocida para evitarlo: los hooks.

Qué es un hook

Un script que Claude Code ejecuta antes o después de usar una herramienta. Si un hook PreToolUse
termina con código de salida 2, la acción se cancela y Claude recibe tu mensaje de error, así que corrige su plan solo.

Hook 1: bloquear comandos destructivos

.claude/hooks/bloquear.py:

#!/usr/bin/env python3
import json, re, sys
PATRONES = [
    (r"\brm\s+-[a-zA-Z]*[rR][a-zA-Z]*f?\s+(/|~|\$HOME|\*)(\s|$)", "rm recursivo sobre /, ~ o *"),
    (r"\bgit\s+push\b.*(--force\b|-f\b)(?!-with-lease)", "git push --force"),
    (r"\bgit\s+reset\s+--hard\b", "git reset --hard"),
    (r"(curl|wget)[^|]*\|\s*(sudo\s+)?(ba|z)?sh\b", "curl | sh"),
]
cmd = (json.load(sys.stdin).get("tool_input") or {}).get("command", "")
for p, motivo in PATRONES:
    if re.search(p, cmd, re.I):
        print(f"Bloqueado: {motivo}", file=sys.stderr); sys.exit(2)

Hook 2: que no lea tu `.env`

Mismo patrón, pero mirando tool_input.file_path en las herramientas Read|Edit|Write
y bloqueando .env, *.pem, id_rsa… (y permitiendo .env.example).

Conectarlos

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/bloquear.py" }] }
    ]
  }
}

Reinicia Claude Code y escribe /hooks para comprobar que está activo.

Probarlo sin riesgo

echo '{"tool_input":{"command":"rm -rf ~"}}' | python3 .claude/hooks/bloquear.py; echo $?   # 2
echo '{"tool_input":{"command":"npm test"}}'  | python3 .claude/hooks/bloquear.py; echo $?   # 0

Código completo

Los dos hooks probados y una skill de code review en español, gratis: https://github.com/carlosp5751258-lgtm/claude-code-es.
Si quieres la configuración completa (6 skills, comandos /plan y /pr, plantillas CLAUDE.md, autoformato),
está el Kit Claude Code en Español.

DEV Community: carlosp5751258-lgtm

Formularios de issues en GitHub: deja de recibir reportes de error incompletos

Dónde van

Anatomía de un formulario

Un truco para logs

config.yml: ordena la entrada

Validar antes de hacer push

Crea una skill de Claude Code para migraciones de base de datos sin sustos

Qué es una skill

El método: expandir y contraer

Una checklist que obliga a pensar

Límites explícitos

Pruébala

Un CLAUDE.md que Claude Code sí respeta: ejemplo real con Terraform

1. Comandos exactos, no descripciones

2. Convenciones que el modelo no puede adivinar

3. Un flujo con punto de parada

4. La sección "No hacer"

5. Mantenlo corto y vivo

Prueba rápida

Dockerfile multi-stage para Go: de 800 MB a menos de 20 MB

El Dockerfile

Qué hace cada parte

Un detalle importante

Compruébalo

Valida Conventional Commits con un hook de git en bash (sin instalar nada)

1. El hook

2. Cómo funciona

3. Activarlo para todo el equipo

4. Probarlo

Tu primer CI en GitHub Actions con matriz de versiones (explicado en español)

1. Dónde va el archivo

2. El workflow completo

3. Qué hace cada parte

4. Siguiente paso: protege tu rama

Cómo borrar ramas de git ya fusionadas sin miedo (script Bash con dry-run)

La idea clave: --merged

Proteger las ramas importantes

Borrar, pero con red de seguridad

Un aviso sobre squash y rebase

Cómo pedirle a la IA que depure tu código (sin que adivine)

El error más común: pedir el arreglo primero

Prompt 1: diagnóstico a partir del stack trace

Prompt 2: cuando llevas horas atascado

Buenas prácticas que aplican a cualquier prompt de depuración

Hooks en Claude Code: bloquea comandos peligrosos con un script de 20 líneas

Los cuatro eventos que más vas a usar

El script

Registrarlo

Pruébalo sin abrir Claude

Tres consejos

El CLAUDE.md perfecto para proyectos Python (plantilla lista para copiar)

Plantilla

Por qué funciona

Extra: CLAUDE.md por carpetas

Tu primera skill de Claude Code en 10 minutos (en español)

Dónde van

Anatomía de una skill

Consejos que marcan la diferencia

Probarla

Cómo evitar que Claude Code borre tu proyecto: hooks de seguridad en 5 minutos

Qué es un hook

Hook 1: bloquear comandos destructivos

Hook 2: que no lea tu .env

Conectarlos

Probarlo sin riesgo

Código completo

La idea clave: `--merged`

Hook 2: que no lea tu `.env`