egutierrez
6ae2e6be03
Estructura inicial de skills organizadas por categoría (analysis, coding, communication, devops, system). Incluye README con convenciones de formato y directorio por skill con sus prompts. Las skills son plantillas de prompts reutilizables que los agentes pueden invocar para tareas especializadas. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
97 lines
2.2 KiB
Markdown
97 lines
2.2 KiB
Markdown
---
|
|
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
|