EN · Read in English Explorar gratis

Checklist · Intermedio · 10 min

Antes de fusionar código de Claude Code: checklist de revisión

Ocho comprobaciones antes de fusionar código escrito por Claude Code: tests reales, secretos, dependencias, licencias, alcance, revisión y un script.

Portada: Antes de fusionar código de Claude Code: checklist de revisión

Probado con Claude Code 2.1.316 · revisado

Ver los archivos en GitHub Gratis · licencia MIT

Para qué sirve

Ocho comprobaciones para hacer antes de fusionar una rama escrita (en todo o en parte) por Claude Code: que los tests se ejecuten de verdad y no se hayan debilitado, que no haya secretos, que las dependencias nuevas existan y estén justificadas, que las licencias encajen, que no haya cambios fuera del alcance de la tarea, que se haya tocado o no la configuración de la IA y del CI, una revisión independiente (/code-review, /security-review o un subagente revisor) y, siempre, una persona que entiende el cambio y lo aprueba. Incluye un script de bash, revisar-rama.sh, que señala dónde mirar.

La lista

El script: dónde mirar antes de fusionar

revisar-rama.sh no sustituye nada de lo anterior: en unos segundos te dice dónde mirar primero (archivos, posibles secretos, dependencias, tests saltados y configuración de la IA). Guárdalo en tu repo o en tu PATH, dale permisos con chmod +x revisar-rama.sh y ejecútalo desde la rama que quieres fusionar:

#!/usr/bin/env bash
# Revisión rápida de una rama antes de fusionar: ./revisar-rama.sh [rama-base]
# No sustituye la revisión humana: te dice dónde mirar primero.
set -euo pipefail
base="${1:-main}"
rango="$base...HEAD"
git rev-parse --verify -q "$base" >/dev/null || { echo "No existe la rama base '$base'" >&2; exit 1; }

echo "== Archivos cambiados (¿todos tienen que ver con la tarea?)"
git diff --stat "$rango"

echo; echo "== Posibles secretos en líneas añadidas"
git diff "$rango" | grep -vE '^\+\+\+' | grep -niE '^\+.*((api|secret|private)[_-]?key|token|passw(or)?d|BEGIN [A-Z ]*PRIVATE KEY)' || echo "(nada a la vista)"

echo; echo "== Dependencias tocadas"
git diff --name-only "$rango" | grep -E '(^|/)(package(-lock)?\.json|pnpm-lock\.yaml|yarn\.lock|requirements[^/]*\.txt|pyproject\.toml|uv\.lock|poetry\.lock|go\.(mod|sum)|Cargo\.(toml|lock)|Gemfile(\.lock)?|composer\.(json|lock))$' || echo "(ninguna)"

echo; echo "== Tests borrados, saltados o enfocados"
git diff --diff-filter=D --name-only "$rango" | grep -iE 'test' || true
git diff "$rango" | grep -nE '^\+.*(@unittest\.skip|pytest\.mark\.(skip|xfail)|\b(it|describe|test)\.(skip|only)\(|\bx(it|describe)\()' || echo "(ninguno añadido)"

echo; echo "== Configuración de la IA y del CI tocada"
git diff --name-only "$rango" | grep -E '^(\.claude/|\.mcp\.json|CLAUDE\.md|AGENTS\.md|\.github/)' || echo "(nada)"

Salida real sobre una rama con cuatro fallos sembrados (1-nov-2026). Los números de los hallazgos son líneas de la salida de git diff, no del archivo:

$ ./revisar-rama.sh main
== Archivos cambiados (¿todos tienen que ver con la tarea?)
 CLAUDE.md           | 1 +
 requirements.txt    | 1 +
 src/app/__init__.py | 1 +
 tests/test_app.py   | 1 +
 4 files changed, 4 insertions(+)

== Posibles secretos en líneas añadidas
21:+API_KEY = "sk-falsa-123"

== Dependencias tocadas
requirements.txt

== Tests borrados, saltados o enfocados
33:+    @unittest.skip("luego")

== Configuración de la IA y del CI tocada
CLAUDE.md

La revisión independiente dentro de Claude Code:

/code-review                     # tu rama + cambios sin confirmar, en un subagente aparte
/code-review low main...mi-rama  # pocos hallazgos, los más seguros
/code-review high 1234           # un pull request, más cobertura
/security-review                 # diff contra la rama por defecto de origin

# Contra la especificación, con el subagente revisor de la plantilla de proyecto:
usa el subagente revisor para revisar git diff main...HEAD contra SPEC.md: comprueba que cada requisito
está implementado y que los casos límite tienen test; informa solo de fallos de corrección y omite el estilo

Si quieres que además cada PR se revise solo en GitHub, añade la receta de revisión de PRs con GitHub Actions.

Errores típicos

Qué probamos y qué falta

En este PC (Linux, Claude Code 2.1.316): revisar-rama.sh se ejecutó sobre una rama de un repo de prueba con cuatro fallos sembrados (una API_KEY escrita en el código, un requirements.txt nuevo, un @unittest.skip y un cambio en CLAUDE.md) y señaló los cuatro; en una rama sin cambios no señala nada; detecta un test borrado; con una rama base inexistente sale con código 1; bash -n confirma la sintaxis. No probamos /code-review, /security-review ni el subagente revisor, porque necesitan una sesión con cuenta: su comportamiento sale de la documentación oficial (code-review-local, commands, best-practices). npm view, pip index versions, npm audit, pip-audit, gitleaks, license-checker y pip-licenses se citan como herramientas habituales, sin probarlas aquí.

Preguntas frecuentes

¿/code-review sustituye la revisión humana?

No. Encuentra errores de corrección con un subagente que no vio la conversación, lo que lo hace útil, pero la documentación deja la responsabilidad de revisar en ti. Úsalo como primer filtro y deja la aprobación final a una persona, sobre todo en autenticación, dinero, datos y despliegue.

¿Qué diferencia hay entre /code-review y la revisión de PR en GitHub Actions?

/code-review corre en tu sesión, en local, y cuenta en tu plan como el resto de la sesión. La receta de GitHub Actions (claude-code-action) revisa cada PR en GitHub de forma automática. También existe el servicio gestionado Code Review para planes Team y Enterprise. Puedes combinarlos: local antes de abrir el PR, automático en el PR.

¿/code-review lee mi CLAUDE.md?

Sí, sigue tu CLAUDE.md, también en una ejecución con -p. No lee REVIEW.md, que solo configura el servicio gestionado de Code Review en GitHub.

¿Por qué el script no encontró un secreto que sí hay?

Porque solo busca palabras típicas en las líneas añadidas: una clave guardada en una variable con otro nombre o codificada se le escapa. Es un aviso rápido, no un escáner. Para eso, añade una herramienta de detección de secretos al CI.

¿Cómo evito que Claude debilite los tests para que pasen?

Díselo en CLAUDE.md («no cambies ni saltes tests existentes sin preguntar»), revisa el diff de tests/ en cada PR y pide al revisor que señale tests borrados, saltados o con aserciones aflojadas, como hace la skill /preparar-pr de la plantilla de proyecto.

Toda la biblioteca