feat: scaffold del sistema de skills
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>
This commit is contained in:
@@ -0,0 +1,96 @@
|
||||
---
|
||||
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
|
||||
Reference in New Issue
Block a user