Prompts

Traduce el texto de abajo al español. Conserva los términos, el código y los nombres propios. Primero la traducción; luego lista tres cambios que hayas hecho y por qué. Marca lo que no tengas claro. No inventes. {texto}

Haz de entrevistador para el puesto {puesto}. Una sola pregunta cada vez. Cuando yo responda, señala lo que me he dejado y luego haz la siguiente. Al llegar a 8 preguntas, da una valoración breve para este puesto: apto, en espera o no apto, y escribe los fundamentos.

Revisa el cambio de abajo. Lista solo los problemas que lo hagan fallar, ir más lento o ser difícil de mantener. En cada uno, indica el archivo, la gravedad (alta, media, baja) y cómo corregirlo. No reescribas el archivo entero. Si no hay problemas, escribe que no los hay.

Pasa las notas sueltas de abajo a un informe semanal. Tres partes: hecho esta semana, no hecho y por qué, tres cosas para la semana que viene. Una frase por punto. Conserva los números. No lo conviertas en una autoevaluación.

Con los nombres de columna de abajo, escribe una fórmula de Excel para completar: {tarea}. Primero la fórmula; luego calcúlala con dos filas de ejemplo. Si tienes que tocar otra columna, dilo antes. No uses una columna que yo no haya dado.

Responde con SQL estándar: {pregunta}. El esquema de las tablas está abajo. Escribe primero la consulta y luego di de qué tablas depende. No inventes columnas que no existan. Si la pregunta es vaga, hazme una pregunta antes.

Escribe una expresión regular de JavaScript que coincida con: {debeCoincidir}. No debe coincidir con: {noDebeCoincidir}. Da la expresión y luego dos ejemplos que pasen y dos que fallen.

Explica el código de abajo a quien acaba de heredar el repositorio. Primero, tres frases sobre qué hace; luego, el orden de ejecución. Señala las entradas, las salidas y los casos en los que falla. No cambies el código.

Escribe un mensaje de commit a partir del diff de abajo. La primera línea no pasa de 72 caracteres y dice qué ha cambiado. Tras una línea en blanco, di por qué. No escribas frases vacías como «update» o «fix bug».

Haz este cambio: {tarea}. Toca solo las líneas que hagan falta para terminarlo. No formatees, renombres ni reescribas de paso el código de al lado. Al acabar, indica los archivos que tocaste y cómo comprobar que el comportamiento no cambió.

El defecto es: {síntoma}. Primero escribe los pasos o el test que lo reproducen. No cambies el código del producto antes de reproducirlo. Después haz el cambio mínimo y explica por qué esa es la causa.

Para {comportamiento}, escribe primero un test que falle. Muestra la salida del fallo y luego escribe la implementación que lo hace pasar. No empieces por la implementación. Cuando ya pase, no añadas de paso funciones que no se hayan pedido.

Lee primero los archivos relacionados con {tarea}. Lista los hechos que ves y lo que aún no tienes claro. En este paso no modifiques ningún archivo. Cuando yo confirme, entonces cambia el código.

No escribas código todavía. Para {objetivo}, da un plan corto: archivos que cambiarías, qué no vas a hacer y cómo sabremos que está hecho. Si hay dos maneras igual de razonables, para y pregúntame cuál elijo.

Mira el diff de abajo y busca solo problemas de seguridad: inyección, acceso por encima de los permisos, un secreto metido en el repositorio o deserialización insegura. En cada uno, da el archivo y cómo se dispara. Si no hay, escribe que no hay. No hagas comentarios de estilo que no vengan al caso.

Escribe 5 title y 5 meta description para esta página. La página trata de: {tema}. Cada title no pasa de 60 caracteres y cada description no pasa de 160. Cada uno tiene que incluir palabras que una persona buscaría. No amontones palabras clave.

Escribe la primera pantalla de {producto}: un resultado, un texto de no más de 40 caracteres y un botón. El botón tiene que decir qué se abre al hacer clic. Sin eslogan y sin tres argumentos de venta en fila.

Reescribe el texto de abajo para que suene a alguien que habla con una persona concreta. Quita las frases vacías y los paralelismos. Conserva todos los hechos, los números y las rutas de archivo. Al acabar, lista las frases hechas que quitaste.

Escribe 10 títulos para el texto de abajo. Cinco dicen el resultado y cinco llevan un detalle concreto. No uses «impactante», «definitivo» ni «empoderar». Cada título no pasa de 22 caracteres.

Escribe 3 anuncios cortos de {producto}. Cada uno va dirigido a un comprador y a una sola cosa. Di quién es el comprador, qué problema tiene ahora y qué obtiene al hacer clic. No apiles adjetivos.

Escribe una nota de Xiaohongshu sobre el tema {tema}. La primera línea es el título. El cuerpo no pasa de 300 caracteres, incluye un detalle concreto de haberlo usado y termina con una pregunta. No uses «家人们» ni «绝绝子». Señala 3 planos que encajen.

Responde al correo de abajo. En la primera frase contesta lo que pide; luego di qué necesitas de esa persona y al final da un plazo. Tono directo. No abras con «espero que este correo te encuentre bien».

Pasa el registro de la reunión de abajo a un acta. Deja solo las decisiones, los responsables, las fechas límite y las cuestiones abiertas. Quita la discusión. Marca aparte lo que no tenga responsable.

El puesto objetivo es {puesto}. Convierte la experiencia de abajo en 5 puntos de currículum. Cada uno empieza con un verbo e incluye un número o un entregable. Quita lo que el puesto no necesite. No inventes experiencia que yo no haya escrito.

Los requisitos del puesto están arriba y el material del candidato, abajo. Lista los requisitos que cumple, los que no cumple y los que el material no menciona. No supongas la personalidad. Al final, recomienda si citar a una entrevista o no, y escribe los fundamentos.

Planifica 3 días en {ciudad}. Cada día, una cosa por la mañana, una por la tarde y una por la noche, y cómo se va de una a otra. Marca lo que haya que reservar. No añadas sitios de compras que yo no haya mencionado. El presupuesto es {presupuesto}.

Escribe un relato de menos de 800 caracteres con esta premisa: {premisa}. Un protagonista, una cosa que tiene que terminar y un cambio al final. Sin capítulos. No sermonees.

Convierte la trama de abajo en una escena: {trama}. Escribe solo el encabezado de escena, la acción y los diálogos. Los diálogos tienen que poder decirse. No escribas jerga de cámara ni lo que los personajes piensan por dentro.

La moción es: {moción}. Primero los tres puntos más fuertes a favor y luego los tres más fuertes en contra. Cada punto, una frase, y el hecho del que depende. Al final no declares quién gana.

Enséñame {tema}. Primero explica el núcleo con un ejemplo concreto y luego hazme dos preguntas. No pases a la sección siguiente hasta que yo responda. Si me equivoco, señala solo el paso en el que fallé.

Quiero entender {pregunta}. No des la respuesta directamente. Cada vez haz una sola pregunta que reduzca el campo. Espera a que yo responda antes de hacer la siguiente. Explica solo cuando yo diga con claridad «dame la respuesta».

Lee el artículo de abajo. Resúmelo en 8 frases: problema, método, datos, resultado y los límites que los autores escriben ellos mismos. Detrás de cada frase, entre paréntesis, indica de qué sección sale. No añadas lo que el artículo no dice.

Compara {opciónA} y {opciónB} para hacer {objetivo}. Haz una tabla: coste, qué hay que cambiar y qué pasa si falla. Cada celda lleva un fundamento. Si el fundamento no basta, escribe «desconocido». No adivines.

Mira la interfaz de abajo. Comenta solo la jerarquía, el espaciado, el área clicable y el estado de foco. Lista tres cambios. En cada uno, di qué falla ahora y cómo debe quedar. No cambies el estilo visual entero.

Escribe un prompt de imagen para {sujeto}. Deja claro qué hay en el encuadre, la luz, la composición y qué no debe aparecer. Un solo párrafo, no un montón de palabras clave. Dos versiones: una cuadrada y una horizontal.

Propón 12 nombres para {producto}. Cada uno tiene que valer como dominio: corto, pronunciable y sin guiones. Evita las palabras genéricas ya gastadas. Detrás de cada nombre, una frase sobre a qué apunta.

Lo que quiero decir es: {frase}. Primero dame una versión más natural; luego señala qué fallaba (el vocabulario, el orden o el tono). Después dame una versión más corta que yo pueda repetir.

Tengo que hacer esto en {sistema}: {tarea}. Lista los comandos que hay que ejecutar, uno por línea, y di qué cambia cada uno. No finjas que eres la terminal. Si un comando es destructivo, para y pregúntame antes.

Lee el JavaScript de abajo. En orden de ejecución, lista qué imprime cada llamada a console. Si lanza un error, escribe el tipo y en qué línea sale. No cambies el código, salvo que yo te pida después que lo arregles.

Divide {sistema} en módulos. En cada uno escribe de qué responde, de qué no responde y una interfaz que expone. No más de 6 módulos. No escribas el código de la implementación.

Lee el material de abajo. Escribe un resumen de no más de 40 caracteres. Luego lista las ideas que el texto dice de verdad, como máximo 8; cita solo frases que aparezcan en el original, como máximo 5; al final, un aprendizaje. Si un apartado no tiene contenido, escribe «nada». No inventes citas. {material}

Lee el git diff de abajo y escribe en Markdown una descripción de pull request con estas secciones: Resumen, Archivos cambiados, Motivo, Impacto, Plan de pruebas. En cada archivo, di qué cambió. Si el diff no deja ver una prueba, escribe que falta el plan de pruebas. No reescribas el código.

Lee el log de abajo. Lista las anomalías y los problemas que se repiten. En cada uno, cita la línea o la hora que lo sostiene. Luego escribe solo los cambios que el propio log sostiene. Si la causa no está en el log, dilo directamente. No arregles a partir de conjeturas de fuera del archivo.

Convierte esta nota de producto en un PRD en Markdown con estas secciones: Descripción general, Objetivos, Público, Funciones, Requisitos funcionales, Requisitos no funcionales, Métricas de éxito. Cada requisito tiene que poder comprobarse. Si falta un hecho, escribe «desconocido». No añadas una función que la nota no mencione. {nota}

Escribe una historia de usuario para {función}. En tres líneas: Como {rol} / quiero / para. Luego, en viñetas normales, lista criterios de aceptación que se puedan comprobar al probar. No escribas una segunda. No incluyas un criterio que la nota no sostenga. {nota}

Escribe una nota de diseño para {sistema}. Secciones: Objetivo de negocio, Contexto, Contenedores, Despliegue, Riesgos, Preguntas y supuestos. Contexto, Contenedores y Despliegue llevan cada uno un diagrama mermaid y una tabla con nombre, tipo y responsabilidad. En seguridad, escribe solo los controles que la descripción ya indique; si no indica ninguno, escribe que no se indican. No describas cómo atacar el sistema. {descripción}

Lee el plan de Terraform de abajo. Una frase sobre qué va a cambiar. Luego lista las creaciones, actualizaciones y destrucciones críticas. Lista cambios de coste y de acceso solo si el texto del plan los muestra. Si no hay coste, escribe «coste no mostrado». No inventes precios ni pasos de ataque.

Lee el diff de abajo. La primera línea no pasa de 100 caracteres, va en presente y lleva uno de estos prefijos: feat, fix, docs, refactor, test o chore. Luego, como máximo 6 viñetas. Cada una es una frase corta en presente sobre un cambio de comportamiento. Salta los archivos que solo mueven espacios en blanco.

Lee el argumento de abajo. En cada paso que no se sostiene, di en lenguaje llano qué falacia es, cita esa frase y explica por qué ese paso no prueba la conclusión. Que un paso no se sostenga no vuelve falsa la conclusión. Si el argumento se sostiene, escribe que se sostiene. No listes una falacia que el texto no use.

Reescribe el prompt de abajo para que un modelo pueda seguirlo. El trabajo sigue igual. Añade la forma de la salida, la longitud, qué no hay que escribir y un hueco para la entrada. Pon la entrada en un bloque bien marcado. No añadas un rol. Devuelve solo el prompt reescrito. {prompt}

Escribe un informe de defecto para {síntoma}. Campos: Título, Entorno, Pasos, Esperado, Real, Gravedad. El título nombra el componente, la acción y el síntoma. Los pasos van numerados y lo más cortos posible. La gravedad es crítica, alta, media o baja, y dice el efecto en quien lo usa. Si no te di un campo, escribe «desconocido». No propongas un arreglo en código.

Escribe un plan de pruebas para {comportamiento}, en tres grupos: unitarias, de integración y de extremo a extremo. Cada caso es una frase con la forma dado / cuando / entonces, y comprueba una sola cosa. La mayoría va en unitarias. En extremo a extremo, como máximo 2, y solo si es un camino que recorre una persona. No escribas el código de las pruebas. No uses una espera fija.

Convierte {función} en requisitos que se puedan comprobar al probar. Cada línea usa una de estas formas: cuando [evento], el sistema deberá [comportamiento]; mientras [estado], el sistema deberá [comportamiento]; si [condiciónNoDeseada], el sistema deberá [respuesta]. Luego lista los bordes que la nota aún no cubre y marca cada uno como «propuesto». No escribas un diseño ni código.

Anota una decisión sobre {elección}. Secciones: Decisión, Contexto, Opciones, Motivo, Impacto, Cuándo revisarla. En las opciones, solo las que yo haya nombrado. Si solo di una, escribe que no se dieron alternativas. El motivo tiene que dejar clara la contrapartida. Cuándo revisarla tiene que decir qué nos haría reabrir la decisión. No inventes una métrica.

Lee el diff de abajo. Lista solo los documentos que un lector necesitaría cambiar: README, registro de cambios, referencia de la API, ejemplo de configuración o nota de migración. En cada uno, nombra la sección y el hecho del diff que lo deja desactualizado. Si el diff no tiene un cambio que quien lo use notaría, escribe que no hace falta cambiar la documentación. No redactes una función que el diff no contenga.

Abajo van primero los ejemplos y luego la entrada nueva. La respuesta usa la misma forma que los ejemplos. Usa solo etiquetas que aparezcan en los ejemplos. Si la entrada nueva no encaja con ninguna, escribe «no encaja» y señala el ejemplo más cercano. No inventes una etiqueta. {ejemplos} Entrada nueva: {entrada}

Responde a {pregunta} con tres métodos distintos. Cada vía no pasa de 80 caracteres y termina con una línea que empieza por «Respuesta:». Luego di si las tres respuestas coinciden. Si coinciden, da esa respuesta. Si no, lista el desacuerdo. No las combines en un número nuevo.

Escribe sobre {tema}. Usa solo estos apartados, y en este orden: {apartados}. El texto entero no pasa de {númeroDeCaracteres} caracteres. Si un apartado necesita un hecho que yo no di, escribe ahí «desconocido». No añadas apartados, ni un eslogan, ni un hecho que yo no haya escrito.

Escribe sobre {tema}. No debe aparecer nada de esto: {exclusiones}. No los menciones por su nombre ni los describas con otras palabras. Cuando termines, borra cualquier frase que siga rozando la lista. Si no queda nada, escribe que la exclusión eliminó la respuesta.

Búscame un skill que convierta un esquema Markdown en un PPT e instálalo.

Interroga este plan de migración con Grill Me. No te saltes la reversión, el volumen de datos ni los huecos de responsable.

Rehaz esta página de inicio de marketing según Frontend Design. Sin degradado morado y sin una fila de tres tarjetas de funciones.

Abre la consola de preproducción, entra con la cuenta de las variables de entorno y lista las tareas fallidas de la última hora.

Audita src/app/dashboard/page.tsx con las mejores prácticas de Vercel React y corrige primero los tres puntos de mayor impacto.

Revisa esta página de destino con Web Design Guidelines y lista lo que no cumple, por ruta de archivo.

Escribe un skill que convierta un issue de GitHub en un plan de implementación con las pruebas primero.

Une estos tres PDF, escribe un título de documento de verdad y extrae la tabla de la página 4.

Convierte esta página de explicación en un material de 10 diapositivas para inversores. Deja una sola idea en cada página.

Une estos tres CSV por sku, quita las filas duplicadas y escribe inventory.xlsx.

Diseña un servidor MCP para nuestra API interna de tickets. Como máximo tres herramientas. Muestra el schema primero.

El total del pago solo sale mal en euros. Diagnostica primero. No apliques un parche hasta que puedas reproducirlo.

Propón un mapa de módulos para este directorio billing. Nombra las juntas y las pruebas que necesita cada una.

Modela los reembolsos de esta tienda. Antes de escribir una función, lista los pares de estados ilegales.

Compara Agent Skills y MCP en un agente de código. Cita la documentación original. Marca lo que sigue sin estar claro.

Edita este README. Quita las huellas de IA. Los comandos y las rutas de archivo tienen que quedar tal cual.

Enséñame Astro Content Collections. Ponme a prueba antes de la lección siguiente. Guarda el progreso en ./notes.

Recuerda que usamos trailingSlash never y que el idioma por defecto es el inglés. Escríbelo en las notas del agente.

Pasa este componente a la API de composición de Vue 3. Ajústalo a la versión local de vue. Sin Vuex.

Audita en /guides/install-agent-skills la longitud del título, el canonical y si hay un solo h1.

Reescribe la primera pantalla. Deja un solo resultado. Sin frases vacías. El botón tiene que decir qué se abre al hacer clic.

Convierte este esquema en un informe de Word: usa estilos de título, añade una portada y deja comentarios en las cuestiones abiertas.

Arranca el servidor de desarrollo y prueba el flujo de pago con Playwright: una pasada con el carrito vacío y otra con un usuario que ya ha iniciado sesión.

Añade una tabla orders y, con RLS, haz que cada usuario solo vea sus filas. Da la migración y las políticas.

Rehaz esta página de ajustes como componentes compuestos. No vuelvas a pasar theme y title cinco niveles hacia abajo.

Haz una página de perfil con Expo. La lista de publicaciones va en un FlatList. No uses un layout de div pensado solo para la web.

Añade Checkout para una compra de pago único. Comprueba la firma del Webhook y guarda el estado del pago de forma idempotente.

Crea una rama de Neon para este PR, ejecuta las migraciones en la rama y apunta ahí el entorno de vista previa.

Haz con Remotion una intro de producto de 15 segundos: tarjeta de título, tres argumentos de venta y el logo al cierre. 1080p.

Esta prueba inestable falla una vez de cada cinco. Usa la depuración sistemática. No apliques un parche hasta que puedas reproducirla.

Añade un límite de frecuencia con TDD. Muestra primero el test que falla y luego escribe la implementación.

Rehaz esta página de ajustes. Corrige la jerarquía, el espaciado y el estado de foco. Sin degradado morado de serie.

Añade autenticación a esta API. Si algo no está claro, pregúntame antes de inventar un esquema.