---
name: prevencion-racionalizacion
description: >
  Patrones para prevenir que los agentes racionalicen atajos, salten procesos o
  inventen excusas para no seguir el workflow. Incluye tabla de excusas comunes,
  red flags de pensamiento y técnicas para construir skills resistentes a la
  racionalización. Cargar al diseñar skills, al detectar agentes saltando procesos,
  o al revisar por qué un agente no siguió un paso obligatorio.
version: "1.0.0"
herramientasPermitidas: [Read, Grep]
exclusiones:
  - "No cargar para prevenir sobre-ingeniería o cambios fuera del scope — ese es `prevencion-sobreingenieria`; este skill trata racionalización de *omisión* de pasos obligatorios, no de *adición* innecesaria de complejidad."
  - "No cargar para evaluar si un proceso fue seguido correctamente después de un incidente — eso es `verificar-trabajo` o revisión post-mortem; este skill sirve para diseñar skills resistentes a la evasión, no para auditoría post-hoc."
  - "No cargar cuando el agente quiere omitir un paso que no está en la spec — en ese caso aplicar las 4 reglas de desviación del implementador; este skill aplica a pasos obligatorios ya documentados en un proceso."
  - "No cargar si el skill o proceso a proteger aún no tiene los pasos definidos — las cláusulas anti-racionalización requieren un proceso existente sobre el cual construir las reglas 'sin excepciones'."
evolvable: true  # default para skill estandar
---
# Prevención de Racionalización en Agentes

La racionalización ocurre cuando un agente genera una justificación convincente
para no seguir un proceso que debería seguir. La justificación suena razonable.
Puede incluso ser técnicamente correcta en abstracto. Pero en el contexto específico,
es una excusa para tomar un atajo. El resultado es el mismo que si el proceso
no existiera: el trabajo queda incompleto o mal hecho.

## Cuándo cargar este skill

Invoca `Skill("prevencion-racionalizacion")` cuando:

- Se diseña un skill nuevo y se quieren incluir cláusulas anti-racionalización
- Se detecta que un agente saltó un paso obligatorio con una justificación
- Se hace autoresearch de un skill que los agentes no siguen consistentemente
- Se revisa por qué un proceso falló en producción y la causa fue un atajo
- Se escribe la sección "Sin excepciones" de cualquier regla obligatoria

## Qué es la racionalización en agentes AI

Un agente racionaliza cuando:
1. Encuentra que seguir el proceso requiere esfuerzo adicional
2. Genera una razón por la cual ese esfuerzo no es necesario en este caso
3. Procede sin seguir el proceso, convencido de que la razón es válida

La diferencia con una excepción legítima es que la excepción legítima está
documentada en el proceso mismo. Si no está documentada, es racionalización.

## Tabla de excusas comunes

| Excusa del agente | Realidad |
|---|---|
| "Es demasiado simple para necesitar diseño" | Hasta features simples se benefician de 5 minutos de diseño. La simplicidad percibida es subjetiva. |
| "Ya sé qué hacer, no necesito preguntar al usuario" | El usuario puede tener contexto crítico que el agente no tiene. Preguntar cuesta menos que reimplementar. |
| "Los tests no son necesarios para este cambio" | Todo cambio que modifica comportamiento necesita verificación. La excepción está en el proceso, no en el juicio del agente. |
| "Solo esta vez voy a saltar este paso" | "Solo esta vez" establece precedente. La próxima vez será más fácil justificarlo. |
| "El espíritu del proceso es lo que importa" | Si se viola la letra del proceso, se viola el espíritu. El proceso tiene la forma que tiene por razones concretas. |
| "Ya intenté 3 veces, debo cambiar de enfoque radicalmente" | 3 intentos fallidos con el mismo enfoque indican un problema de raíz, no de enfoque. Diagnosticar antes de cambiar. |
| "Este skill no aplica a mi situación" | Si hay 1% de probabilidad de que aplique, debe invocarse. El costo de invocar es bajo; el costo de no invocar cuando debía puede ser alto. |
| "El contexto es diferente aquí" | El proceso fue diseñado para contextos variados. Si el contexto genuinamente lo invalida, hay que documentarlo y escalar. |
| "El usuario no lo va a notar" | El usuario puede no notar ahora. Lo notará cuando el sistema falle de una forma que este paso prevenía. |
| "Voy a completarlo después" | "Después" no existe en el contexto de un agente. Si no se hace ahora, no se hace. |

## Red flags de pensamiento

Cuando un agente produce cualquiera de estos patrones de pensamiento, debe detenerse
y aplicar el proceso completo:

- **"No necesito..."** — si existe un proceso para algo, se necesita. Demostrar con
  evidencia del proceso mismo que no aplica, no con razonamiento propio.

- **"Esto es obvio..."** — lo obvio para el agente puede no serlo para el usuario
  o para otro agente. Si es obvio, documentarlo cuesta poco. Si no es obvio, documentarlo
  previene errores.

- **"Solo voy a..."** — el "solo" minimiza el impacto. Los cambios "solo" tienen
  consecuencias que el agente no anticipó. Hacer el proceso completo.

- **"Dado el contexto, puedo saltar..."** — el proceso existe precisamente para
  contextos específicos. Si el contexto justifica una excepción, la excepción debe
  estar en el proceso. Si no está, no es una excepción, es una violación.

- **"Ya lo hice antes sin problema..."** — el éxito pasado no garantiza el éxito
  futuro. Cada instancia del proceso es independiente.

- **"El agente anterior ya verificó esto..."** — cada agente es responsable de
  verificar lo que afirma. La verificación de otro agente no es evidencia propia.

## Principio fundamental

> Si hay 1% de probabilidad de que un skill aplique, DEBE invocarse.

El costo de invocar un skill innecesario es bajo: unos tokens extra de contexto.
El costo de no invocar un skill necesario puede ser alto: un bug en producción,
un requisito no implementado, una vulnerabilidad de seguridad.

La racionalización siempre infravalora el costo de no seguir el proceso y sobrevalora
el costo de seguirlo. Corregir ese sesgo sistemáticamente.

## Cómo construir skills resistentes a la racionalización

Al diseñar o actualizar un skill, incluir estas secciones explícitas:

### 1. Listar excusas específicas del dominio

No usar excusas genéricas. Investigar qué atajos específicos toman los agentes
en este dominio y documentarlos:

```markdown
## Excusas comunes en este dominio — y por qué son incorrectas

| Excusa | Por qué es incorrecta |
|---|---|
| [excusa específica 1] | [razón concreta] |
| [excusa específica 2] | [razón concreta] |
```

### 2. Agregar sección "Sin excepciones" explícita

```markdown
## Sin excepciones

Las siguientes reglas no tienen excepciones. Si el agente encuentra una razón
para no seguirlas, esa razón es racionalización, no una excepción legítima:

- [regla 1] — SIEMPRE, incluso si [excusa típica]
- [regla 2] — SIEMPRE, incluso si [excusa típica]

La única excepción legítima es que el proceso mismo la documente explícitamente.
```

### 3. Incluir red flags de pensamiento específicos

```markdown
## Señales de racionalización en este contexto

Detener y reiniciar el proceso si aparece cualquiera de estos pensamientos:
- "Este endpoint es demasiado simple para necesitar schema Pydantic"
- "Este test es obvio y no aporta valor"
- [red flag específico del dominio]
```

### 4. Documentar el costo de saltarse el proceso

Los agentes racionalizan mejor cuando no tienen visibilidad del costo real:

```markdown
## Qué pasa cuando se salta este proceso

- [consecuencia concreta 1 de saltarse el proceso]
- [consecuencia concreta 2]
```

## Checklist anti-racionalización

Al revisar si un agente siguió un proceso:

- [ ] El agente invocó todos los skills listados en la spec
- [ ] El agente ejecutó todos los pasos del protocolo, no solo los convenientes
- [ ] Si el agente se saltó un paso, la excepción está documentada en el proceso mismo
- [ ] No hubo "solo esta vez" ni "en este contexto particular"
- [ ] El agente reportó evidencia, no confianza

## Cuándo NO cargar

- Se detecta que el agente está agregando abstracciones o código que nadie pidió — eso es sobre-ingeniería, no racionalización; cargar `prevencion-sobreingenieria`.
- El paso omitido no estaba documentado en el proceso — las cláusulas anti-racionalización protegen pasos explícitos; si el paso falta en la spec, primero definirlo y luego protegerlo.
- Se quiere auditar si un proceso específico fue ejecutado correctamente tras una sesión — eso es `verificar-trabajo`; este skill diseña skills resistentes a evasión futura, no valida ejecuciones pasadas.
- La causa del atajo fue un bug en el proceso, no una justificación del agente — en ese caso aplicar la Regla 1 (AUTO-FIX) del implementador; la racionalización requiere que el agente haya generado activamente una excusa.

## Gotchas / Errores comunes no obvios

- **Cláusula "sin excepciones" tan absoluta que bloquea casos legítimos**: el agente no puede avanzar porque el proceso dice "SIEMPRE invocar X, sin excepción" pero hay un escenario técnico legítimo donde X no está disponible. Causa: las cláusulas anti-racionalización se redactaron sin documentar las excepciones reales del dominio. Solución: el proceso debe incluir las excepciones legítimas explícitamente — toda excepción no documentada es racionalización, pero toda excepción documentada en el proceso sí es válida; redactar las cláusulas como "SIEMPRE, salvo [excepción documentada aquí]".
- **Red flag "ya lo hice antes sin problema" usado para validar un atajo que efectivamente es correcto**: el agente tiene evidencia empírica real de que el paso puede omitirse en ese contexto específico. Causa: los red flags son señales de alerta, no prohibiciones absolutas. Solución: si el agente tiene evidencia de que un paso es innecesario en un contexto específico, la acción correcta es documentar la excepción en el proceso (Regla 2 AUTO-ADD del implementador), no ignorar el red flag ni proceder silenciosamente.
- **Tabla de excusas del dominio rellena con excusas genéricas del skill base**: el skill creado tiene como excusa de dominio "este skill no aplica a mi situación" en lugar de una excusa específica del dominio técnico. Causa: copiar la tabla de excusas genéricas sin adaptarla. Solución: las excusas de dominio deben ser observadas de la práctica real — revisar los logs de sesión donde el agente saltó el proceso para extraer las justificaciones reales que usó, no inventarlas a priori.
- **Usuario reporta "sigue fallando" tras un fix y el agente parcha el síntoma sin investigar causa raíz**: el agente aplica un segundo fix en la misma capa donde aplicó el primero, asumiendo que el primer fix estaba incompleto. En realidad, el bug está en una capa distinta (ej: se normaliza el input del formulario pero el bug real es que la consulta de deduplicación usa una columna cache stale; el tercer usuario reporta duplicados no por error de normalización, sino porque la comparación se hace contra `nombre_normalizado` en BD que fue calculado por una versión anterior de la función). Causa: el modelo mental del agente se ancla en la primera hipótesis — "es el normalizador" — y todos los fixes siguientes intentan mejorar el normalizador en lugar de cuestionar la hipótesis. Solución: cuando el usuario reporta "mismo síntoma tras fix", ejecutar **3 preguntas anti-anclaje** antes de tocar código: (1) ¿qué capa del sistema NO modifiqué en el primer fix?, (2) ¿hay estado persistido entre requests (BD, caché, sesión) que pueda tener valores calculados por la versión anterior del código?, (3) ¿el test que reproduce el bug empezaba con la BD limpia o con datos pre-existentes? Si (3) es "pre-existentes" y el fix no tocó esos datos, el bug probablemente está en la interacción entre el código nuevo y el estado viejo.

---
*Skill creado con swl:crear-skill el 2026-03-31. Version 1.0.1 (+ Gotcha meta-aprendizaje 2026-04-20).*
