# Plantilla de Checklists de Evaluación para Autoresearch

Usa esta plantilla para crear checklists específicos por skill. Cada checklist
debe tener 3-6 items binarios, ponderados y verificables.

---

## Estructura del checklist

```markdown
## Checklist — [nombre-skill]

**Caso de prueba**: [descripción del caso representativo que se usará para evaluar]

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | [criterio] | [1-5] | [método de verificación] |
```

### Reglas para cada campo

| Campo | Reglas |
|-------|--------|
| **Criterio** | Binario (sí/no), observable, sin ambigüedad |
| **Peso** | 1=nice-to-have, 3=importante, 5=crítico |
| **Verificación** | Grep, conteo, presencia/ausencia, formato |

---

## Ejemplos por dominio

### Backend Python (FastAPI)

```markdown
## Checklist — fastapi-experto

**Caso de prueba**: "Genera un endpoint CRUD para una entidad Producto con
relaciones a Categoría, incluyendo schemas Pydantic y tests"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Endpoints usan response_model tipado | 3 | grep response_model |
| 2 | Inyección con Depends(), nunca instancia directa | 5 | grep Depends, ausencia de instanciación |
| 3 | Schemas usan model_validator, no @validator | 4 | ausencia de @validator |
| 4 | Queries async usan selectinload | 5 | grep selectinload |
| 5 | Tests usan httpx.AsyncClient | 3 | grep AsyncClient |
| 6 | Manejo de errores con HTTPException + detail dict | 2 | formato de excepciones |
```

### Frontend Angular

```markdown
## Checklist — angular-moderno

**Caso de prueba**: "Genera un componente de tabla de datos con filtrado,
paginación y edición inline usando Angular signals"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Componente usa standalone: true | 3 | grep standalone |
| 2 | Inputs usan input() signal, no @Input() | 5 | ausencia de @Input |
| 3 | Outputs usan output(), no @Output() | 4 | ausencia de @Output |
| 4 | Estado derivado usa computed(), no getters | 5 | grep computed( |
| 5 | changeDetection: OnPush | 3 | grep ChangeDetectionStrategy.OnPush |
| 6 | Template usa @if/@for, no *ngIf/*ngFor | 4 | ausencia de *ngIf, *ngFor |
```

### Frontend React

```markdown
## Checklist — react-experto

**Caso de prueba**: "Genera un componente de dashboard con fetching de datos,
estado local, y subcomponentes reutilizables"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Componentes funcionales, no clases | 3 | ausencia de extends Component |
| 2 | Estado con useState/useReducer, memoización correcta | 4 | grep useMemo, useCallback |
| 3 | Efectos tienen deps array completo | 5 | verificar deps de useEffect |
| 4 | Keys únicas en listas (no index) | 4 | ausencia de key={index} |
| 5 | Error boundaries para secciones críticas | 3 | grep ErrorBoundary |
```

### Testing

```markdown
## Checklist — tdd-workflow

**Caso de prueba**: "Genera tests para un servicio de autenticación con
login, logout, refresh token y roles"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Tests siguen patrón Arrange-Act-Assert | 3 | estructura de cada test |
| 2 | Nombres descriptivos (test_should_...) | 2 | formato de nombres |
| 3 | Cubre happy path Y edge cases | 5 | presencia de tests negativos |
| 4 | Usa fixtures/factories, no datos hardcoded | 4 | grep fixture, Factory |
| 5 | Assertions específicas (no assert True) | 3 | ausencia de assert True genérico |
| 6 | Mocking solo en boundaries (DB, HTTP) | 4 | verificar qué se mockea |
```

### Documentación

```markdown
## Checklist — documentador-swl (agente)

**Caso de prueba**: "Genera documentación de API para 3 endpoints con
autenticación, parámetros y respuestas"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Cada endpoint tiene método HTTP + ruta | 5 | formato de encabezados |
| 2 | Parámetros documentados con tipo y requerido | 4 | tabla de parámetros |
| 3 | Ejemplo de request y response incluidos | 5 | bloques de código |
| 4 | Códigos de error documentados | 3 | tabla de status codes |
| 5 | Autenticación requerida especificada | 3 | mención de auth header |
```

### Seguridad

```markdown
## Checklist — checklist-seguridad

**Caso de prueba**: "Revisa un endpoint de login con JWT, refresh tokens
y almacenamiento de sesión"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Tokens tienen expiración explícita | 5 | grep exp, expires |
| 2 | Passwords hasheados con bcrypt/argon2 | 5 | grep hash, bcrypt |
| 3 | Rate limiting en endpoint de login | 4 | grep rate_limit, throttle |
| 4 | Refresh tokens rotados en cada uso | 4 | lógica de rotación |
| 5 | No expone stack traces en errores | 3 | formato de error responses |
```

### CSS / Tailwind

```markdown
## Checklist — tailwind-experto

**Caso de prueba**: "Genera un layout responsivo de dashboard con sidebar,
header y contenido principal usando Tailwind v4"

| # | Criterio | Peso | Verificación |
|---|----------|------|-------------|
| 1 | Usa utilidades de Tailwind, no CSS custom inline | 4 | ausencia de style= |
| 2 | Layout con grid/flex de Tailwind | 3 | grep grid, flex en clases |
| 3 | Breakpoints responsivos (sm:, md:, lg:) | 5 | grep sm:, md: |
| 4 | Spacing consistente (escala de Tailwind) | 3 | no valores arbitrarios |
| 5 | Dark mode con clase dark: | 2 | grep dark: |
```

---

## Cómo crear un checklist para un skill nuevo

1. **Identificar el output típico** del skill (¿qué genera?)
2. **Listar las 3 reglas más críticas** del SKILL.md
3. **Convertir cada regla en criterio binario** verificable
4. **Asignar pesos** según impacto en la calidad del output
5. **Definir método de verificación** (grep, conteo, formato, presencia/ausencia)
6. **Escribir caso de prueba** representativo que active las reglas

### Checklist del checklist (meta-evaluación)

Antes de usar un checklist, verificar:

- [ ] Tiene entre 3 y 6 items
- [ ] Cada item es binario (sí/no sin ambigüedad)
- [ ] Los pesos suman al menos 15 (para que el score sea discriminante)
- [ ] Hay al menos un item de peso 5 (criterio crítico)
- [ ] El caso de prueba es representativo del uso real del skill
- [ ] Los métodos de verificación son ejecutables (grep, conteo, etc.)

---

## Ubicación de checklists en el sistema

Los checklists de evaluación se almacenan junto al skill que evalúan:

```
habilidades/[nombre-skill]/
├── SKILL.md
├── recursos/
│   └── checklist-autoresearch.md   ← checklist de evaluación
└── scripts/                         (si aplica)
```

Esto permite que el loop Autoresearch encuentre el checklist automáticamente
buscando `habilidades/[nombre]/recursos/checklist-autoresearch.md`.
