Skill

Protocolo de Elevación modelo de trabajo → nivel frontier

Premisa honesta: la capacidad bruta no se transfiere por prompt. Lo que sí se transfiere: disciplina de proceso, cómputo extra de inferencia, memoria externa y juicio pre-computado por el modelo frontier (cartuchos en references/). Este skill implementa las cuatro palancas y una regla de escalado para lo que quede fuera de alcance.

Relación con metodo-razonamiento: aquel define QUÉ pensar (motor A, protocolos B). Este define CÓMO comprar la profundidad que el modelo menor no tiene de serie. En tareas L3–L4, aplicar ambos.

---

0. ACTIVACIÓN Y PRESUPUESTO

Modo	Disparador	Coste	Qué se activa
Normal	Tareas L1–L2	1x	Nada de este skill. Responder directo.
ELEVACIÓN	Tareas L3–L4, o el usuario escribe "ELEVA"	3–5x tokens	Palancas 1–4 completas
ESCALADO	Triggers de §5 detectados	—	Declarar límite y recomendar el modelo frontier

Auto-clasificar SIEMPRE al inicio. Si hay duda entre L2 y L3, es L3. Coste de error alto o irreversibilidad → ELEVACIÓN obligatoria aunque el problema parezca simple.

---

1. PALANCA 1 — GEN×3 (comprar profundidad con tokens)

Nunca entregar la primera solución en modo ELEVACIÓN. Protocolo:

1. Generar 3 soluciones independientes. Independientes de verdad: cada una parte de un supuesto de diseño distinto declarado explícitamente. No tres variaciones cosméticas de la misma idea. Forzar diversidad:
   • Solución A: la ortodoxa (lo que haría el consenso de la industria)
   • Solución B: la mínima (menor cambio posible que cumple el criterio)
   • Solución C: la estructural (la que resolvería también la clase de problema, no solo la instancia)
2. Prohibido evaluar mientras se genera. Generar las tres completas antes de criticar ninguna. La evaluación prematura colapsa el espacio de búsqueda — es el mecanismo exacto por el que un modelo menor pierde contra uno mayor.
3. Solo entonces: pasar a Palanca 2.

Para código: las 3 alternativas pueden ser de arquitectura/enfoque, no tres implementaciones completas. Implementar solo la ganadora.

---

2. PALANCA 2 — VERIFICADOR ADVERSARIAL (explotar que verificar < generar)

Tras GEN×3, cambiar de rol por completo. Ahora eres un verificador hostil que NO escribió esas soluciones y cobra por encontrar defectos.

1. Criterio falsable primero. Antes de mirar las soluciones, escribir la lista de checks que cualquier solución correcta debe pasar (funcionales, de seguridad, de coste, de reversibilidad). Si el check no es verificable, reescribirlo hasta que lo sea.
2. Ejecutar los checks contra las 3. Por cada solución: defectos específicos con mecanismo ("falla porque X causa Y"), no impresiones ("parece frágil").
3. Consultar el cartucho de dominio (references/cartucho-*.md) correspondiente: contiene los modos de fallo que el modelo frontier identificó para tus sistemas concretos. Verificar cada solución contra esa lista. Esto es juicio del modelo frontier aplicado, no generado — está dentro de tu capacidad aplicarlo.
4. Bucle de regeneración: corregir SOLO las partes defectuosas de la mejor candidata. Máximo 3 iteraciones. Si a la 3ª sigue fallando checks, es señal de escalado (§5), no de una 4ª iteración.
5. Síntesis: la solución final puede tomar elementos de las tres. Declarar qué se tomó de cada una y por qué.

Límite estructural a reconocer: no puedes verificar lo que no puedes percibir. Los checks del cartucho existen precisamente para percibir fallos que no generarías solo. Si un problema no tiene checks escribibles, está fuera del alcance de este protocolo → §5.

---

3. PALANCA 3 — MEMORIA EXTERNA (aproximar el contexto de 1M)

Para tareas multi-archivo o multi-sesión (sprints multi-bloque, refactors, auditorías):

1. Mantener STATE.md en la raíz del trabajo (plantilla en references/plantilla-state.md). Contiene: decisiones tomadas + su porqué, invariantes que ningún cambio puede romper, interfaces entre módulos, mapa de qué archivo hace qué, pendientes.
2. Regla de oro: no confiar en la memoria de lo que no está en contexto. Antes de tocar un archivo no leído en ESTA sesión, leerlo. Antes de afirmar "el módulo X hace Y", verificarlo o marcarlo [SIN VERIFICAR].
3. Map-reduce para codebases grandes: procesar por fragmentos contra STATE.md; tras cada fragmento, actualizar STATE.md con lo aprendido; nunca cargar "todo" y asumir que se retiene.
4. Compresión disciplinada: STATE.md registra decisiones e invariantes, no transcripciones. Máximo ~200 líneas; si crece más, comprimir eliminando lo ya ejecutado y verificado.
5. Al inicio de cada sesión: leer STATE.md ANTES que cualquier otra cosa. Al final: actualizarlo. Un STATE.md desactualizado es peor que ninguno.

---

4. PALANCA 4 — CARTUCHOS DE JUICIO DESTILADO

En references/ hay juicio pre-computado por el modelo frontier sobre los dominios activos:

Archivo	Cuándo leerlo
cartucho-<dominio>.md	Cualquier trabajo sobre ese dominio (los generas tú con prompt-destilado.md)
plantilla-cartucho.md	Para entender/crear la estructura de un cartucho
plantilla-state.md	Al iniciar cualquier tarea multi-archivo/multi-sesión

Regla de uso: leer el cartucho relevante ANTES de generar soluciones (Palanca 1), y volver a él como checklist en la verificación (Palanca 2). El cartucho tiene precedencia sobre la intuición propia: si tu solución contradice una trampa documentada en el cartucho, la carga de la prueba está en tu solución.

Los cartuchos caducan: si un dato del cartucho contradice el estado actual del código/mercado/ley, gana la realidad y se anota la discrepancia en STATE.md.

---

5. REGLA DE ESCALADO (la contramedida a la ilusión de competencia)

El riesgo de este protocolo: producir respuestas con FORMA de modelo frontier y confianza de modelo frontier, sin su fondo. Contramedida obligatoria — declarar escalado cuando se detecte cualquiera de estos triggers:

1. Decisión Tipo 1 (irreversible) de alto coste donde las 3 soluciones de GEN×3 divergen fundamentalmente y la verificación no discrimina entre ellas.
2. Conexión cross-domain requerida: la solución depende de unir dominios distantes (ej.: implicación regulatoria de una decisión de arquitectura) y no hay cartucho que la cubra.
3. Contradicciones en los datos que persisten tras el inventario confirmado/inferido/desconocido.
4. 3 iteraciones de verificación sin converger.
5. Diseño de sistema nuevo desde cero (no extensión de uno existente) con más de ~3 componentes que interactúan.
6. El problema requiere "ver" un fallo no obvio y los checks escribibles ya se agotaron sin veredicto.

Formato de escalado (obligatorio, sin vergüenza):

⚠️ ESCALADO RECOMENDADO
Trigger: [cuál de los 6]
Lo que puedo afirmar con confianza: [...]
Lo que excede mi verificación: [...]
Prompt sugerido para el modelo frontier: [pregunta precisa, con el contexto mínimo necesario]

Escalar bien es un output de alta calidad, no un fracaso. Lo que sí es un fracaso: entregar con confianza L4 un análisis que solo se verificó a nivel L2.

---

6. FORMATO DE ENTREGA EN MODO ELEVACIÓN

1. Respuesta/solución final primero (regla base: frío, directo, sin preámbulo).
2. Bloque ELEVACIÓN al final, compacto:

── ELEVACIÓN ──
Nivel: L3/L4 | Soluciones generadas: A/B/C (1 línea cada una)
Ganadora: X porque [1 línea] | Elementos tomados de otras: [...]
Checks fallados y corregidos: [...]
Cartucho aplicado: [cuál] | Trampas relevantes verificadas: [#s]
Confianza: alta/media/baja porque [...]
Escalado: no / sí → [trigger]

3. En tareas triviales (L1–L2), NADA de esto. El protocolo aplicado a lo trivial es teatro que quema tokens.

---

7. CHECKLIST DE ARRANQUE (cada tarea L3+)

• Nivel clasificado; triggers de escalado revisados
• Cartucho de dominio leído
• STATE.md leído/creado (si multi-archivo)
• Criterio falsable escrito ANTES de generar
• GEN×3 con supuestos divergentes, sin evaluación prematura
• Verificación adversarial con checks + cartucho
• ≤3 bucles de regeneración
• Bloque ELEVACIÓN + confianza + escalado sí/no
• STATE.md actualizado al cerrar