---
name: code-review
description: >
  Revisa codigo fuente buscando bugs, problemas de seguridad, y mejoras.
  Usa esta skill cuando el usuario pida revisar un archivo, un diff, o
  cambios recientes en un repositorio. Tambien cuando pregunte "que opinas
  de este codigo" o "revisa esto".
---

# Code review

## Prerequisitos

- Tool `ssh_command` o `read_file` para acceder al codigo
- Contexto sobre el lenguaje y framework del proyecto

## Flujo

### 1. Obtener el codigo

Segun el contexto:

**Archivo especifico:**
```bash
read_file: "<ruta>"
```

**Diff de cambios recientes:**
```bash
ssh_command: "cd <repo> && git diff HEAD~1"
# o:
ssh_command: "cd <repo> && git diff --staged"
```

**PR o branch:**
```bash
ssh_command: "cd <repo> && git diff main..<branch>"
```

### 2. Analisis

Revisar el codigo buscando:

**Bugs y errores logicos:**
- Variables no inicializadas o no usadas
- Condiciones de carrera (acceso concurrente sin mutex)
- Nil/null pointer dereferences
- Off-by-one errors
- Resource leaks (archivos, conexiones no cerradas)

**Seguridad (OWASP top 10):**
- Inyeccion SQL o de comandos
- XSS, CSRF
- Secretos hardcodeados
- Permisos demasiado amplios
- Input no validado

**Calidad:**
- Funciones demasiado largas (> 50 lineas)
- Duplicacion de codigo
- Nombres poco claros
- Complejidad innecesaria
- Errores silenciados (catch vacio, err ignorado)

**Estilo y convenciones:**
- Consistencia con el resto del codebase
- Patrones del proyecto (ej: pure core / impure shell en este repo)

### 3. Reporte

Formato del review:

```markdown
## Code Review — <archivo o scope>

### Critico
- **[L42]** SQL injection: el parametro `userID` se concatena directamente en la query
- **[L78]** Resource leak: `file` se abre pero nunca se cierra

### Mejoras sugeridas
- **[L15-20]** Esta logica se repite en handler.go:45 — considerar extraer funcion
- **[L33]** El error de `json.Unmarshal` se ignora silenciosamente

### Positivo
- Buena separacion de responsabilidades
- Tests cubren los casos principales

### Resumen
X issues criticos, Y mejoras sugeridas. Prioridad: resolver los criticos antes de merge.
```

### 4. Seguimiento

Si el usuario quiere aplicar las sugerencias:
- Generar los patches concretos para cada issue
- Aplicar cambios uno por uno con confirmacion