Robate esto.

Empezando

// Investigación

Investigar competencia sin sesgos

Cuando necesitas un mapa rápido y honesto de tus competidores antes de una junta.

CopiarEres un analista de mercado senior con 15 años en LatAm. Te paso 3 competidores: [EMPRESA_1], [EMPRESA_2], [EMPRESA_3]. Para cada uno, dame: 1. Posicionamiento real (no su tagline, lo que se percibe en el mercado) 2. Fortaleza no obvia 3. Debilidad estructural (no anecdótica) 4. Cliente ideal específico 5. Una pregunta incómoda que su CMO no quiere responder Formato: tabla. Tono: directo, sin diplomacia. Si no tienes evidencia clara, di "no encontré" y no inventes.

Output esperado:Tabla 5×3 con columnas precisas. La columna "pregunta incómoda" suele ser la joya: te da el ángulo de tu pitch.

No usar si: los competidores son pequeños o regionales — el modelo va a alucinar. Mejor usa una herramienta con browsing.

Empezando

// Reuniones

Resumir una junta de 60 min en 3 párrafos

Saliste de una reunión larga, tienes la transcripción, necesitas mandar un resumen en 10 min.

CopiarTe paso la transcripción de una reunión. Dame DOS outputs: OUTPUT 1 — Resumen ejecutivo (máx 3 párrafos): - Párrafo 1: contexto y por qué se hizo la reunión - Párrafo 2: las 2-3 decisiones tomadas (con quién las debe ejecutar) - Párrafo 3: lo que quedó sin resolver y la fecha próxima OUTPUT 2 — Action items: tabla con columnas [Tarea | Owner | Deadline | Status inicial]. No uses bullets en el OUTPUT 1. No inventes nombres. Si alguien dijo algo importante pero no se decidió, anótalo en "sin resolver". TRANSCRIPCIÓN: [pegar aquí]

Output esperado:3 párrafos limpios para mandar por email + tabla de acciones lista para Asana/ClickUp.

No usar si: la transcripción tiene info confidencial — primero quita nombres reales o usa modelo local.

Empezando

// Escritura

Escribir un memo que se lea de verdad

Tienes que comunicar un cambio impopular y quieres que el equipo entienda y no se ponga a la defensiva.

CopiarEscribe un memo interno sobre [DECISIÓN]. Audiencia: [equipo de X personas]. Reglas: - Máximo 350 palabras - Empieza con la decisión, no con el contexto - Justifica con 2 razones concretas (no abstractas) - Reconoce explícitamente el costo de la decisión (qué se pierde) - Cierra con qué necesitas del equipo en las próximas 48h - Tono: respetuoso, claro, no corporativo. Cero "estamos emocionados de anunciar" Hechos clave que tienes que usar (no inventes nada más): - [hecho 1] - [hecho 2] - [hecho 3]

Output esperado:Memo de ~350 palabras directo, sin "sinergias" ni "cohesión", con la decisión arriba y las 48h claras.

No usar si: la decisión aún no está alineada con tu jefe. Comunicar antes de tener su sí te deja sola defendiéndola cuando arda.

Empezando

// Carrera

Prepararte para una entrevista que sí importa

Tienes una entrevista clave en 24h y necesitas anticipar las preguntas duras sin estudiarte un libro.

CopiarVoy a entrevistar para [PUESTO] en [EMPRESA / SECTOR]. Mi background: [3-4 líneas de qué hiciste]. Hazme tres cosas: 1. Dame las 6 preguntas más probables que me van a hacer, ordenadas de más fácil a más difícil 2. Para cada una, dame el "anti-patrón" (la respuesta que casi todos dan y que aburre al entrevistador) 3. Para las 2 más difíciles, dame el frame de respuesta usando STAR (Situación-Tarea-Acción-Resultado), pero solo el frame, no me lo escribas — quiero pensarlo yo Bonus: una pregunta que YO debería hacerle al entrevistador para que se note que entendí el negocio.

Output esperado: 6 preguntas + anti-patrones + 2 frames STAR (Situación-Tarea-Acción-Resultado) + 1 pregunta inversa para hacerle tú al entrevistador. Esa pregunta inversa cambia entrevistas.

No usar si: es una entrevista de cultura en startup. Esas son menos predecibles.

Empezando

// Brief

Brief para copywriter en 10 minutos

Necesitas escribir un brief para una pieza de copy y siempre se te olvida algo importante.

CopiarVas a escribir un brief de copy para un copywriter freelance. Te doy contexto y tú lo estructuras profesionalmente. Producto/servicio: [QUÉ] Audiencia primaria: [QUIÉN, lo más específico que puedas] Pieza: [landing / email / anuncio / video script] Tono: [3 adjetivos máx] Hecho clave (la única cosa que la audiencia debe recordar): [UNA FRASE] Objeción principal: [QUÉ DUDA TIENE] CTA: [QUÉ HACER DESPUÉS] Lo que NO se puede decir: [legal/marca/competencia] Ejemplos de copy que admiro: [URLS o nombres] Devuelve un brief de máx 1 página con secciones: contexto, audiencia, propuesta de valor, tono, must-includes, no-go, CTA, mood references. Si falta info, lístame las preguntas — no inventes.

Output esperado:Brief de 1 página tipo agencia. Si no llenaste algo, te devuelve preguntas en lugar de relleno.

No usar si: el copywriter ya conoce la marca y el producto. Para él, brief de 1 párrafo basta.

Geeks

// Comparativa

Comparar 3 modelos AI para una tarea concreta

Quieres elegir entre Claude, GPT y Llama para un caso real, no para benchmarks de marketing.

CopiarSoy [tu rol] y necesito elegir un modelo para esta tarea: [DESCRIPCIÓN DE 2 LÍNEAS]. Volumen estimado: [N tokens/mes o N requests/mes] Latencia tolerable: [Xms o "no importa"] Restricciones: [costo / privacidad / on-prem / idioma / herramientas] Compara: Claude Sonnet 4.6, GPT-5.1, Llama 4 (versión grande). Para cada uno dame: 1. Fit con la tarea (1-10) y por qué 2. Costo estimado al mes con ese volumen 3. Riesgo principal (lo que más dolor da en producción) 4. Si lo eligiera, qué ajustaría primero (prompt, RAG, fine-tune, etc.) Cierra con UNA recomendación, no con "depende". Si depende, dices de qué depende y ya.

Output esperado:Tabla comparativa + recomendación final que se la juega. Sin esquivar con un "depende".

No usar si: tu volumen es enano (<10K tokens/mes). Toma el modelo que te gusta y listo.

Geeks

// Arquitectura

Arquitectura mínima viable para tu integración AI

Quieres montar una integración AI y no sabes si necesitas RAG, fine-tune, agente, o solo un buen prompt.

CopiarEres un arquitecto AI senior. Te describo un caso y tú me das la arquitectura mínima viable Y la primera evolución. CASO: [Describe en 5-10 líneas: qué entra, qué sale, quién lo usa, qué precisión necesitas, qué datos hay] Devuelve: 1. ARQUITECTURA MÍNIMA VIABLE (qué construir esta semana): - Modelo - Storage (si aplica) - UI/integración - Costo aproximado mensual 2. PRIMERA EVOLUCIÓN (qué agregas cuando duela): - El cuello de botella que vas a tener primero - El componente que lo resuelve 3. Lo que NO necesitas todavía (cosas que la gente agrega de más): lístame 3. Justifica cada decisión en 1 línea. Sin lenguaje "enterprise". Sin "cohesión".

Output esperado:Stack mínimo + primera evolución + lista anti-overkill. Salida apta para mostrarle a tu jefe.

No usar si: ya tienes la arquitectura aprobada y en marcha. Replantearla a estas alturas solo crea fricción política.

Geeks

// Evaluación

Evaluar una herramienta AI nueva en 30 min

Cada semana sale una "AI tool" nueva. Quieres un sistema para decidir si vale la pena probarla sin perder horas.

CopiarVoy a evaluar una herramienta nueva: [NOMBRE + URL]. Ayúdame a hacerle la prueba ácida en 30 minutos. Devuelve: 1. Las 5 preguntas que tengo que poder responder al final, ordenadas: ¿qué problema real resuelve? ¿quién es el usuario verdadero? ¿con qué se compara? ¿precio real (no "starting at")? ¿qué riesgo de discontinuidad tiene? 2. Para CADA pregunta: dónde busco la respuesta (sección de su web, changelog, repo, twitter del fundador, reviews independientes). 3. Tres red flags (señales de alarma) que indican que no vale ni 30 min de prueba (ej: pricing oculto, fundador sin track record, dependencia de un único proveedor). 4. Un test de 5 minutos que rompe la herramienta más rápido que su demo.

Output esperado:Checklist de evaluación reutilizable + red flags + un test rompedor. Te ahorra 80% del tiempo.

No usar si: ya pagaste el plan anual. Tarde.

Geeks

// Roadmap

Roadmap personal AI para los próximos 90 días

Quieres crecer en AI pero el ruido es paralizante. Un plan honesto y aterrizado a tu nivel.

CopiarSoy [tu rol/contexto]. Mi nivel actual con AI es: [describe en 3 líneas qué haces y qué no entiendes todavía]. Quiero un roadmap de 90 días para subir de nivel SIN ahogarme. Devuelve: - 3 hitos (uno cada 30 días) con criterio de éxito medible - Para cada hito: 1 lectura técnica, 1 video honesto (no influencer), 1 proyecto pequeño que demuestre que aprendí - Las 3 trampas más comunes de mi nivel (lo que la gente intenta y le hace perder semanas) - Una pregunta crítica que debería poder responder al día 90 que hoy no puedo Tono: honesto, no motivacional. Si crees que mi nivel real es más bajo de lo que digo, dímelo.

Output esperado:3 hitos + 9 recursos curados + 3 trampas + 1 pregunta de cierre. Tu plan personal en 1 página.

No usar si: ya estás en un curso estructurado. No mezcles rutas, te confundes.

Geeks

// Build vs Buy

Decidir build vs buy con criterio

Tienes que decidir si construir una solución AI in-house o pagar un SaaS. Y la respuesta NO siempre es "comprá".

CopiarTenemos que decidir entre construir [X] in-house o contratar [SAAS Y]. Contexto: - Tamaño del equipo dev disponible: [N personas / X horas/semana] - Presupuesto del SaaS: [USD/mes] - Volumen de uso: [N usuarios / N transacciones] - Sensibilidad de datos: [pública / interna / regulada] - Velocidad necesaria: [tenemos X semanas / no hay deadline] Devuelve: 1. Tabla comparativa con: costo año 1, costo año 3, riesgo de vendor lock-in, control sobre el roadmap, cumplimiento legal, tiempo a producción, mantenimiento ongoing. 2. La pregunta de criterio de descarte (kill criteria): ¿qué hecho concreto haría obviamente errónea cada opción? 3. Recomendación con UNA frase que arranque con "Construir/Comprar PORQUE...". Si crees que es 50/50, dices cuál es el criterio que rompe el empate.

Output esperado:Tabla 7×2 + criterio de descarte + recomendación accionable. La pregunta del criterio de descarte suele ser la que cambia la decisión.

No usar si: no tienes ni el equipo dev ni el presupuesto. Esa decisión ya está tomada por las restricciones.

Devs

// Code review

Code review con criterio, no de checklist

Necesitas un review honesto de un PR antes de mandárselo a un humano.

CopiarEres un senior engineer haciendo code review. No me pidas explicaciones — lee el código y opina. Te paso un diff. Revisa enfocándote en: 1. Bugs reales (no de estilo) 2. Casos límite que no contempla 3. Riesgos de concurrencia / race conditions 4. Acoplamientos peligrosos con código existente 5. Performance — solo si es realmente un problema, no especulativo 6. Tests faltantes, en orden de importancia Reglas: - Si algo está bien, no lo elogies. Tiempo es tiempo. - Si dudas de la intención del autor, haz UNA pregunta concreta antes de criticar. - Categoriza cada comentario como [bloqueante] [importante] [nit]. - No me digas "deberías considerar X" — di "X porque Y". DIFF: [pegar aquí]

Output esperado:Comentarios categorizados (bloqueante/importante/nit), sin elogios vacíos. Listo para pegar en GitHub.

No usar si: el PR es tuyo y no quieres escuchar críticas. El modelo no es diplomático.

Devs

// TDD

Convertir una spec en tests antes de codear

Recibiste una spec ambigua y quieres escribir los tests primero para forzar la claridad.

CopiarTe paso una especificación. Antes de implementar, escribe los tests. REGLAS: - Solo tests que vengan directamente de la spec — no inventes comportamiento - Si la spec es ambigua, escribe "AMBIGÜEDAD: [pregunta]" en lugar del test - Cubre: golden path, casos límite obvios, errores esperados - Stack: [Jest / pytest / Vitest / Go testing] - Estilo: AAA (arrange-act-assert), nombres descriptivos en español o inglés según el repo Devuelve: 1. Lista de ambigüedades (si las hay) — antes de los tests 2. Tests, agrupados por feature, con un comentario al inicio que diga qué línea de la spec lo origina SPEC: [pegar aquí]

Output esperado:Lista de ambigüedades + tests organizados con trazabilidad a la spec. Las ambigüedades son la parte más útil.

No usar si: ya estás a la mitad de la implementación. Volver a tests es costoso.

Devs

// Refactor

Refactor con criterio (no por gusto)

Quieres mejorar un módulo pero sin gold-plating ni cambios cosméticos.

CopiarEres un senior engineer pragmático. Te paso un módulo y quiero mejorarlo SOLO si tiene impacto real. REGLAS: - Identifica MÁXIMO 3 cambios que valen la pena - Para cada uno, di: el problema concreto que resuelve, la línea/función afectada, el tamaño del cambio (S/M/L), el riesgo (B/M/A) - Si no encuentras 3 cambios de alto valor, di "no veo deuda significativa, este código está bien" — no rellenes - Cero refactor cosmético (renames sin razón, extraer funciones de 3 líneas) - Si encuentras un bug en el camino, márcalo aparte como [BUG] — no lo mezcles con refactor CÓDIGO: [pegar aquí]

Output esperado:Máximo 3 cambios priorizados + bugs marcados aparte. La opción "este código está bien" es honesta y la usa.

No usar si: el código tiene tests débiles o ningún test. Refactor sin tests es ruleta rusa.

Devs

// Debug

Debug sistemático en lugar de adivinanzas

Llevas 2 horas con un bug que no se reproduce y empiezas a pegarle a ciegas.

CopiarMe ayudas a debuggear con método. Cero adivinanzas, cero "prueba X a ver". Te paso: el síntoma, lo que esperaba, lo que pasa, el entorno, lo que ya intenté. Devuelve: 1. UNA hipótesis más probable basada en el patrón del síntoma (no la primera que se te ocurra — la más probable estadísticamente). 2. Una técnica para CONFIRMAR o DESCARTAR esa hipótesis en menos de 10 minutos (con código si aplica). 3. Si la hipótesis se descarta, la SIGUIENTE más probable y su técnica de confirmación. 4. Las 2 trampas mentales más comunes con este tipo de bug (cosas que la gente cree y no son). NO me sugieras "agregar logs" como respuesta genérica — di dónde y qué loguear con propósito. SÍNTOMA: [...] ESPERADO: [...] ACTUAL: [...] ENTORNO: [...] YA INTENTÉ: [...]

Output esperado:Hipótesis priorizada + técnica de confirmación de <10min + plan B + trampas mentales. Esto sí avanza.

No usar si: es un bug en producción que está costando dinero ahora. Llama a alguien.

Devs

// Documentación

Documentar una API que vas a publicar

Tienes que escribir docs de un endpoint y quieres que se entienda sin leer el código.

CopiarDocumenta este endpoint para que un dev externo lo use sin leer mi código. Sigue exactamente esta estructura: # [Método] [Path] ## En 1 frase Qué hace, sin reescribir el path. ## Cuándo usarlo 2-3 escenarios reales. NO "para obtener X" — esos son obvios. ## Request Tabla: parámetro | tipo | obligatorio | descripción | ejemplo ## Response (200) JSON ejemplo realista (no Lorem ipsum). Comenta los campos NO obvios. ## Errores comunes Tabla: código | razón | qué hacer del lado cliente ## Curl real Un curl que funcione copy-paste con valores plausibles. ## Lo que esta API NO hace 2-3 cosas que parece que hace pero no — esto evita 80% de tickets de soporte. CÓDIGO/CONTRATO: [pegar aquí]

Output esperado:Doc lista para Stoplight/Mintlify/Markdown. La sección "Lo que NO hace" suele ser la más leída.

No usar si: la API todavía cambia. Documentar interfaces inestables genera deuda.

Señoras

// Email triage

Asistente que clasifica tu inbox sin abrir cada email por ti

Recibes 80 emails al día y quieres que alguien te diga rápido cuáles importan, sin perder el control.

CopiarVas a actuar como mi jefe de gabinete. Te voy a pasar emails y tú los clasificas SIN responderlos por mí. Categorías: 1. URGENTE (algo se va a romper si no lo veo hoy) 2. DECISIÓN (alguien espera mi sí/no) 3. INFORMATIVO (no requiere acción mía) 4. RUIDO (newsletter, promo, puedes ignorarlo) Para cada email me devuelves: - 1 línea de resumen (sin saludos, sin firmas) - Categoría - Si es DECISIÓN: la pregunta exacta que están haciendo - Si es URGENTE: por qué lo es y qué pasa si lo ignoro 24h Reglas duras: - Nada de "podría ser importante" — categoriza con confianza - Si no entiendes el email, márcalo "revisar a mano" — no inventes resumen - Si detectas tono pasivo-agresivo o conflicto, márcalo con ⚠️ al inicio EMAILS: [pegar tanda]

Output esperado:Lista categorizada que recortas tu inbox a la mitad y identificas las 2-3 cosas que SÍ requieren tu atención.

No usar si: los emails son legales o de RRHH sensibles. Esos los lees tú completos.

Señoras

// Inteligencia diaria

Tu briefing matutino de prensa, en 5 minutos

Quieres saber qué pasó en tu industria sin leer 12 medios. Algo tipo lo que tienen los CEOs grandes.

CopiarVas a ser mi analista de inteligencia matutino. Cada mañana te paso titulares y links de las últimas 24h en mi industria. Tu trabajo es CURAR, no reportar. Devuelve un briefing así: 📌 LO IMPORTANTE (máx 3 items, 2 líneas cada uno): Solo si pasó algo que cambia decisiones. Si no pasó nada, di "día tranquilo, sin novedades de fondo". 🔍 DETRÁS DE: 1 historia que parece menor pero merece tu atención (qué la hace relevante). ⚠️ RIESGO EMERGENTE: 1 patrón que se está formando (regulatorio, competencia, supply chain). Si no hay, "ninguno detectable". 💬 CONVERSACIÓN: lo que tu equipo va a comentar hoy aunque sea ruido — para que no te tome desprevenida cuando salga el tema. Mi industria: [SECTOR] Mis competidores clave: [LISTA] Lo que NO me interesa (para que no me lo metas): [LISTA] INPUTS DE HOY: [titulares + links]

Output esperado:Briefing de 1 página. La sección "detrás de" suele ser donde encuentras tu próxima movida.

No usar si: tu industria está en crisis aguda — ahí necesitas llamadas, no resúmenes.

Señoras

// Negociación

Prepararte para una negociación dura

Tienes una negociación clave y quieres anticipar las jugadas del otro lado sin pagar un coach de $3K.

CopiarVas a actuar como un negociador experimentado preparándome para una conversación difícil. CONTEXTO: - Con quién negocio: [persona y rol] - Qué quiero conseguir (mi resultado ideal): [...] - Qué estoy dispuesta a ceder: [...] - Qué NO voy a ceder bajo ninguna circunstancia: [...] - Mi BATNA (mi alternativa si esto no cierra): [...] - Lo que sé del otro lado: [...] Devuélveme: 1. Las 3 jugadas más probables que va a intentar el otro lado, con la respuesta concreta para cada una 2. Las 2 trampas a las que probablemente caigo yo (básate en mi descripción) 3. La frase exacta para abrir y la frase exacta para cerrar si la conversación se va a un mal lugar 4. Mi BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado): ¿es realmente fuerte o me estoy mintiendo? Sé honesto. 5. Una pregunta que si la hago, cambia el balance de poder NO uses lenguaje de coach motivacional. Habla como alguien que ha negociado mucho.

Output esperado: plan de negociación con frases exactas + chequeo honesto de tu BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado). La crítica honesta a tu BATNA es lo que más sirve.

No usar si: es una negociación legal con abogados. Ahí tu preparación la hace el abogado, no la AI.

Señoras

// Sucesión

Plan de sucesión: pasarle tu rol a alguien en 30 días

Vas a delegar tu rol (parcial o total) y quieres un plan de transición que no te haga la vida miserable después.

CopiarVoy a entregar [parte de] mi rol a [PERSONA, breve descripción]. Ayúdame a diseñar un plan de transición de 30 días. Lo que hago hoy (en bullets, máx 12): [...] Lo que solo yo sé (conocimiento tácito que se pierde si no lo paso): [...] Mis relaciones clave (personas con quien la nueva persona DEBE construir confianza): [...] Lo que NO voy a soltar (temas que sigo decidiendo yo aunque delegue): [...] Devuélveme: 1. Plan semana por semana (4 semanas), con MÁX 3 actividades concretas por semana 2. Las 5 reuniones críticas que tienen que pasar y con quién 3. El documento mínimo viable que la persona necesita: índice (no contenido) — máx 1 página 4. Las 3 señales tempranas de que la transición no va bien (para corregir en lugar de aguantar) 5. Lo que YO tengo que hacer diferente (no lo que la persona tiene que hacer) para que esto funcione Tono: pragmático. Sin "empoderamiento".

Output esperado:Plan de 4 semanas + 5 reuniones + índice de doc + señales tempranas. La sección "qué tienes que hacer diferente" suele ser lo más valioso.

No usar si: la persona ya está sucediéndote y no funciona. Eso ya no es un plan, es una conversación distinta.

Señoras

// Legal

Revisar un contrato antes de mandarlo al abogado

Tienes un contrato encima y quieres llegar al abogado con preguntas afiladas, no en blanco.

CopiarNO eres mi abogado. Eres un revisor que me ayuda a llegar a mi abogado preparada. Te paso un contrato. Devuelve: 1. RESUMEN EN UNA PÁGINA (sin lenguaje legal, en español claro) 2. LAS 5 CLÁUSULAS QUE MÁS RIESGO ME GENERAN, en orden, con: - Cita textual de la cláusula - Por qué es riesgosa para mí (no en abstracto, en MI caso) - La pregunta exacta que tengo que hacerle al abogado 3. CLÁUSULAS ESTÁNDAR pero potencialmente negociables (las que la otra parte espera que firme sin chistar pero que si pidiera ajustar, lo aceptarían) 4. AUSENCIAS NOTABLES: lo que un contrato así DEBERÍA tener y no tiene (eso es donde se esconden los problemas) 5. UN PÁRRAFO DE 3 LÍNEAS que pueda mandarle al otro lado para pedir tiempo a revisar, sin sonar conflictiva CONTEXTO: - Mi rol: [comprador/proveedor/empleador/etc] - Tamaño relativo: [soy más grande / más chica / similar] - Relación: [primera vez / repetimos / preexistente] CONTRATO: [pegar aquí]

Output esperado:Resumen claro + 5 cláusulas riesgosas + ausencias notables. Llegas al abogado con tarea, no con confusión.

No usar si: el contrato es regulado (banca, salud, energía). Ahí necesitas revisión legal especializada desde el principio.

Cuarentones

// Board

Presentación al board en 5 slides, sin relleno

Tienes que reportarle al board y quieres que el deck diga lo importante en 5 slides, no en 30.

CopiarEstoy preparando una presentación al board para [TEMA: ej. revisión Q3, lanzamiento, decisión X]. Tengo que entregarlo en 5 slides. Ni una más. Ayúdame a estructurarlo. CONTEXTO: - Audiencia (perfil del board): [...] - Lo que quiero que aprueben/decidan al final: [...] - Lo que ya saben: [...] - Lo que NO saben pero deberían: [...] - Métricas clave que tengo: [...] Devuélveme la estructura de los 5 slides así: SLIDE 1 — [tema]: bullet único de qué hay en el slide y por qué este es el slide 1. SLIDE 2 — [tema]: ... ... etc. REGLAS: - Slide 1 es la conclusión, no el contexto. Si no, el board ya dejó de oírte en el primer minuto. - Cada slide tiene 1 idea, no 4. - El último slide es la decisión que pides, escrita como pregunta. - Después de los 5 slides, lístame 3 preguntas que el board casi seguro me va a hacer y la respuesta corta para cada una.

Output esperado:5 slides estructurados + 3 Q&A esperadas. Las Q&A son la diferencia entre que aprueben hoy o "lo discutimos la próxima".

No usar si: tu board prefiere narrativa larga (algunos lo hacen). Conoce a tu audiencia.

Cuarentones

// Finanzas

Analizar tu P&L (Pérdidas y Ganancias) sin exponer cifras reales

Quieres interrogar tu P&L con un asistente sin subir datos sensibles a un modelo cloud.

CopiarTengo un P&L y quiero analizarlo, pero NO te voy a pasar números absolutos. Te paso porcentajes y ratios. Trabajá con eso. ESTRUCTURA QUE VOY A PASAR (todo en %): - Mix de revenue por línea: [...] - Margen bruto por línea: [...] - OpEx como % de revenue total, por categoría: [...] - Crecimiento YoY por línea: [...] - Comparación vs benchmark de industria que tengo: [...] Haz lo siguiente: 1. Identifica las 3 anomalías (cosas que no encajan con un negocio sano de mi industria) 2. Para cada anomalía, dame DOS hipótesis posibles (una optimista y una pesimista) 3. Dime qué dato adicional me ayudaría a romper el empate entre las dos hipótesis 4. Una pregunta que si me la hace mi CFO/board, no sabría responder con esta info Tono: analista financiero senior. Sin diplomacia. Si crees que mi negocio tiene un problema serio que no quiero ver, dímelo.

Output esperado:3 anomalías + hipótesis dual + pregunta de stress test. Esto sin exponer ni un dólar real.

No usar si: los porcentajes son chiquitos (revenue micro). Las anomalías van a ser ruido.

Cuarentones

// Decisiones

Framework para decidir cuando estás en bucle

Llevas semanas dándole vueltas a una decisión y necesitas un sistema que te saque del loop.

CopiarEstoy atorada/o entre [OPCIÓN A] y [OPCIÓN B]. Llevo semanas sin decidir. Sin pedirme más contexto del que te doy abajo, llevame por este framework: 1. ¿Cuál es la decisión REAL que estoy postergando? (a veces no es la que parece) 2. ¿Qué pasa si decido y me equivoco? Costo concreto en cada opción. 3. ¿Es reversible? Si sí, decidir mal es barato — el costo de no decidir es mayor. 4. ¿Qué información me falta REALMENTE para decidir? Y, ¿la puedo conseguir en 7 días? Si no, no la voy a tener nunca. 5. ¿Cuál es la opción que mi yo de aquí a 5 años va a desear haber tomado? Sé directo. 6. La frase final: la decisión que me recomiendas Y por qué. CONTEXTO: - Opción A: [...] - Opción B: [...] - Lo que me preocupa de A: [...] - Lo que me preocupa de B: [...] - Costo de NO decidir: [...] Reglas: nada de "depende de tus prioridades". Si depende, dime de qué depende y arriésgate con la recomendación.

Output esperado:6 puntos + recomendación con criterio. La pregunta sobre tu yo de aquí a 5 años suele desbloquear.

No usar si: la decisión es emocional (separación, despido). El framework no funciona ahí.

Cuarentones

// Equipo

Coachear a alguien de tu equipo sin terminar haciendo su trabajo

Tienes un reporte que no está rindiendo y quieres un plan que lo desbloquee sin que termines haciendo su trabajo.

CopiarTengo a [PERSONA, rol, antigüedad]. No está rindiendo en [ÁREA específica]. Llevo [X meses] dándole feedback sin que cambie. ANTES DE DARME EL PLAN, hazme tres preguntas que me obliguen a ser honesta sobre: - Si el problema es de capacidad (no puede) o de motivación (no quiere) - Si yo le di las herramientas/contexto suficientes - Si la persona está en el rol correcto Espera mis respuestas. NO me des plan todavía. (Cuando responda, recién ahí me das un plan de 30 días con: 1 conversación clave, 2 hitos medibles, criterio de "esto no va a funcionar" — que es lo que define si es momento de salida amable o si vale la pena seguir invirtiendo).

Output esperado:3 preguntas duras primero, plan después. La fase de preguntas suele revelar que el problema no es la persona.

No usar si: ya decidiste despedir. No abras la conversación si no vas a actuar sobre las respuestas.

Cuarentones

// KPIs

Diseñar un dashboard que la gente realmente lea

Tienes un dashboard que nadie abre o todos abren y no sirve para decidir. Quieres rediseñarlo con criterio.

CopiarQuiero rediseñar un dashboard para [ROL: ej. director comercial, gerente de operaciones]. Hoy nadie lo usa o lo usan mal. CONTEXTO: - Quién lo va a leer: [...] - Qué decisión debería poder tomar después de mirarlo (UNA decisión, no varias): [...] - Frecuencia con la que lo va a abrir: [diario / semanal / mensual] - Lo que hoy tiene y NO sirve: [...] - Datos disponibles: [lista corta] Devuélveme: 1. Las 5 métricas que SÍ deben estar (no más). Para cada una: qué decisión habilita. 2. Las métricas "obvias" que NO deben estar y por qué (las que la gente mete por inercia). 3. La estructura visual: qué va arriba, qué va al medio, qué va al final, en 5 líneas. 4. Una alerta condicional que el dashboard debería disparar (algo que no requiera abrir el dashboard, te llega por mail/WA si pasa). 5. La pregunta de validación que tengo que hacerle al usuario antes de construir: si su respuesta es X, todo este diseño está mal. No uses palabras tipo "vista 360" o "single source of truth".

Output esperado:5 métricas + 5 obvias-pero-no + estructura + alerta + pregunta de validación. La pregunta evita semanas perdidas.

No usar si: el dashboard ya está aprobado y en uso. Rediseñarlo se vuelve un debate político, no técnico.

Zoomers

// Personal brand

Armar un portafolio personal que no sea genérico

Estás armando tu primer portafolio (para LinkedIn, web, lo que sea) y todo te queda genérico tipo "passionate about X".

CopiarVas a ayudarme a armar un portafolio personal que NO suene a plantilla. Mi info: - Lo que hice (con fechas y resultados concretos, no "ayudé al equipo"): [...] - Lo que me apasiona DE VERDAD (no lo que suena bien decir): [...] - Lo que NO quiero hacer aunque me paguen: [...] - A dónde quiero llegar en 3 años: [...] Devuélveme: 1. Una "one-liner" para LinkedIn que arranque con un VERBO concreto, no con "passionate", "driven" ni "results-oriented" 2. 3 versiones de bio (corta / media / larga) con ángulos distintos: la práctica, la curiosa, la honesta sobre lo que estás aprendiendo 3. Las 3 cosas más interesantes de mi historia que probablemente NO estoy mostrando porque me parecen normales (lo que para ti es normal afuera puede ser raro) 4. Una sección que NO suelen poner pero que destaca: ej. "lo que estoy estudiando ahora", "lo que cambié de opinión sobre" 5. Lo que NO debo poner aunque la plantilla lo pida (cosas que matan más perfiles de lo que ayudan) Tono: fresco pero profesional. Cero "rockstar", cero "ninja", cero emojis sin función.

Output esperado:Bio one-liner + 3 versiones + secciones diferenciadas. La sección "lo que cambié de opinión sobre" llama mucho la atención.

No usar si: aplicas a roles muy tradicionales (banca conservadora, gobierno). Ahí lo "diferente" puede jugar en contra.

Zoomers

// Aplicaciones

Carta de presentación sin cringe (la que sí leen)

Estás aplicando a un trabajo y la cover letter te queda cliché o no la haces porque "nadie las lee" — pero esta vez sí importa.

CopiarVoy a escribir una cover letter para [PUESTO] en [EMPRESA]. Tu trabajo es ayudarme a hacer una que sí lean. Te paso: - La descripción del puesto (copy-paste): [...] - Mi experiencia relevante (3-4 puntos concretos): [...] - Algo específico de la empresa que me llamó la atención (un producto, un valor, un movimiento reciente — algo CONCRETO, no "su misión inspiradora"): [...] - Por qué quiero ESTE puesto y no cualquiera (honesto): [...] Devuélveme: 1. PRIMER PÁRRAFO (60 palabras): no arranca con "Me dirijo a ustedes con interés", arranca con un hecho concreto sobre la empresa que demuestre que investigué de verdad. 2. SEGUNDO PÁRRAFO (80 palabras): conexión entre lo que ofrecen y lo que sé hacer, con UNA evidencia cuantitativa. 3. TERCER PÁRRAFO (40 palabras): por qué este puesto en particular (no "su cultura"). 4. CIERRE (20 palabras): pedido concreto, sin "agradezco su tiempo". Reglas: - Total: máx 200 palabras - Cero "soy un profesional apasionado y proactivo" - Cero subjuntivos cobardes ("podría aportar", "espero contribuir") — usa indicativo - Si me ves inflando algo, márcalo aparte para que lo ajuste yo

Output esperado:4 párrafos en 200 palabras, con verbos directos y un hecho real de la empresa. Esto sí lo leen.

No usar si: la empresa pide cover letter formal con encabezados específicos. Sigue su formato.

Zoomers

// Carrera

Negociar tu primer salario sin perder la oferta

Te ofrecen tu primer trabajo serio y quieres negociar sin que te lo retiren — pero tampoco aceptar lo primero que ofrecen.

CopiarRecibí mi primera oferta seria. Quiero negociar sin sonar entitled ni perder la oferta. CONTEXTO: - Puesto: [...] - Empresa (tamaño, sector, geografía): [...] - Oferta actual: [salario, beneficios, todo lo que te dijeron] - Mi BATNA real: [otra oferta concreta / "necesito el trabajo" / "puedo esperar 60 días"] - Rango de mercado que investigué: [link o número] Devuélveme: 1. ¿Está la oferta en rango de mercado? Sé directo: si está bien, te digo que aceptes; si está bajo, te digo cuánto pedir. 2. Si pido más, ¿pido SALARIO base, BONO de firma, EQUITY, BENEFICIOS, o CONDICIONES (vacaciones, remoto, horario)? Ordenalo por probabilidad de éxito en MI caso. 3. La frase exacta para empezar la conversación de negociación (texto literal que copio y pego) 4. La frase para cerrar si dicen que no a mi pedido inicial (sin perder la oferta) 5. Las 2 cosas que NO debo hacer aunque me las recomienden en internet (esos consejos viejos que en LatAm o para junior se voltean) Tono: realista. Si crees que estoy en posición débil, dímelo y dame estrategia para esa posición.

Output esperado:Diagnóstico honesto + jerarquía de qué pedir + frases exactas. La frase de cierre sin perder oferta es oro.

No usar si: ya aceptaste verbalmente. Renegociar después es una banderita roja para muchos empleadores.

Zoomers

// Side hustle

Validar tu idea de side hustle en 7 días sin construir nada

Tienes una idea para un side project y quieres saber si vale la pena antes de gastar 3 meses construyendo.

CopiarTengo una idea: [DESCRIPCIÓN EN 3 LÍNEAS]. Antes de construir nada, quiero validarla en 7 días. Diséñame el experimento. Devuélveme: 1. La hipótesis CRÍTICA: ¿qué tiene que ser cierto para que esta idea valga la pena? (UNA hipótesis, no cinco) 2. El test más barato y rápido para confirmar/descartar esa hipótesis. NO me digas "haz una landing y mide" si hay algo más rápido. 3. Cuánto debería costar el test (en dinero y en horas). Si supera $50 USD o 10 horas para una validación inicial, estoy haciendo algo mal. 4. La métrica que define éxito: número concreto. Si no llego a X, descartá la idea. 5. La trampa del "vanity metric (métrica de vanidad)": qué métrica voy a querer celebrar pero que NO valida nada. 6. Si el test sale bien, ¿cuál es el SIGUIENTE experimento? (un solo paso adelante, no el plan completo) Si la idea ya tiene 50 competidores y no la diferenciaste, dímelo arriba antes del experimento.

Output esperado:1 hipótesis + 1 test + presupuesto + métrica + trampa + paso siguiente. Detectar la métrica de vanidad te ahorra meses haciéndote ilusiones.

No usar si: ya construiste el MVP (Producto Mínimo Viable). Validar después de construir es otro juego, y mucho más caro.

Zoomers

// Estudio

Estudiar para un examen difícil con la AI bien usada

Tienes un examen importante en pocos días y quieres que la AI te ayude a aprender de verdad, no a hacer trampa.

CopiarVas a ser mi tutor para [MATERIA / EXAMEN]. Tienes que enseñarme, no responderme. REGLAS DURAS PARA TI: 1. NUNCA me des la respuesta directa. Siempre la siguiente pregunta o pista que me empuja a pensar. 2. Si me equivoco, no me digas "incorrecto, la respuesta es X". Dime: "¿qué pasaría si Y?" — y déjame llegar. 3. Si me trabo después de 3 intentos, dame UNA pista concreta — no la respuesta. 4. Cada 5 conceptos, hazme una pregunta sintética que mezcle 2-3 cosas que ya vimos. 5. Al final de la sesión, dame: - Las 3 cosas que dominé - Las 2 que necesito reforzar - Una explicación de por qué confundí lo que confundí (no qué confundí — POR QUÉ) CONTEXTO: - Material que tengo que cubrir: [tema o link] - Tipo de examen (memorización / aplicación / análisis): [...] - Nivel de partida: [no sé nada / sé lo básico / lo manejo pero me trabo en X] - Tiempo disponible total: [horas] Empieza con UNA pregunta de diagnóstico. No me des resumen. Solo pregunta.

Output esperado:Sesión socrática que te hace pensar. La explicación de POR QUÉ te confundes es la diferencia entre estudiar y aprender.

No usar si: el examen es mañana y solo necesitas repasar. Ahí pídele que te haga preguntas tipo flashcard, no Sócrates.

Empezando

// Código nuevo

Escribe un script de Python básico

Cuando necesitas un código sencillo pero no sabes por dónde empezar

CopiarEscribe un pequeño script en Python que lea un archivo CSV y calcule la media de una columna específica. Asegúrate de incluir manejo de errores para archivos inexistentes o formatos incorrectos.

Output esperado:Obtendrás un script corto pero funcional que puede ser ejecutado directamente en Python. El código incluirá manejo de excepciones para casos como archivos no encontrados y columnas inexistentes.

No usar si: No es adecuado si ya tienes experiencia avanzada o necesitas algo más complejo.

Geeks

// Investigación

Crea una lista de recursos para aprender IA

Cuando quieres empezar a explorar el mundo de la inteligencia artificial pero no sabes por dónde comenzar

CopiarGenera una lista ordenada de sitios web, libros y cursos en línea recomendados para principiantes que quieren incursionar en el campo de la inteligencia artificial. Incluye un breve resumen de cada recurso.

Output esperado:Recibirás una lista organizada con recursos variados (sitios web, libros, cursos) junto a una descripción concisa sobre qué pueden aprender de ellos los principiantes de IA.

No usar si: Este prompt no es útil si ya eres experto en el tema o necesitas información muy específica.

Señoras

// Reuniones

Prepara un resumen de la reunión semanal

Cuando terminas una reunión y necesitas hacer un breve resumen para compartir con el equipo

CopiarCrea un texto corto que resuma los puntos clave abordados durante la reunión semanal, incluyendo decisiones importantes tomadas y acciones a seguir. Asegúrate de mencionar quién está responsable de cada tarea.

Output esperado:Obtendrás un breve resumen con los principales puntos discutidos en la reunión, las decisiones tomadas y las tareas asignadas junto al nombre del responsable para cada una.

No usar si: Este prompt no es útil si ya has anotado todos los detalles de la reunión por tu cuenta.

Empezando

// Investigación

Investiga sobre un nuevo trabajo

Cuando necesitas saber más sobre una nueva posición laboral.

CopiarHazme una investigación detallada sobre la posición de Analista Financiero en XYZ Corp. Incluye información acerca del nivel de experiencia requerido, las responsabilidades específicas y los requisitos técnicos clave para este puesto.

Output esperado:Obtendrás un resumen conciso con detalles relevantes sobre el trabajo, incluyendo lo que se espera de ti y qué habilidades necesitas.

No usar si: No uses este prompt si ya conoces bien la posición o estás buscando información más específica.

Geeks

// Reuniones

Prepara un resumen para una reunión

Cuando necesitas sintetizar la discusión de una reunión pasada antes del siguiente encuentro.

CopiarHazme un resumen de 3-5 puntos clave de nuestra última reunión sobre el proyecto Alpha, incluyendo los acuerdos y desacuerdos principales.

Output esperado:Obtendrás un resumen conciso que recopila las ideas más importantes de la discusión anterior.

No usar si: No uses este prompt si la reunión fue muy técnica o específica, ya que podría no cubrir todos los detalles técnicos necesarios.

Señoras

// Code review

Revisa código para errores comunes

Cuando quieres revisar un trozo de código por errores tipográficos o funcionales.

CopiarComprueba este fragmento de código en Python y busca errores como malas prácticas, falta de documentación o problemas lógicos.

Output esperado:Obtendrás una lista de posibles errores junto con sugerencias para corregirlos.

No usar si: No uses este prompt si el código es demasiado complejo y requiere entender conceptos avanzados.

Empezando

// Aprender algo nuevo

Entender un tema nuevo desde cero

Cuando quieres meterte a un tema que no manejas y no sabes ni por dónde empezar.

CopiarQuiero entender [TEMA] desde cero. Asume que no sé absolutamente nada. 1. Explícamelo en 5 frases cortas, sin jerga. Si usas una palabra técnica, tradúcela ahí mismo entre paréntesis. 2. Dame los 3 conceptos que TENGO que dominar antes de avanzar, en orden. 3. Ponme un ejemplo concreto de la vida real, no uno genérico. 4. Termina con UNA pregunta que yo debería hacerte para profundizar (la pregunta inversa) y respóndela tú mismo. Si algo del tema es discutido o no hay consenso, dímelo en vez de inventar una respuesta limpia.

Output esperado:Una explicación aterrizada en lenguaje llano, con los cimientos que te faltan puestos en orden. Lo más útil es el paso 4: la pregunta inversa. El modelo te dice qué NO sabías que debías preguntar, y te la contesta. Así no dependes de saber formular la duda correcta desde el arranque.

No usar si: No lo uses para temas donde un dato equivocado te cuesta caro (dosis médicas, montos legales, fiscales). Ahí el modelo suena seguro aunque se equivoque. Úsalo para orientarte, luego confirma con una fuente humana.

Devs

// Code review

Revisar mi diff antes de abrir el PR

Cuando terminaste un cambio y quieres una segunda lectura antes de pedirle el review a un compañero.

CopiarActúa como un revisor senior escéptico, no como porrista. Te pego mi diff. Revísalo así: 1. Bugs reales primero: race conditions, casos borde sin cubrir, nulls, errores que se tragan en silencio. Uno por uno, con el número de línea. 2. Después, gold-plating: código que agregué de más y que nadie pidió. Márcalo para borrar. 3. Marca aparte lo que NO puedas juzgar sin ver el resto del repo, con la etiqueta 'revisar a mano'. No adivines. 4. No me felicites. Si algo está bien, sáltalo y ve a lo que puede romperse. Al final dame un veredicto: ¿lo abrirías como PR tal cual, sí o no, y por qué? Sin esquivar con un 'depende'. [PEGA AQUÍ TU DIFF]

Output esperado:Una lista de hallazgos ordenados por gravedad, con línea señalada, y una separación clara entre 'esto rompe' y 'esto sobra'. Lo valioso es la etiqueta 'revisar a mano': el modelo admite lo que no puede saber sin contexto del repo, en vez de inventarse un juicio. Cierra con un sí/no concreto sobre abrir el PR.

No usar si: No sustituye el review humano ni las pruebas. El modelo no ve tu repo completo ni corre tu suite, así que inventará supuestos sobre funciones que no le pegaste. Trátalo como primer filtro, no como aprobación final.

Cuarentones

// Reuniones difíciles

Prepararme para una conversación tensa

Cuando tienes que entrar a negociar o dar una noticia incómoda y no quieres que la reunión te tome desprevenida.

CopiarVoy a entrar a una conversación difícil. Ayúdame a prepararla, no a redactarla bonito. Contexto: [describe la situación, con quién, qué está en juego]. 1. Dame las 3 objeciones más probables que me van a poner, ordenadas de la más dura a la más floja. 2. Para cada una, una respuesta de 2 frases. Directa, sin adornos. 3. Ayúdame a definir mi BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado): si esto no cierra, ¿cuál es mi mejor opción fuera de esta mesa? 4. Dame mi criterio de descarte (criterio de descarte (kill criteria)): las 2 señales que, si aparecen, me dicen que ya no vale la pena seguir insistiendo. Sé honesto conmigo. Si mi posición es débil, dímelo antes de que me lo diga la otra persona.

Output esperado:Un guion de defensa aterrizado: qué te van a rebatir y qué contestas, sin quedarte en blanco a mitad de la reunión. Lo que casi nadie prepara es el punto 3 y 4. Sandra Urena recomienda escribir tu criterio de descarte ANTES de entrar, no descubrirlo cuando ya estás emocionalmente metida en la discusión. Sales sabiendo tu piso, no solo tu deseo.

No usar si: No lo uses para poner palabras en boca de otra persona ni para armar 'trucos' de manipulación: el modelo no conoce a tu contraparte y te dará supuestos. Úsalo para ordenar TU cabeza, no para predecir la de enfrente.

Señoras

// Proveedores

Filtrar el humo de una propuesta de proveedor de AI

Cuando un proveedor te manda una propuesta llena de promesas de AI y tienes que decidir si vale una reunión.

CopiarActúa como una directora escéptica con 20 años comprando servicios. Te voy a pegar la propuesta de un proveedor que ofrece soluciones con AI. Analízala y devuélveme: 1. Lo que promete en concreto (entregables medibles), separado de lo que solo suena bien. 2. Las 5 preguntas que debo hacerle en la primera llamada para verificar que es real. 3. Qué dato o referencia falta en la propuesta y debería pedir antes de firmar. 4. Señales de alarma (red flags (señales de alarma)): promesas sin plazo, métricas sin línea base, dependencia total del proveedor (vendor lock-in, quedar amarrada a él). No me des tu opinión sobre si contrato o no. Dame el material para decidirlo yo. Propuesta: [pega aquí el texto de la propuesta]

Output esperado:Una separación clara entre promesas concretas y adorno, 5 preguntas listas para la llamada y la lista de lo que falta antes de firmar. Lo más útil suele ser la sección de señales de alarma: las métricas sin línea base y las promesas sin plazo saltan a la vista de inmediato. Sandra Urena recomienda llegar a esa primera llamada con las 5 preguntas impresas: cambia por completo quién dirige la reunión.

No usar si: No lo uses como sustituto de revisión legal o financiera: la AI no conoce tu contrato marco ni tus números. Y si la propuesta es de dos párrafos, no hay material que analizar — pide primero una propuesta seria.

Devs

// Legacy

Entender un repo legacy antes de tocar una línea

Cuando heredas un codebase sin documentación y te piden un cambio "pequeño" para el viernes.

CopiarVoy a pegarte partes de un repo que heredé: estructura de carpetas, el archivo principal y el módulo que debo modificar. Antes de sugerir cualquier cambio: 1. Descríbeme qué hace el sistema en 5 líneas, en términos de negocio, no de código. 2. Mapea las dependencias del módulo que voy a tocar: qué lo llama y a qué llama. 3. Lístame los puntos donde un cambio se puede propagar sin que yo lo note: estado global, efectos secundarios (side effects), configuración implícita. 4. Dime qué tests existen para esta zona y cuáles faltarían antes de tocar nada. 5. Hazme las preguntas que no puedes responder con lo que te pegué. No escribas código todavía. Estructura y archivos: [pega aquí]

Output esperado:Un mapa del terreno antes de excavar: qué hace el sistema en lenguaje de negocio, qué depende de qué y dónde están las minas. El punto que más vale es el 5: las preguntas que la AI no puede responder con tu material son exactamente las que debes hacerle a quien escribió ese código, si todavía trabaja ahí.

No usar si: No sirve si pegas un archivo suelto: sin estructura ni contexto, la AI adivina, y sus adivinanzas suenan muy seguras. Tampoco lo uses para saltarte la lectura del código crítico — el mapa orienta, no reemplaza caminar el terreno.

Cuarentones

// Carrera

Preparar tu evaluación anual con evidencia, no memoria

Cuando se acerca tu evaluación de desempeño y solo recuerdas lo que pasó en los últimos dos meses.

CopiarTe voy a dar material crudo de mi año: correos clave, minutas, entregables y los objetivos que me pusieron en enero. Organízame la evaluación: 1. Cruza cada objetivo del año contra la evidencia que te di. Marca cada uno: cumplido con evidencia / cumplido sin evidencia clara / no cumplido. 2. Extrae 3 logros con impacto medible, redactados en una línea cada uno: qué hice, qué cambió, cómo se midió. 3. Identifica el hueco más incómodo — lo que mi jefe probablemente va a señalar — y ayúdame a preparar una respuesta honesta, sin excusas. 4. Redacta la lista de lo que voy a pedir (recursos, alcance o compensación), ligada a la evidencia de arriba. Objetivos de enero: [pega aquí] Evidencia del año: [pega aquí]

Output esperado:Llegas a la reunión con tres logros de una línea cada uno, cada objetivo cruzado contra evidencia real y una respuesta preparada para la pregunta incómoda. Lo que marca la diferencia es el punto 3: anticipar el señalamiento de tu jefe en lugar de improvisarlo dentro de la sala.

No usar si: No funciona sin materia prima: si no le das correos, minutas o entregables reales, te devuelve frases genéricas de perfil de LinkedIn. Y cuidado con pegar información confidencial de tu empresa en una herramienta no aprobada — anonimiza cifras y nombres antes.

Empezando

// Email

Revisar un email delicado antes de mandarlo

Cuando llevas 20 minutos dándole vueltas a un correo con carga: un reclamo, una mala noticia o un favor grande.

CopiarTe voy a pegar un email que todavía no envío. Antes de tocar el texto, respóndeme esto: 1. ¿Qué va a entender el destinatario en la primera leída rápida? 2. ¿Qué frase puede sonar agresiva, pasivo-agresiva o confusa sin que yo lo note? 3. ¿Qué estoy pidiendo exactamente y en qué línea queda claro? Si no queda claro, dímelo. Después dame una versión corregida que: - Mantenga mi tono; no lo vuelvas corporativo ni robótico - Ponga la petición concreta en las primeras 3 líneas - No pase de 150 palabras Contexto: [quién es el destinatario y qué relación tienes con esa persona] Email: [pega aquí tu borrador]

Output esperado:Un diagnóstico en 3 puntos antes de cualquier reescritura. La pregunta 2 es la valiosa: te señala las frases que suenan distinto de como las pensaste, que es justo lo que tú ya no puedes ver después de tres releídas. Luego una versión corregida corta, con tu voz, y la petición al inicio en vez de escondida en el último párrafo.

No usar si: No lo uses para correos con peso legal: despidos, disputas de contrato, temas de acoso. Ahí el borrador lo revisa un abogado o Recursos Humanos, no un chat. Tampoco sirve si aún no sabes qué quieres pedir: la AI pule el texto, no decide por ti.

Señoras

// Equipo

Escribir la política de uso de AI para tu empresa

Cuando tu equipo ya usa ChatGPT por su cuenta y tú todavía no has puesto reglas claras por escrito.

CopiarAyúdame a redactar una política de uso de herramientas de AI para mi empresa. Somos [tamaño y giro, ej: 35 personas, servicios profesionales]. Antes de redactar nada, hazme 5 preguntas, una por una, para entender: - Qué información NUNCA puede salir de la empresa (datos de clientes, precios, nómina) - Qué herramientas ya usa mi equipo por su cuenta - Quién responde si algo sale mal Con mis respuestas, redacta una política de máximo 1 página con: 1. Qué sí se puede hacer, con 3 ejemplos concretos de nuestro día a día 2. Qué no se puede hacer y por qué, explicado sin tono de regaño 3. A quién preguntar cuando haya duda Lenguaje claro, cero jerga legal. La tiene que entender alguien que nunca ha abierto ChatGPT.

Output esperado:Primero un interrogatorio corto que te obliga a definir lo importante: qué datos son intocables y quién es responsable. Luego una política de una página que puedes mandar mañana, con ejemplos de tu operación y sin lenguaje de abogado. Sandra Urena recomienda empezar siempre por la lista de información que nunca sale de la empresa: esa lista vale más que todo el resto del documento.

No usar si: No lo uses como documento final si manejas datos regulados: salud, información financiera de terceros, menores de edad. Ahí este borrador es el punto de partida para tu abogado, no el reemplazo. Y si tú misma no usas ninguna herramienta de AI todavía, prueba una un par de semanas antes de escribir reglas sobre algo que no conoces.

Zoomers

// Carrera

Decidir si ese curso o certificación vale tu dinero

Cuando estás a punto de pagar un curso porque el anuncio te prometió cambiarte la vida en 6 semanas.

CopiarEstoy considerando pagar [nombre del curso o certificación]. Cuesta [precio] y dura [tiempo]. Mi meta real es [conseguir trabajo de X / subir de puesto / aprender Y]. Antes de darme tu opinión: 1. Pregúntame qué evidencia tengo de que este curso conecta con mi meta: temario, quién lo imparte, qué pasó con egresados reales 2. Lístame 3 alternativas gratuitas o más baratas para lograr lo mismo, y qué sacrifico con cada una 3. Dame un criterio de descarte (criterio de descarte (kill criteria)): la señal concreta que me diría "no lo pagues" Al final, tu recomendación directa: pagar, no pagar, o pagar solo si se cumple una condición específica. Sin esquivar con un "depende".

Output esperado:Un interrogatorio que expone si tu evidencia es real o si solo viste testimonios del propio vendedor. Después 3 alternativas con su costo oculto (tiempo, cero acompañamiento, sin certificado) y un criterio de descarte concreto, tipo "si no encuentras 3 personas contratadas que lo mencionen en su perfil, no pagues". Cierra con una recomendación sin rodeos.

No usar si: No lo uses para justificar una compra que ya hiciste: ahí solo vas a buscar que la AI te dé la razón. Tampoco decide por ti si tu meta es difusa; si no puedes llenar el campo "mi meta real es", ese es el problema a resolver primero, no el curso.

Señoras

// Decisiones

Traducir la jerga de tu equipo de sistemas

Cuando tu equipo de tecnología te pide aprobar un gasto y la explicación viene llena de términos que nadie te tradujo.

CopiarVoy a pegarte la propuesta que me mandó mi equipo de tecnología. Yo dirijo el negocio, no soy técnica, y tengo que decidir si apruebo este gasto. Haz esto: 1. Tradúceme cada término técnico a lenguaje de negocio. Sin condescendencia: explícame qué es y por qué importa para MI operación. 2. Dime qué me están pidiendo exactamente: cuánto cuesta, qué compra, y qué pasa si digo que no. 3. Lístame las 5 preguntas que debería hacerle a mi equipo antes de firmar. Preguntas que demuestren que entendí, no que los ponga a la defensiva. 4. Señálame qué parte de la propuesta está floja o vaga. Si algo suena a relleno para justificar el gasto, dímelo directo. 5. Al final, dame tu lectura en 3 frases: ¿esto se ve como una necesidad real o como algo que puede esperar? No asumas que la propuesta es buena solo porque suena técnica. [PEGA AQUÍ LA PROPUESTA]

Output esperado:Una traducción término por término a lenguaje de negocio, el resumen de qué te piden y cuánto cuesta, y las 5 preguntas para tu equipo. El detalle que más sirve es el punto 4: la AI suele detectar las partes vagas que tú intuías pero no sabías nombrar. Sandra Urena recomienda llevar esas 5 preguntas impresas a la reunión: cambia la dinámica de "firma aquí" a conversación entre pares.

No usar si: No lo uses como sustituto de una segunda opinión técnica real si el gasto es grande: la AI te ayuda a entender la propuesta, no a validar que el precio sea de mercado. Y no pegues cifras confidenciales de tu empresa con nombres reales; usa montos aproximados.

Devs

// Incidentes

Escribir un postmortem sin cacería de culpables

Cuando algo se cayó en producción y te toca escribir el postmortem antes de que la historia se convierta en "fue culpa de fulano".

CopiarTe voy a dar la cronología cruda de un incidente en producción. Ayúdame a escribir un postmortem blameless (sin señalar culpables) que sirva para aprender, no para castigar. Estructura que necesito: 1. Resumen ejecutivo: qué pasó, cuánto duró, a quién afectó. Máximo 5 líneas, para gente no técnica. 2. Cronología limpia: ordena mis notas en timeline con timestamps. Marca el momento de detección, de diagnóstico y de mitigación por separado. 3. Causa raíz: distingue entre el trigger (qué lo disparó) y las condiciones que lo hicieron posible. Casi nunca son lo mismo. 4. Reescribe cualquier frase mía que culpe a una persona ("X hizo deploy sin probar") como falla de sistema ("el pipeline permitió un deploy sin pasar por staging"). 5. Action items: cada uno con verbo, dueño sugerido por rol (no por nombre) y una forma de verificar que se hizo. 6. Pregúntame qué señales hubo ANTES del incidente que ignoramos. Esa sección casi siempre falta. Cronología cruda: [PEGA AQUÍ TUS NOTAS DEL INCIDENTE]

Output esperado:Un postmortem completo con las 6 secciones, listo para circular. Lo más valioso es el punto 4: ver tus propias frases reescritas de culpa-a-persona a falla-de-sistema te enseña a redactar así la próxima vez. La pregunta del punto 6 (señales ignoradas) suele sacar el action item más importante del documento.

No usar si: No lo uses si el incidente involucra un tema legal, de seguridad o de datos personales: eso primero pasa por tu equipo de legal/seguridad, no por un chat de AI. Tampoco pegues logs con credenciales, tokens o datos de clientes; limpia antes de pegar.

Zoomers

// Networking

Escribir un DM en frío que sí contesten

Cuando quieres escribirle a alguien que admiras (para chamba, mentoría o consejo) y llevas 20 minutos borrando el mensaje.

CopiarQuiero escribirle un mensaje en frío a esta persona: [DESCRIBE QUIÉN ES Y QUÉ HACE]. Lo que quiero de esa persona: [SÉ HONESTO: ¿consejo puntual? ¿que vea tu proyecto? ¿una vacante?] Lo que yo tengo para mostrar: [TU PROYECTO, PORTAFOLIO, O LO QUE HAYAS HECHO — aunque sea poco] Ayúdame así: 1. Antes de escribir nada, dime si mi petición es razonable para un primer mensaje. Si estoy pidiendo demasiado (ej. "30 minutos de tu tiempo" a un desconocido), proponme una petición más chica que sí pueda decir que sí. 2. Escribe 3 versiones del mensaje, máximo 80 palabras cada una. Cero halagos genéricos tipo "admiro mucho tu trabajo". Si menciono algo de esa persona, tiene que ser específico y demostrar que investigué de verdad. 3. Cada versión debe terminar con UNA petición concreta que se responde en menos de 2 minutos. 4. Dime cuál de las 3 mandarías tú y por qué. 5. Dame la regla de seguimiento: cuándo insistir una vez y cuándo aceptar que no va a contestar.

Output esperado:Tres versiones cortas y una recomendación de cuál mandar. El punto 1 es el que te salva: la mayoría de los DMs en frío mueren porque piden demasiado, no porque estén mal escritos. Achicar la petición a algo que se contesta en 2 minutos multiplica las respuestas.

No usar si: No lo uses para mandar el mismo mensaje a 30 personas cambiando el nombre: eso es spam y se nota a la primera línea. Este prompt funciona para UN mensaje investigado a UNA persona. Si no tienes nada que mostrar todavía, trabaja primero en eso; ningún mensaje bien escrito compensa un perfil vacío.

Devs

// Planeación

Estimar un feature con rangos, no con optimismo

Cuando te piden 'para cuándo está' y tu instinto es decir un número que sabes que no vas a cumplir.

CopiarVoy a estimar este feature y quiero que me obligues a ser honesto. Feature: [describe qué hay que construir] Stack: [tu stack] Lo que ya existe en el repo que puedo reusar: [lo que sepas] Lo que NO conozco todavía: [APIs externas, partes del código que no he tocado, etc.] Haz esto en orden: 1. Descompón el feature en tareas de máximo un día cada una. Si una tarea no cabe en un día, pártela. 2. Para cada tarea dame tres números: optimista, probable, pesimista. 3. Lista los supuestos que estoy haciendo sin darme cuenta. Cada supuesto que resulte falso, ¿cuánto agrega? 4. Señala la tarea con más incertidumbre y propón un spike (exploración corta con tiempo límite) para reducirla antes de comprometer fecha. 5. Dame la estimación final como rango, nunca como un solo número, y el texto exacto de una línea para comunicarla a mi jefe sin sonar evasivo. No me dejes responder 'depende'. Si falta un dato, pregúntamelo directo.

Output esperado:Una lista de tareas de tamaño día, cada una con tres escenarios de tiempo. Lo más útil es el paso 3: los supuestos ocultos que inflan o revientan la estimación (esa dependencia externa que 'seguro funciona'). Cierra con un rango defendible y la frase lista para decirle a tu jefe.

No usar si: No sirve si la spec todavía no existe: estimar humo da rangos de humo. Primero usa el prompt de convertir spec en tests o define el alcance. Tampoco lo uses para inflar estimaciones a propósito; el punto es honestidad, no colchón.

Señoras

// Decisiones

Interrogar un reporte antes de firmarlo

Cuando te entregan un reporte o análisis para tu aprobación y solo tienes 20 minutos antes de la junta.

CopiarTe voy a pegar un reporte que me entregaron para mi aprobación. Tu trabajo NO es resumirlo. Tu trabajo es ayudarme a interrogarlo antes de firmarlo. [pega el reporte — quita nombres de clientes y cifras sensibles si es confidencial] Dame: 1. Las 5 preguntas más incómodas que yo debería hacerle a quien lo escribió. Preguntas específicas de este documento, no genéricas. 2. Qué afirmaciones vienen SIN fuente o sin dato que las respalde. Cítalas textual. 3. Dónde hay conclusiones que no se sostienen con la evidencia que el mismo reporte presenta. 4. Qué falta: ¿qué esperarías ver en un reporte de este tipo que aquí no aparece? 5. Si el autor tuviera un incentivo para que yo apruebe esto rápido, ¿qué parte del documento lo delataría? Sé directa. Prefiero incomodidad ahora que firmar algo que no entendí.

Output esperado:Cinco preguntas puntuales para la junta, con la cita textual de las afirmaciones huérfanas de dato. El punto 5 es el que más valor da: te muestra dónde el documento empuja hacia el sí. Sandra Urena recomienda llegar a la junta con esas preguntas impresas y hacerlas en voz alta; la calidad de los reportes siguientes sube sola.

No usar si: No lo uses como sustituto de leer el reporte: la AI te da preguntas, no juicio. Si el documento tiene cifras confidenciales de tu empresa, anonimízalas antes de pegarlo o quédate solo con la estructura. Y si ya decidiste aprobar por política interna, este prompt solo te va a incomodar sin cambiar nada.

Zoomers

// Carrera

Convertir lo que hiciste en bullets de CV con números

Cuando tu experiencia es real pero en tu CV se lee como lista de tareas de escuela: 'apoyé en', 'participé en', 'ayudé con'.

CopiarVoy a contarte lo que hice en [prácticas / proyecto / trabajo actual] y quiero que me ayudes a convertirlo en bullets de CV que digan resultados, no tareas. Lo que hice, contado como me salga: [escríbelo sin filtro, aunque suene poca cosa] Proceso: 1. Por cada cosa que conté, pregúntame qué cambió gracias a eso: ¿cuánto tiempo se ahorró? ¿cuánta gente lo usó? ¿qué pasaba antes vs después? Hazme las preguntas una por una. 2. Si no tengo el número exacto, ayúdame a reconstruir un estimado honesto ('~15 horas al mes', 'unas 40 personas') — estimado se vale, inventado no. 3. Reescribe cada bullet con la fórmula: verbo fuerte + qué hice + resultado medible. 4. Marca cuáles bullets siguen débiles aunque los reescribas, para que yo sepa qué experiencia me falta construir. 5. Dame dos versiones de cada bullet: una para CV (corta) y una para contarla en entrevista (30 segundos, con contexto). No me infles. Un reclutador con experiencia huele los números falsos a la primera pregunta.

Output esperado:Bullets reescritos con resultado medible en lugar de 'apoyé en la elaboración de'. La parte que más trabaja es el paso 1: el interrogatorio te saca números que sí tenías pero nunca habías contado como logro. El paso 4 es un regalo extra: te dice qué tipo de experiencia buscar en tu siguiente proyecto.

No usar si: No lo uses para maquillar experiencia que no tienes: en la entrevista te van a pedir el detalle del número y ahí no hay prompt que te salve. Si todavía no has hecho nada medible, mejor usa primero el prompt de validar tu side hustle o busca un proyecto donde generar resultados reales.

Señoras

// Trámites

Redactar un reclamo formal que sí te contesten

Una empresa te cobró de más, te entregó mal o no cumplió, y llevas semanas dando vueltas por teléfono sin respuesta.

CopiarQuiero redactar un reclamo formal por escrito a una empresa. Ayúdame a armarlo paso a paso. Primero pregúntame, una por una, estas cosas antes de escribir nada: 1. Nombre de la empresa y qué servicio o producto contraté. 2. Qué salió mal, con fechas aproximadas. 3. Qué evidencia tengo (recibos, capturas, números de folio, nombres de quien me atendió). 4. Qué quiero exactamente: reembolso, reposición, cancelación sin penalización o una disculpa por escrito. 5. Cuánto tiempo estoy dispuesta a esperar respuesta. Con esas respuestas, escribe una carta de reclamo de máximo una cuartilla: - Tono firme y educado, sin amenazas ni insultos. - Hechos en orden cronológico, con fechas y folios. - Una sola petición clara al final, con fecha límite para responder. - Una línea que diga qué haré si no responden (por ejemplo, acudir a la instancia de protección al consumidor de mi país). Al final, hazme una pregunta: ¿qué dato de los que te di NO puedo comprobar con un documento? Ese es el que hay que quitar o suavizar antes de enviar.

Output esperado:Una carta de reclamo lista para copiar en un correo o imprimir, con los hechos ordenados, una petición concreta y una fecha límite. Lo más útil es la pregunta final: te obliga a quitar lo que no puedes probar antes de que alguien del otro lado lo use para desestimar todo el reclamo. Sandra Urena recomienda enviar el reclamo por un canal que deje registro escrito, nunca solo por teléfono.

No usar si: No lo uses si el problema ya está en manos de un abogado o de una autoridad. Ahí la carta la revisa quien lleva el caso, no la IA. Tampoco sirve si no tienes ningún comprobante: primero consigue el folio o el recibo, luego escribe.

Devs

// Code review

Que la IA revise mi diff antes que mi tech lead

Tienes un cambio listo para abrir el pull request y quieres cazar lo obvio antes de que lo cace alguien más.

CopiarActúa como revisor de código que quiere encontrar razones para rechazar este cambio. No seas amable, sé útil. Contexto del proyecto: [lenguaje, framework, qué hace el servicio en dos líneas] Qué se supone que hace este cambio: [una frase] Diff: ``` [pega aquí el diff completo] ``` Revisa en este orden y reporta solo lo que encuentres, sin relleno: 1. Bugs de lógica: casos donde el código hace algo distinto a lo que dice el objetivo. 2. Casos borde no cubiertos: entradas vacías, nulos, listas de un elemento, concurrencia (race conditions) si aplica. 3. Cambios de comportamiento que no están en la descripción del cambio. 4. Código muerto o gold-plating (funcionalidad que nadie pidió). 5. Qué prueba falta para que este cambio sea confiable. Formato por hallazgo: archivo y línea, qué está mal, por qué importa, cómo lo arreglarías en una línea. Ordena de más grave a menos grave. Si no encuentras nada grave, dilo sin inventar problemas. Cierra con una pregunta: ¿qué parte del diff NO entiendes lo suficiente como para revisarla bien? Esa parte la reviso yo a mano.

Output esperado:Una lista corta de hallazgos ordenados por gravedad, cada uno con ubicación y arreglo sugerido, más la lista de pruebas faltantes. No esperes que detecte todo: encuentra bien lo local, casos borde y lógica dentro del diff. La pregunta final marca las zonas donde la IA está adivinando, para que tú las revises antes de confiar en el resto. Sandra Urena recomienda correr este prompt antes de pedir revisión humana, no en lugar de ella.

No usar si: No sirve para cambios que dependen de contexto fuera del diff: migraciones de base de datos, integraciones con servicios externos o refactors grandes donde el problema está en lo que NO cambió. Ahí la IA solo ve la punta y opina con demasiada seguridad. Tampoco lo uses para aprobar un cambio: sirve para rechazar, no para dar visto bueno.

Cuarentones

// Carrera

Preparar la conversación de aumento con evidencia

Llevas años en el mismo puesto, sabes que aportas más de lo que te pagan y no has pedido aumento porque no sabes cómo abrir el tema.

CopiarVoy a pedir un aumento de sueldo y quiero prepararme como si fuera una negociación seria, no una súplica. Mi situación: - Puesto y años en él: [ ] - Qué hago hoy que no hacía cuando me contrataron: [lista] - Resultados que puedo demostrar con números o documentos: [ ] - Lo que sé del rango salarial de mi puesto en mi mercado, con fuente: [ ] (si no lo sé, dímelo y dime cómo averiguarlo) - Mi BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado), es decir, qué hago si me dicen que no: [ ] Con esto, ayúdame en cuatro bloques: 1. Separa mi lista en dos columnas: lo que puedo probar con evidencia y lo que solo es mi percepción. Lo segundo no va a la conversación. 2. Escribe un guion de apertura de máximo 5 frases: qué digo en los primeros 30 segundos para plantear el tema sin rodeos. 3. Anticipa las 3 objeciones más probables de mi jefe (presupuesto, momento, política de la empresa) y dame una respuesta corta para cada una. 4. Define un criterio de descarte (criterio de descarte (kill criteria)): qué respuesta o plazo significa que la empresa no va a moverse y que debo activar mi alternativa. No me des frases motivacionales. Dame material para la reunión.

Output esperado:Tu caso dividido en evidencia y opinión, un guion de apertura corto, tres respuestas a objeciones y un criterio claro de cuándo dejar de insistir. El bloque más valioso suele ser el primero: descubres cuánto de lo que querías decir no lo puedes sostener con datos. Sandra Urena recomienda llegar a esa reunión con tu alternativa real definida, porque sin ella no estás negociando, estás pidiendo.

No usar si: No lo uses como sustituto de averiguar tu valor de mercado. Si dejas vacío el campo del rango salarial, la IA no lo conoce y cualquier cifra que te sugiera es inventada. Tampoco sirve si la relación con tu jefe ya está rota: ahí el guion no arregla lo que el historial ya definió.

Señoras

// Finanzas personales

Entender un estado de cuenta que no te cuadra

Cuando llega tu estado de cuenta de la tarjeta, el banco o un servicio y hay cargos que no reconoces o no entiendes.

CopiarTe voy a pegar el texto de mi estado de cuenta. Ya le tapé el número de tarjeta, mi dirección y cualquier dato personal. Quiero que hagas esto, en este orden: 1. Haz una lista de cada cargo con fecha, concepto y monto, en lenguaje sencillo. Si un concepto viene en clave (por ejemplo, siglas raras), dime qué podría ser y aclara que es una suposición. 2. Separa los cargos en tres grupos: - Los que se ven normales (compras, pagos recurrentes). - Comisiones, intereses o cargos del banco. Explícame cada uno en una frase. - Los que no se pueden explicar con lo que te pegué. Márcalos como 'revisar a mano'. 3. Si hay intereses, explícame con mis propios números por qué aparecen. No inventes tasas: usa solo lo que viene en el documento. 4. Escríbeme 3 preguntas concretas para hacerle al banco por teléfono, empezando por el cargo más grande que no se entiende. Reglas: - No supongas montos ni fechas que no estén en el texto. - Si algo no se puede saber con lo que te di, dímelo directo. - Háblame claro, sin términos bancarios sin explicar. Aquí va el estado de cuenta: [PEGA AQUÍ EL TEXTO]

Output esperado:Una lista limpia de tus cargos traducida a español sencillo. Los cargos separados en normales, comisiones del banco y los que hay que 'revisar a mano'. Una explicación de los intereses usando solo tus números. Tres preguntas listas para leerle al banco, empezando por el cargo más grande que no se explica.

No usar si: No lo uses si no puedes tapar tus datos personales antes de pegar el documento. Tampoco sustituye la aclaración oficial: si hay un cargo que no reconoces, llama al banco el mismo día. La IA te ayuda a llegar con la pregunta correcta, pero no puede cancelar ni disputar nada.

Devs

// Code review

Revisar tu propio PR antes de pedir review

Justo antes de abrir un pull request, cuando quieres agarrar tus propios errores antes de que los vea tu equipo.

CopiarEres un reviewer senior, exigente y sin ganas de quedar bien. Te voy a pegar el diff de mi PR y una descripción corta de qué debería hacer. Objetivo del cambio: [DESCRIBE EN 2-3 LÍNEAS QUÉ RESUELVE] Revísalo así: 1. Pregunta inversa: ¿por qué rechazarías este PR? Dame las 3 razones más fuertes, ordenadas por gravedad. 2. Bugs probables: casos borde, nulls, errores no manejados, race conditions. Para cada uno, señala la línea y explica qué input lo rompe. 3. Lo que falta: tests que debería tener y no tiene. Escribe el nombre del test y qué valida, no el código completo. 4. Ruido: cambios que no tienen que ver con el objetivo y deberían ir en otro PR. 5. Una línea de veredicto: listo / casi / no lo mandes todavía. Reglas: - No me felicites. Si algo está bien, no lo menciones. - Si no ves suficiente contexto para juzgar algo (por ejemplo, una función que no está en el diff), dilo en lugar de suponer. - No propongas refactors grandes si no arreglan un problema real. Diff: [PEGA AQUÍ EL DIFF]

Output esperado:Las 3 razones más fuertes por las que alguien rechazaría tu PR: esa es la pregunta inversa, y suele sacar lo que tú no ves por cansancio. Bugs probables con la línea exacta y el input que los dispara. Una lista de tests faltantes, solo con el nombre y qué validan. Cambios que conviene sacar a otro PR y un veredicto de una línea.

No usar si: No lo uses con código propietario si tu empresa no permite pegar código en herramientas externas. Revisa esa política primero. Tampoco reemplaza al reviewer humano: el modelo solo ve el diff, no conoce el resto del repo ni las decisiones del equipo, así que va a fallar en todo lo que dependa de ese contexto.

Cuarentones

// Decisiones de carrera

Decidir si aceptas una oferta de trabajo

Cuando tienes una oferta sobre la mesa y no sabes si te conviene dejar un trabajo estable a estas alturas.

CopiarTengo una oferta de trabajo y necesito decidir si la acepto. No quiero que me motives, quiero que me ayudes a pensar. Mi trabajo actual: - Puesto y responsabilidades: [...] - Lo que me gusta: [...] - Lo que ya no aguanto: [...] - Sueldo y prestaciones (aproximado): [...] La oferta: - Puesto y responsabilidades: [...] - Sueldo y prestaciones: [...] - Lo que sé de la empresa: [...] - Lo que NO sé todavía: [...] Mi situación: [familia, deudas, ahorros en meses de gastos, salud, lo que pese]. Haz esto: 1. Antes de comparar, pregúntame hasta 5 cosas que te falten para dar una opinión seria. Espera mis respuestas. 2. Después, arma una tabla con lo que gano y lo que pierdo en cada opción, usando solo lo que te dije. 3. Dime cuál es mi BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado): qué pasa si digo que no. 4. Propón 3 criterios de descarte: cosas que, si resultan ciertas, deberían hacer que diga que no aunque el sueldo sea mejor. 5. Escríbeme las preguntas que le debo hacer a la empresa antes de firmar. 6. Cierra con tu postura en dos líneas. Sin esquivar con un 'depende'. No inventes datos de la empresa ni del mercado. Si algo no lo sabes, dilo.

Output esperado:Primero, hasta 5 preguntas para cubrir lo que te falta. Así no opina a ciegas. Una tabla de lo que ganas y pierdes en cada opción, con tus propios datos. Tu BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado) en claro y 3 criterios de descarte para no dejarte llevar solo por el sueldo. Las preguntas para la empresa antes de firmar y una postura de dos líneas. Sandra Urena recomienda responder primero las preguntas del paso 1 con honestidad, porque ahí se juega la calidad de todo lo demás.

No usar si: No lo uses para decidir por ti: la IA no conoce a tu familia, tu salud ni el ambiente real de la nueva empresa. Tampoco sirve si ya decidiste y solo buscas que alguien te dé la razón. Si respondes las preguntas acomodando las respuestas, te va a dar la razón y no vas a ganar nada.

Señoras

// Salud y citas

Llegar a tu cita médica con las preguntas listas

Cuando tienes una consulta en pocos días y sabes que en el consultorio se te olvida la mitad de lo que querías preguntar.

CopiarVoy a ir al médico y quiero aprovechar bien la consulta. No quiero que me diagnostiques nada. Ayúdame solo a ordenar mis ideas. Esto es lo que me pasa: - Síntoma o molestia: [descríbelo con tus palabras] - Desde cuándo: [aproximado] - Cuándo empeora o mejora: [ej. en la mañana, después de comer] - Medicamentos y vitaminas que tomo hoy: [lista, con dosis si la sabes] - Lo que más me preocupa: [en una frase] Con eso, hazme: 1. Un resumen de 5 líneas que pueda leerle al médico tal cual. 2. Las 5 preguntas más importantes que debo hacer, ordenadas de la más a la menos urgente. 3. Una pregunta inversa: algo que el médico probablemente me va a preguntar y que conviene que lleve respondido. 4. Un espacio en blanco al final para anotar lo que me diga. Usa palabras sencillas. Si algo de lo que escribí es confuso, pregúntame antes de armar la lista.

Output esperado:Una hoja corta que puedes imprimir o llevar en el celular. Un resumen claro de tus síntomas para no improvisar frente al médico. Cinco preguntas ordenadas por prioridad. La pregunta inversa: lo que te van a preguntar a ti, para que no te tome desprevenida. Sandra Urena recomienda llevar esta hoja impresa y pedirle al médico que te deje anotar sus respuestas ahí mismo.

No usar si: No lo uses para decidir si algo es grave ni para cambiar tus medicamentos. Si tienes dolor fuerte, falta de aire o cualquier síntoma de emergencia, no abras el chat: ve a urgencias o llama a tu médico.

Devs

// Code review

Encontrar lo que tus tests no están cubriendo en un PR

Antes de pedir review de un PR, cuando quieres que alguien busque cómo romper tu código y no solo cómo se ve.

CopiarActúa como un reviewer senior que no confía en mi código. Tu trabajo es encontrar cómo se rompe, no felicitarme. Contexto: - Qué hace este cambio: [1-2 frases] - Lenguaje / framework: [ej. Python 3.12, FastAPI] - Tests que ya escribí: [lista breve o pégalos] Código del diff: [pega aquí el diff] Devuélveme, en este orden: 1. Los 5 inputs o estados concretos que más probablemente rompen esto (nulos, vacíos, concurrencia, encoding, límites, timeouts). Para cada uno: qué pasaría y por qué. 2. Cuáles de esos 5 ya están cubiertos por mis tests y cuáles no. 3. El test que falta más importante, escrito y listo para pegar. 4. Una sola cosa que quitarías del diff porque es gold-plating o no hace falta para este PR. Reglas: no reescribas todo mi código. No inventes APIs ni funciones de librerías que no aparecen en el diff; si no estás seguro de cómo se comporta algo, dilo y márcalo como 'verificar a mano'.

Output esperado:Una lista de 5 casos que rompen tu código, cada uno con su explicación. Un cruce claro entre esos casos y tus tests: qué está cubierto y qué no. El test faltante más importante, listo para correr. Un recorte sugerido para que el PR quede más chico y más fácil de revisar.

No usar si: No pegues código con secretos, tokens o credenciales, ni código propietario si la política de tu empresa no permite usar herramientas externas. Tampoco sustituye la review de alguien que conoce el sistema: el modelo solo ve el diff, no el resto del repo ni cómo corre en producción.

Cuarentones

// Decisiones de carrera

Decidir si aceptas una oferta de trabajo sin autoengañarte

Cuando te llegó una oferta y llevas días dándole vueltas entre lo que ganas, lo que arriesgas y lo que te dice la emoción.

CopiarTengo una oferta de trabajo y necesito decidir con la cabeza fría. No me des ánimos ni me digas lo que quiero oír. Rétame. Mi situación actual: - Puesto y lo que me gusta / no me gusta: [describe] - Lo que gano hoy (total, no solo sueldo): [monto o rango] - Responsabilidades fuera del trabajo que pesan en esta decisión: [familia, deudas, salud, etc.] La oferta: - Puesto, empresa (tipo de empresa, sin nombre si prefieres) y lo que ofrecen: [describe] - Lo que no me han aclarado todavía: [lista] Haz esto: 1. Define mi BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado): qué pasa realmente si digo que no. 2. Dame 3 criterios de descarte (criterio de descarte (kill criteria)): condiciones que, si se cumplen, deberían hacerme rechazar la oferta sin importar lo demás. 3. Lista las 5 preguntas que debo hacerle a la empresa antes de firmar, empezando por lo que no me han aclarado. 4. Señala dónde crees que me estoy haciendo ilusiones según lo que escribí. 5. Termina con una recomendación clara: aceptar, negociar o rechazar, y qué dato me falta para estar segura o seguro. No inventes salarios de mercado ni datos de la empresa. Si necesitas un dato que no te di, pídemelo.

Output esperado:Tu BATNA (Best Alternative to a Negotiated Agreement / Mejor Alternativa a un Acuerdo Negociado) escrita en palabras simples, para que veas qué pasa si dices que no. Tres criterios de descarte concretos, no genéricos. Las preguntas que debes hacer antes de firmar, ordenadas por prioridad. Una lectura honesta de dónde te estás haciendo ilusiones. Una recomendación directa, sin esquivar con un 'depende'.

No usar si: No lo uses si todavía no tienes la oferta por escrito: el análisis queda tan flojo como los datos que le des. Tampoco sirve para comparar sueldos de mercado. El modelo no tiene esos datos confiables para tu país ni tu industria, así que eso investígalo por tu cuenta.