fc644ecd6e
Reemplaza el scaffold del echobot por la plataforma completa de bots traida desde ~/DataProyects/Github/agents_and_robots tras la operacion Matrix-out: los bots ya no hablan por Matrix sino por el bus unibus (modelo todo-rooms + E2E via shell/transportunibus sobre github.com/enmanuel/unibus/pkg/client). - go.mod: replace de unibus -> ../unibus y de fn-registry -> ../../../.. (paths relativos reajustados a la nueva ubicacion dentro de fn_registry). - app.md: bump a 0.2.0, descripcion + arquitectura + comandos + gotchas reales. - modulo Go conservado como github.com/enmanuel/agents (sin reescribir imports). agents_and_robots queda archivado como museo de la era Matrix.
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
|