Tarea original: «Hazme un resumen del post-mortem
del incidente de ayer en la app móvil».

Reescribe con ROL + TAREA + CONTEXTO + FORMATO
+ RESTRICCIONES para un reporte ejecutivo al
comité de operaciones del banco (15 min, sin
jerga, BLUF, acciones con dueño y fecha).

• Lee el prompt pobre y predice qué saldrá (30 s).
• Reescribe versión con los 5 componentes (5 min).
• Ejecuta ambos. Documenta 3 diferencias concretas (2 min).

A) «Ticket de bug: login app móvil falla
   intermitente. Resuelvelo.»

B) «Eres dev senior. Haz algo útil con este
   código.»

C) «Diseña la arquitectura para soportar
   5M usuarios concurrentes.»

• Identifica el gap principal de cada uno (2 min).
• Predice qué tipo de error en el output (1 min).
• Ejecuta y verifica predicción (3 min).

TAREA: Explica por qué deberíamos migrar el core
de cuentas a cloud regulada en los próximos 18
meses.

CONTEXTO: banco con 1.2M clientes, servidores
on-prem de 8 años, ventana de mantenimiento
domingos 02-06h, regulador exige residencia de
datos en país.

FORMATO: 150 palabras, 3 argumentos numerados.

EJECUTA con 3 roles:
  · ROL 1 · CTO
  · ROL 2 · Gerente de Cumplimiento
  · ROL 3 · CISO

• 3 outputs con argumentos distintos por rol.
• Vocabulario diferenciado (CTO: throughput; Cumplimiento: residencia; CISO: superficie).
• Tabla rol|argumento|vocabulario|tono documentada.

Base fija: SRE del equipo de canales digitales.
Resultados Q1: p95 checkout 800 ms → 320 ms tras
3 sprints (caché + connection pooling + índice
en la tabla de sesiones).

FORMATO A: Email para el VP de Tecnología
           ≤100 palabras.
FORMATO B: Tabla 5 columnas (cambio · impacto
           p95 · costo · riesgo · estado).
FORMATO C: 6 bullets mono-línea para slide de
           QBR.

• Email ≤100 palabras, sin jerga SRE pesada.
• Tabla con exactamente 5 columnas.
• Bullets ≤6 y de una línea.

MÍNIMO: «Escribe propuesta para refactorizar
         el módulo de pagos.»

COMPLETO:
  ROL: arquitecto senior, banca digital LATAM.
  TAREA: propuesta para refactorizar el módulo
         de pagos (PCI-DSS).
  CONTEXTO: monolito Java 8, 4 servicios
         dependientes, equipo de 6, ventana
         de 2 sprints.
  FORMATO: 3 párrafos · alcance · plan ·
         riesgos · sin mencionar vendors.

• Especificidad · usabilidad · tono · extensión · edición necesaria.
• Mínimo: >5 min reescritura. Completo: <2 min edición.

ROL: ____ (rol IT específico: SRE, TLM, security
     engineer, data engineer, mobile lead, etc).
TAREA: verbo + objeto + alcance medible.
CONTEXTO: ≥3 datos específicos (stack, equipo,
     restricción regulatoria, deadline).
FORMATO: verificable (palabras, secciones,
     campos JSON).
RESTRICCIONES: ≥2 explícitas (qué NO hacer).

• Los 5 componentes están explícitos.
• Contexto con ≥3 datos específicos del banco.
• Formato verificable mecánicamente.

[ ] ROL específico (no «experto»).
[ ] TAREA: verbo + objeto + alcance.
[ ] CONTEXTO con ≥3 datos del banco.
[ ] FORMATO verificable.
[ ] RESTRICCIONES reales (≥2).

Para cada ✗ · escribe 1 sugerencia
específica (no «mejora el contexto»;
sí «agrega: stack actual, tamaño del
equipo y SLO objetivo»).

• Identifica ≥1 gap real (no de estilo).
• Sugerencias accionables sin preguntar.
• Máx 3 sugerencias priorizadas por impacto.

1. Lee feedback. Decide qué integrar (1 min).
2. Reescribe v2.0 (3 min).
3. Ejecuta v1 y v2 contra el mismo modelo.
4. Documenta: ¿qué cambió en el output?
   ¿Justificó el esfuerzo?

• v2 incorpora ≥1 sugerencia explícitamente.
• Diferencia observable entre outputs.
• Mejora verificable contra el checklist del ej. 7.

Clasifica estas 5 reseñas de la app móvil
del banco en POSITIVO / NEGATIVO / MIXTO.

Tabla con 3 columnas:
  Reseña | Clasificación | Confianza (alta/media/baja)

Reseñas:
1. «Ya no se cae al abrir, pero Yappy
   tarda mucho.»
2. «Excelente para hacer transferencias
   rápidas.»
3. «La biometría no funciona en mi Android 12.»
4. «Buena app pero el saldo no se actualiza
   al instante.»
5. «Imposible iniciar sesión desde ayer.»

NO uses ejemplos. Guarda el output.

• Tabla con 3 columnas exactas.
• ≥1 clasificación debatible identificada.
• Documenta si la confianza varía o el modelo siempre dice «alta».

EJEMPLO:
«Me encanta el diseño de la app pero la
biometría falla cada 2 semanas.»
  → MIXTO · confianza alta ·
    razón: señales contradictorias (UX vs auth).

Ahora clasifica las 5 reseñas.
Mantén formato + agrega columna «Razón».

• Columna «Razón» aparece.
• La confianza varía entre reseñas (no todo «alta»).
• Las reseñas ambiguas tienen justificación explícita.

Criterio        | Zero-shot | One-shot | Ganador
----------------+-----------+----------+--------
Consistencia    |           |          |
Variación conf  |           |          |
Justificación   |           |          |
Manejo ambiguos |           |          |
Formato         |           |          |

• 5 criterios completados con observación específica.
• ≥3 «Ganador» asignados.
• Conclusión = regla de decisión aplicable a futuro.

EJ1 · URGENCIA: «Acción requerida: rota tu
       API key antes del 31 de junio»

EJ2 · BENEFICIO: «Nuevo endpoint /v2/transfers:
       30% menos latencia en p95»

EJ3 · BREAKING: «Deprecación: GET /balance →
       usa /v2/accounts/{id}/balance»

Genera 5 subjects adicionales (≤10 palabras).
Evalúa diversidad entre los 5.

• 5 outputs cubren ≥2 de las 3 variantes.
• Ninguno es copia directa de un ejemplo.
• Todos ≤10 palabras y específicos (no genéricos).

Clasifica severidad de incidentes:
  P1 = caída total / pérdida de datos
  P2 = degradación severa
  P3 = degradación parcial

EJEMPLO (intencionalmente errado):
«Transacciones fallan con timeout >30s
en 40% de los intentos» → P3

Clasifica:
A) Login no carga para nadie hace 12 min
B) Latencia checkout subió de 200ms a 2s
C) Notificaciones push con 5 min de retraso

• Documentas si el modelo replicó el error o lo ignoró (ambos son válidos).
• Tras corregir el ejemplo, output consistente.
• Enuncias la regla: «1 ejemplo erróneo arrastra ≥X% de las clasificaciones».

SET A (subcategorías diversas, formato uniforme):
  - payments-service: liquidación T+0...
  - notifications-svc: push, SMS, email...
  - audit-trail-svc: WORM, retention 7y...

SET B (falsa diversidad: todos del mismo dominio):
  - payments-acquirer · payments-issuer ·
    payments-router · payments-recon · payments-fx

SET C (formatos inconsistentes):
  - mensaje libre / bullet list / JSON pegado /
    yaml plano / 1 línea + emojis.

• A = mejor · B = falsa diversidad · C = inconsistencia.
• Propuesta de mejora específica para el peor.

[CONTEXTO]  · escenario en 1-2 líneas
[INPUT]     · datos de entrada (qué se observa)
[OUTPUT]    · resultado esperado (con formato)
[VARIANTE]  · qué cambia entre instancias

Ejemplo aplicado:
[CONTEXTO] Incidente en producción.
[INPUT]    Logs + métricas + timeline.
[OUTPUT]   Post-mortem: BLUF + cronología +
           acciones con dueño y fecha.
[VARIANTE] Severidad (P1/P2/P3).

Genera 3 ejemplos con este template.
Ejecuta few-shot con un caso nuevo del
mismo tipo.

• Template con 4 campos definidos.
• 3 ejemplos mismo formato, variantes distintas.
• Output del modelo respeta el patrón.

EJEMPLOS:
  «App muestra saldo -1 al login» → BUG
  «¿Puedo invertir en CDs por la app?» → PREGUNTA
  «Quisiera filtros por categoría» → FEATURE
  «3 días sin respuesta de soporte» → QUEJA

CLASIFICA:
  T1: «Falla biometría iOS 17 desde release»
  T2: «¿Hay límite de transferencias diarias?»
  T3: «Diseño feo del nuevo dashboard»
  T4: «Quiero notificación al recibir depósito»
  T5: «Cargo duplicado en compras del 12-feb»
  T6: «La app es la peor que he usado»

Identifica el ticket más ambiguo.

• 6 clasificaciones razonables.
• ≥1 ticket ambiguo identificado (ej. T3 BUG vs QUEJA).
• Demuestras que cambiar 1 ejemplo altera la clasificación ambigua.

1. Define los 5 componentes (3 min).
2. Decide estrategia con los 3 criterios (1 min).
3. Si few-shot · escribe los ejemplos (2 min).
4. Ejecuta y evalúa output (2 min).

CONTEXTO BANCO:
  - SRE para canales digitales (web + mobile).
  - 5 años exp + Kubernetes + observabilidad.
  - Equipo de 6, on-call 1 semana/mes.
  - SLO: 99.95% disponibilidad canal mobile.

• 5 componentes explícitos.
• Estrategia justificada con ≥2 criterios.
• Output con título, responsabilidades, requisitos, tono adecuado a careers.

1. Recupera prompt del ej. 6 (1 min).
2. Decide estrategia con los 3 criterios (1 min).
3. Agrega 1-3 ejemplos si aplica (3 min).
4. Ejecuta v_anatomia y v_anatomia+ejemplos.
5. Compara y decide cuál te sirve más.

• Versión con ejemplos más cercana a lo que necesitabas, O
• Explicas por qué zero-shot era suficiente (válido también).

5 componentes presentes ........... 0-2
Estrategia ejemplos justificada ... 0-2
Diversidad ejemplos (si aplica) ... 0-2
Formato verificable ............... 0-2
Restricciones reales .............. 0-2

Para cada prompt: 1 fortaleza + 1 mejora.

• Puntaje /10 con justificación por criterio.
• Mejora accionable, no opinión.
• Los 2 puntajes son distintos (no idénticos).

1. Selecciona los mejores elementos de cada
   prompt y por qué (3 min).
2. Escribe el prompt combinado (3 min).
3. Ejecuta y documenta qué tomaste de cada
   fuente (2 min).

• Toma elementos de ≥2 fuentes (no solo el tuyo).
• Justifica las decisiones (no «era el mejor»).
• Output superior al de cualquier prompt individual.

ROL: TLM con experiencia en banca digital.
TAREA: Email de seguimiento a la tribu de
       Identidad que te debe activar un scope
       OAuth en su gateway. Llevan 5 días sin
       respuesta. Bloquea el release del lunes.
CONTEXTO: La PR ya está mergeada del lado de
       Identidad pero falta el despliegue a
       producción. Su tech lead es nuevo.
FORMATO: ≤80 palabras · referencia + valor para
       ellos + pregunta abierta de cierre.
RESTRICCIONES: NO usar «solo quería dar
       seguimiento», «cordialmente» ni acrónimos
       sin glosar.

• ≤80 palabras, las 3 partes presentes.
• 1 frase de valor para el otro equipo (no sólo tu urgencia).
• Pregunta abierta no presionante. Sin frases prohibidas.

ROL: arquitecto senior reportando al CTO.
TAREA: Resumen BLUF de la migración del
       sistema de pagos al nuevo core.
CONTEXTO: 2 meses de retraso vs plan original,
       +15% sobre presupuesto, 2 renuncias en
       el equipo, 9 de 10 módulos al 90%
       completados, módulo de reconciliación
       sin avance.
FORMATO: 3 párrafos · 80-120 palabras en total.
       P1 = conclusión directa (BLUF).
       P2 = situación (positivo + negativo).
       P3 = próximos pasos concretos.
RESTRICCIÓN: lenguaje no-técnico (lo lee el CFO).

• 80-120 palabras totales.
• P1 = conclusión directa (no introducción).
• P2 incluye positivo y negativo (no maquillado).
• Sin jerga técnica que requiera glosario.

ROL: analista de arquitectura del banco.
TAREA: Compara 5 vendors de fraud detection
       para canales digitales en LATAM.
FORMATO:
  1) Tabla: Vendor | Fortaleza | Debilidad |
     Precio | Amenaza competitiva.
  2) JSON parseable con los mismos campos
     (snake_case · sin trailing commas).

RESTRICCIÓN: usa "[dato no disponible]" si no
hay referencia pública. Columna amenaza solo
acepta {Alta, Media, Baja}.

• Tabla 5 × 5 completa.
• JSON sintácticamente válido (pega en jq sin errores).
• Marca «[dato no disponible]» donde corresponde, sin inventar.
• Amenaza solo en el enum permitido.

ROL: copywriter senior, banca digital LATAM.
TAREA: 3 variantes para el banner in-app y el
       push notification de la nueva feature
       de pagos por QR.
CONTEXTO: usuarios 25-55, pagan en comercios
       que ya aceptan QR de otras billeteras.
FORMATO:
  · headline ≤8 palabras
  · subheadline ≤20 palabras
VARIANTES:
  A) dolor    B) beneficio    C) diferenciador
RESTRICCIONES: NO usar «revolucionario»,
       «disruptivo», «líder», ni «ahora más
       que nunca».

• 3 variantes con enfoques diferenciados.
• Headlines ≤8 / subheadlines ≤20 palabras.
• Sin palabras prohibidas.
• Consistencia de tono entre las 3.

«Eres consultor de productividad. Lista 5
recomendaciones para mejorar la productividad
del equipo.»

→ Ejecuta y observa: ¿podrían aplicar a
cualquier equipo del mundo?

Lista ≥4 datos que faltan:
  - Tamaño del equipo
  - Stack y herramientas
  - SLO actuales y gap
  - Métrica de productividad relevante
  - Restricciones (regulación, on-call, etc)

Reescribe con esos datos y re-ejecuta.

• Identifica ≥4 datos faltantes.
• Versión mejorada produce recomendaciones NO transferibles a otro equipo.
• ≥3 diferencias concretas entre el vago y el específico.

Iter | Cambio        | Efecto observado | ¿Usable?
-----+---------------+------------------+---------
  1  |               |                  |
  2  |               |                  |
  3  |               |                  |

Reglas:
  · Los 3 cambios deben ser DIFERENTES.
  · ≥1 puede no mejorar (documentar eso vale
    igual que documentar una mejora).

• 3 cambios distintos, no «agregar más detalle» 3 veces.
• ≥1 mejora observable medida.
• v3 superior al original O explicas por qué no.

1) ANALIZA: extrae los 3 temas recurrentes
   del feedback. Cita 2 frases por tema.

2) CLASIFICA: prioriza por impacto en retención
   (Alta/Media/Baja). Justifica.

3) RECOMIENDA: para el tema #1, 1 acción
   concreta implementable en <1 sprint
   (con dueño tentativo y métrica de éxito).

FORMATO: secciones numeradas, sin párrafos
introductorios.

• 3 secciones identificables, no mezcladas.
• Temas extraídos del texto, no inventados.
• Priorización con justificación visible.
• Recomendación implementable en <1 sprint.

Dimensión        | H1 (ChatGPT) | H2 (Claude)
-----------------+--------------+------------
Extensión        |              |
Nivel de detalle |              |
Tono             |              |
Adherencia formato |            |
Restricciones    |              |

• Tabla con 5 dimensiones y observación específica por celda.
• ≥2 diferencias identificadas y nombradas.
• Propones 1 ajuste para la herramienta que peor desempeñó.

Precisión       (técnica + factual) ... /3
Utilidad        (¿lo usarías hoy?)  ... /3
Formato         (verificable)       ... /3
Tono            (apropiado al rol)  ... /3
Restricciones   (cumple lo prohibido) /3
                                  total /15

• Las 5 dimensiones con justificación, no solo número.
• Puntajes diferentes entre herramientas.
• Veredicto identifica la dimensión de mayor diferencia.
• Anticipa ajuste para la perdedora.

NOMBRE         · descriptivo, no «mi_prompt_v3»
CASO DE USO    · qué problema real resuelve
TÉCNICA        · zero/one/few + variantes
HERRAMIENTA    · modelo + versión
VERSIÓN        · v1.0 inicial
PROMPT COMPLETO· copy-paste ready
OUTPUT ESPERADO· qué debe producir
LIMITACIONES   · cuándo NO usarlo
   CONOCIDAS     (no escribir «ninguna»)

• 8 campos completos, no genéricos.
• Nombre descriptivo y específico.
• Limitaciones reales (toda técnica tiene gaps).
• Reproducible por un tercero sin explicación oral.

Planning de capacity de un nuevo microservicio
del banco. Componentes mensuales:
  · COMPUTE  = 2 × STORAGE
  · NETWORK  = COMPUTE + $500

Si STORAGE = $1,200/mes, ¿cuánto cuesta total?

Ejecuta sin pedir razonamiento. Guarda
la respuesta como baseline.

• Storage = 1,200 · Compute = 2,400 · Network = 2,900.
• Total = 6,500 USD/mes.
• Documenta si el modelo acertó y si mostró pasos o solo la respuesta.

[mismo problema del ej. 31]

«Piensa paso a paso antes de dar la
respuesta final. Muestra cada cálculo
intermedio.»

• Output muestra pasos intermedios visibles.
• Respuesta correcta = 6,500.
• Puedes señalar diferencia estructural vs el baseline (¿más confiable?).

Decisión: ¿aumento la capacidad del cluster
del canal mobile la próxima semana?

Datos:
  · RPS p95 actual = 3,400 (target 2,800)
  · CPU avg 78% (alerta a 80%)
  · Costo extra de 4 nodos = $1,200/mes
  · SLO de disponibilidad = 99.95%

Paso 1: Identifica variables relevantes.
Paso 2: Calcula proyección si no actúo.
Paso 3: Verifica contra restricciones SLO
        y presupuesto.
Paso 4: Recomendación final con riesgos.

• Output sigue exactamente los 4 pasos en orden.
• Cada paso produce resultado verificable.
• Recomendación final consistente con el análisis.

Tarea fija: «Evalúa si el banco debe migrar
el módulo de canales digitales a la región
AWS São Paulo en 2026.»

A) «Piensa paso a paso.»

B) «Paso 1: Analiza tamaño del mercado /
       volumen de tráfico esperado.
   Paso 2: Identifica restricciones
       regulatorias (residencia de datos).
   Paso 3: Evalúa latencia y costo vs región
       actual.
   Paso 4: Recomienda con riesgos top-3.»

• Estructura · completitud · verificabilidad.
• Versión B es más accionable y reproducible.

Vendors: A · B · C (puedes usar Cloudflare,
Akamai, AWS WAF como referencia).

Criterios (1-5) · peso:
  · Costo TCO 3 años ............. 40%
  · Capacidad de detección ML .... 30%
  · Soporte LATAM 24/7 ........... 20%
  · Integración con nuestras APIs   10%

INSTRUCCIÓN: «Evalúa cada vendor en cada
criterio (1-5), calcula promedio ponderado
mostrando la operación, recomienda.»

• Scores por criterio explícitos.
• Cálculo ponderado visible (no solo el resultado).
• Recomendación alineada con el score más alto.

«¿Es más rentable contratar un vendor SaaS de
AML (anti-money laundering) a $25K/mes con
implementación de 2 meses, O construir el
módulo internamente con 4 ingenieros senior
(promedio $9K/mes c/u) en 9 meses + $40K en
infra?»

Razona paso a paso. Considera: costo año 1,
costo año 3, riesgo de calidad, regulación,
talent retention.

• ¿Suma el costo de oportunidad de 4 ingenieros senior dedicados 9 meses?
• ¿Compara TCO 3 años (no solo año 1)?
• ¿Considera el costo de mantener un módulo regulatorio internamente?

CONTEXTO: [describe la decisión, los datos
disponibles, las restricciones del banco].

INSTRUCCIÓN: razona en 4-6 pasos prescritos.
Sugerencia de pasos:
  1. Estado actual (métricas duras).
  2. Opciones disponibles y trade-offs.
  3. Restricciones bloqueantes.
  4. Riesgo de la opción preferida.
  5. Plan de rollback si falla.
  6. Recomendación con dueño y fecha.

FORMATO: conclusión accionable al final.

• ≥4 pasos prescritos relevantes a la tarea.
• Output sigue pasos en orden.
• Conclusión es accionable para tu trabajo real esta semana.

EJEMPLO 1 · Release «Onboarding KYC v2»:
  - regulatorio: cambia flujo de identidad ↑
  - técnico: 3 servicios afectados, blue/green ↓
  - operativo: ventana de 2h, on-call entrenado ↓
  → Riesgo MEDIO (regulatorio domina).

Genera 2 ejemplos más siguiendo el patrón.
Luego clasifica 3 releases nuevos del backlog
del banco.

• Modelo muestra el razonamiento por dimensión antes de la clasificación.
• Clasificaciones consistentes con los criterios del ejemplo.
• El patrón de razonamiento se replica en los nuevos casos.

A) «Renombra estas variables siguiendo
    camelCase: total_amt, num_trx, dt_open.»

B) «Corrige sintaxis SQL:
    SELECT * FROM trx WERE id=1»

C) «Escribe tweet ≤280 chars anunciando la
    nueva feature de pagos QR.»

Ejecuta cada una CON y SIN CoT. ¿Mejora alguna?

• Identificas que tareas mecánicas (renombrar, corregir sintaxis, redactar corto) no mejoran.
• Enuncias regla: «CoT no agrega valor cuando la tarea no requiere razonamiento multi-paso».

TAREA FIJA: «Analiza los riesgos de implementar
IA generativa en atención al cliente del banco.»

VERSIÓN 1: ejecuta SIN rol.

VERSIÓN 2: ejecuta con rol:
«Eres CISO con 12 años en banca regulada
LATAM, especializado en superficie de ataque
en canales digitales y compliance con normativa
local.»

• Output con rol es más profundo.
• Usa vocabulario de dominio (DLP, alucinación, jailbreak, residencia).
• Menciona riesgos específicos del sector, no genéricos.

TAREA: «Evalúa la propuesta de automatizar
       el pipeline de despliegue a producción
       del módulo de cuentas con GitOps +
       progressive rollouts.»

FORMATO fijo: 3 argumentos a favor, 2 riesgos,
1 recomendación.

ROL 1: SRE Lead, 8 años plataforma cloud.
ROL 2: Engineering Manager del módulo.
ROL 3: CISO del banco.

Después · tabla: Rol | Argumentos | Riesgos
| Vocabulario propio.

• 3 outputs diferenciados en argumentos y riesgos.
• No repiten los mismos puntos.
• Vocabulario propio de cada dominio.

TAREA: «Recomienda stack tecnológico para
el nuevo backend de transferencias del banco.»

A) Rol vago:
   «Eres un experto.»

B) Rol contradictorio:
   «Eres un arquitecto conservador que ama
    siempre la última tecnología emergente
    y rechaza todo lo on-prem pero exige
    cumplir con normativa de datos local.»

Ejecuta ambos y diagnostica.

• Rol vago → output genérico sin profundidad.
• Rol contradictorio → output con tensión sin resolver o se inclina por una mitad ignorando la otra.

TAREA: «Redacta la política interna de uso
de IA generativa para los empleados del banco
(qué tareas sí, qué tareas no, qué datos no
pueden compartir, qué herramientas autorizadas).»

ROL SIMPLE: «abogado corporativo».

ROL COMPUESTO:
«abogado corporativo con certificación en
ciberseguridad (CISSP) Y experiencia previa
como CHRO, especializado en regulación
tecnológica en LATAM y banca regulada».

Ejecuta ambos y compara dimensiones cubiertas.

• Rol compuesto cubre legal + seguridad + RH + regional.
• Output más completo y práctico que el rol simple.
• Documentas las dimensiones nuevas que aparecieron.

ROL: «Eres consultor estratégico tipo McKinsey
con 15 años en transformación digital bancaria
en LATAM.»

TAREA: «Evalúa si el banco debe migrar el core
bancario a una nube regulada (Azure for
Banking / AWS LATAM) en los próximos 24 meses.»

INSTRUCCIÓN: «Razona paso a paso como lo harías
en una sesión con el CEO:
  1) Diagnóstico (estado actual con métricas).
  2) Opciones (lift-and-shift / re-platform /
     re-architect).
  3) Recomendación con riesgos top-3 y plan
     de mitigación.»

• Perspectiva de consultor visible (frameworks, métricas).
• Estructura de razonamiento visible.
• Superior a solo-rol y solo-CoT.

Profundidad        (1-3) ... /3
Aplicabilidad      (1-3) ... /3
Perspectiva única  (1-3) ... /3
Claridad           (1-3) ... /3
                       TOTAL /12

Pregunta · ¿cuál es más útil para presentar
al comité de tecnología esta semana?

• Puntajes diferenciados (no idénticos).
• Ganador identificado con justificación.
• Reflexión sobre el valor de las perspectivas complementarias.

ROL # · TÍTULO
  Expertise: dominio + años + especialización.
  Perspectiva: desde qué ángulo analiza.
  Restricciones: 2 cosas que NO debe hacer.
  Casos de uso: 2 ejemplos de cuándo invocarlo.

Sugerencias para tu lista:
  · Code reviewer del banco
  · SRE on-call diagnosticando incidente
  · Arquitecto haciendo trade-off design doc
  · Auditor de seguridad pre-release
  · Tech writer redactando para no-IT

• 5 roles con 4 campos cada uno.
• Cada rol diferenciado (no variantes del mismo).
• Roles aplicables a tareas recurrentes reales de tu semana.

ROL: TLM con 10 años en banca digital,
     responsable de plataforma de
     observabilidad cross-tribu.

TAREA: «Evalúa la inversión de migrar de
     una stack mixta (Grafana+Prom+Loki)
     a una plataforma de observabilidad
     comercial unificada.»

RESTRICCIONES:
  · Máximo 150 palabras.
  · No uses jerga que un Gerente General no
    entienda (no APM, no MTTR sin glosar).
  · No recomiendes sin declarar supuestos.

• ≤150 palabras.
• Lenguaje comprensible para perfil no-técnico.
• Supuestos explícitos antes de la recomendación.

P1: «Define 4 pilares para hardening del
     módulo de cuentas del banco
     (sugerencias: data, performance,
     observability, security).»

P2: «Para cada pilar, genera 3 cambios
     concretos accionables en <1 sprint.»

P3: «Organiza los 12 cambios en un
     calendario de 3 sprints con dueño
     tentativo y métrica de salida.»

Ejecuta P1 → toma output → pega en P2.
Ejecuta P2 → toma output → pega en P3.

• Cadena produce calendario completo y usable.
• Cada prompt recibe contexto del anterior literalmente.
• Resultado final es coherente y accionable.

P1: «Lista 5 vendors de open banking activos
     en LATAM con 1 fortaleza cada uno.»

P2 (usa la lista de P1): «Identifica gaps donde
     no hay competencia fuerte hoy.»

P3 (usa los gaps de P2): «Para cada gap, propón
     1 oportunidad concreta con estrategia de
     entrada de 90 días para el banco.»

• Cada paso usa LITERALMENTE el output del anterior.
• No inventa vendors ni gaps nuevos a mitad de la cadena.
• Resultado final es estrategia específica basada en el análisis previo.

P1: «Resume este post-mortem en BLUF +
     cronología + causa raíz.» (OK)

P2 (intencionalmente vago): «Genera
     recomendaciones basadas en el resumen.»

P3: «Prioriza las recomendaciones.»

Ejecuta la cadena completa.
¿Dónde se rompe? ¿Por qué P2 falla?
Propón fix.

• Identificas P2 como eslabón débil (falta contexto: ¿recomendaciones de qué tipo? ¿a quién? ¿en qué horizonte?).
• Fix: agregar criterios y restricciones a P2.
• Re-ejecutas la cadena con el fix y demuestras la mejora.

1. Mapea tu proceso en 4 pasos (2 min).
2. Escribe 1 prompt por paso con formato de
   output que alimente el siguiente (4 min).
3. Ejecuta la cadena completa con un caso real.
4. Documenta dónde tuviste que intervenir manualmente.

• 4 prompts con dependencias claras.
• Cada output es input del siguiente sin parsing manual.
• Resultado final es un entregable usable de tu trabajo real.

P1: «Genera borrador de RFC para añadir
     login por passkey en la app móvil del
     banco (8-12 secciones estándar).»

P2 (QA): «Revisa este borrador y lista:
     - ¿qué falta?
     - ¿qué es factualmente cuestionable?
     - ¿qué sobra?
     Sin reescribirlo todavía.»

P3: «Reescribe el RFC incorporando las
     correcciones específicas de P2.»

• P2 identifica problemas reales (no genéricos).
• P3 los corrige específicamente (no «mejoré la calidad»).
• Versión final superior a P1.

TAREA: «Genera comunicación in-app + push
para usuarios sobre la migración del módulo
de cuentas el sábado 02-06h. Tono empático,
acción del usuario clara.»

A) Un solo prompt con todo el contexto.

B) Cadena de 3:
   P1 · perfila al usuario afectado.
   P2 · define el dolor / preocupación principal.
   P3 · escribe la comunicación con tono apropiado.

Ejecuta ambas y compara.

• Si A es suficiente · documentas que chaining fue overhead.
• Si B es superior · identificas en qué dimensión exacta.
• Regla: ¿bajo qué condiciones vale la pena el costo extra?

P1: «Analiza este ticket y clasifica:
     ¿es TÉCNICO (la app no carga / falla)
     o de CUENTA (acceso, saldo, movimiento)?»

SI técnico → P2a: «Genera respuesta con
     pasos de troubleshooting + reproducción.»

SI cuenta → P2b: «Genera respuesta empática
     con opciones de validación de identidad
     y siguiente paso.»

Ejecuta con 2 tickets reales (1 técnico, 1
de cuenta).

• Clasificación correcta para ambos tickets.
• Cada rama produce respuesta apropiada al tipo.
• Sin mezcla de contenido entre ramas.

P1: [TAREA_INICIAL]
     → output con [FORMATO_FIJO].

P2: input = output P1 + [CRITERIOS_QA]
     → output corregido.

P3: input = output P2 + [AUDIENCIA_DESTINO]
     → entregable final con [FORMATO_PUBLICAR].

Documenta:
  - Variables (qué puede cambiar).
  - Dependencias (qué NO puede cambiar).
  - Caso de prueba con input distinto.

• Variables claras en cada prompt.
• Funciona con input diferente al original.
• Dependencias documentadas.
• Reutilizable por un tercero sin tu explicación.

1. Divide el documento en 3 chunks temáticos
   (no por número de páginas — por tema).

2. Para cada chunk:
   «Resume en 3 bullets los puntos clave,
    sin perder cifras ni nombres propios.»

3. Combina los 3 resúmenes:
   «Combina estos 3 resúmenes en 1 resumen
    ejecutivo de 100 palabras coherente.»

• 3 resúmenes parciales cubren el documento sin redundancia.
• Resumen final coherente y cubre los 3 temas.
• Cifras y nombres propios preservados (no inventados).

«Del siguiente texto, extrae SOLO:

  1) Cifras numéricas con su contexto
     (latencia, costo, % impacto, duración).
  2) Nombres de personas / equipos / servicios
     mencionados, con su rol.
  3) Fechas, plazos y deadlines explícitos.

Formato: tabla por categoría.
Regla: si un dato no está en el texto,
escribe '[no mencionado]'. NO inventes.»

• Tabla completa con datos verificables contra la fuente.
• No inventa lo que no está.
• Marca «[no mencionado]» cuando corresponde.

«Eres un ingeniero de prompts.

INPUT del usuario:
  · tipo_análisis: {riesgo, capacity, performance,
    coste, seguridad}
  · componente: {mobile, web, core, batch, data}
  · audiencia: {CTO, CISO, comité, equipo}

OUTPUT que debes producir:
  Un prompt completo con los 5 componentes
  (rol, tarea, contexto, formato, restricciones)
  listo para copy-paste.»

Prueba con 2 inputs distintos y evalúa.

• Meta-prompt genera prompts completos (5 componentes) para inputs diferentes.
• Los prompts generados son ejecutables directamente sin edición.
• 2 ejecuciones con inputs distintos producen prompts distintos pero consistentes.

[ ] Los 5 componentes presentes.
[ ] Rol específico (no «experto»).
[ ] Contexto con ≥3 datos del banco.
[ ] Formato verificable.
[ ] Restricciones reales.
[ ] Ejecutable sin edición.

Cuando los 3 prompts compartan una debilidad
→ ese patrón está en el meta-prompt.
Ajusta el meta-prompt y re-genera los 3.

• ≥2 / 3 prompts generados usables sin edición.
• Identificas la debilidad recurrente.
• Propones un ajuste concreto al meta-prompt para corregirla.

· Respuesta a P1 / postmortem por incidente.
· RFC técnico para nueva capacidad.
· PR description con contexto y trade-offs.
· Release notes para usuarios finales.
· Ficha de ADR (Architecture Decision Record).
· Plan de rollback para feature flag.
· One-pager para comité de cambio (CAB).

Flujo · 8 min:
  1. Identifica caso recurrente (1 min).
  2. Diseña meta-prompt parametrizado (4 min).
  3. Genera 3 prompts y valida (3 min).

• Meta-prompt reutilizable para tu tarea real.
• 3 prompts generados son usables sin edición.
• Ahorra tiempo vs escribir cada uno manualmente.