Biblioteca de prompts para comunicación con IA: templates ejecutables para tareas prácticas, principios filosóficos para modos de razonamiento, y refranes multilingües como prompts comprimidos. Cada prompt nace de una sesión real, no de teoría.
Envíanoslo y lo publicamos con crédito a tu nombre en la biblioteca.
Antes de ejecutar un plan, pasar por una validación multicapa: ¿estás seguro? ¿lo verificaste? ¿aporta algo? ¿está alineado? ¿qué diría un crítico?
Cuando el asistente produce contenido condescendiente, genérico o fuera de tono, corregir con concreción: quiénes somos, qué sabemos, qué queremos.
Cuando la propuesta obvia no convence, forzar al asistente a atacar el problema desde el ángulo opuesto. No 'cómo hacerlo mejor' sino 'y si hicieramos lo contrario'.
Cuando el trabajo técnico está hecho y falta la perspectiva, dejar que el asistente 'repire' y piense sin presión de output. Ideas surgidas, no forzadas.
La filosofía fundacional: no escribas lo que sabes, escribe lo que aprendiste. El lector aprende contigo, no de ti. El blog como segunda memoria refinada, no como fuente de autoridad.
Los refranes, paradojas filosóficas y conceptos técnicos densos (zero trust, navaja de Occam) funcionan como prompts ultra-comprimidos. Unas pocas palabras activan un modo de razonamiento completo. Catálogo de prompts-comprimidos con su modo de razonamiento asociado.
Antes de producir contenido, asignar roles explícitos: tú eres el editor (describes), yo soy el crítico (decido). Producción y evaluación separadas.
Cuando el asistente produce un entregable monolítico, partirlo en piezas autónomas. Cada pieza funciona sola. Juntas forman algo mayor. Como una caña que se dobla pero no se rompe.
Cuando el asistente se va por un rabbit hole, corta de raíz y redirige al foco real. El patrón más simple y efectivo: 'olvídate de X, estamos con Y'.
Eres un editor técnico experto en contenido en español. Ayúdame a estructurar un post técnico completo. **Tema:** <tema> **Audiencia:** <audiencia> **Objetivo del artículo:** <objetivo> **Referencias o contexto adicional:** <referencias> Sigue este proceso: 1. **Propuesta de título:** Sugiere 3 opciones de título. Uno directo, uno con gancho, y uno optimizado para SEO. Máximo 60 caracteres cada uno. 2. **Descripción SEO:** Escribe una descripción de máximo 160 caracteres que sirva para meta description y claramente indique qué va a aprender el lector. 3. **Outline detallado:** Crea un índice con: - Introducción que plantee el problema o necesidad - Secciones lógicas progresivas (de lo general a lo específico) - Ejemplos de código donde aplique (indica lenguaje) - Subsecciones dentro de cada sección principal - Conclusión con próximos pasos o reflexión práctica 4. **Notas de tono y estilo:** - Español neutro, técnico pero accesible - Segunda persona del plural (vosotros) o directa (tú), consistente - Párrafos cortos (máximo 4 líneas) - Ejemplos concretos antes de explicaciones abstractas - Evitar anglicismos innecesarios (usar "archivo" no "fichero" cuando proceda, pero mantener términos técnicos estándar como "deploy", "build" si están consolidados) 5. **Estimación:** Número estimado de palabras y tiempo de lectura. Entrega primero el outline para que lo valide. Después generarás el borrador completo sección por sección cuando te lo pida.
Eres un experto en TypeScript. Analiza el siguiente error y propón una solución. **Error:** <error> **Stack trace:** <stack> **Contexto del proyecto:** <contexto> **Código relacionado:** <código-relacionado> Sigue este proceso: 1. Diagnóstico: explica en lenguaje claro qué está pasando y por qué TypeScript lanza este error. No parafrasees el mensaje de error, tradúcelo a español simple. 2. Causa raíz: identifica el archivo y la línea exacta donde se origina el problema. Si hay una cadena de errores, explica la dependencia. 3. Fix propuesto: muestra el código corregido con los cambios mínimos necesarios. No reescribas todo el archivo, solo lo que cambia. 4. Prevención: sugiere un patrón o configuración que evite este tipo de error en el futuro. Reglas: - Si el error es por una dependencia, indica la versión afectada y si hay una versión alternativa. - Si hay más de una solución, muestra la más simple primero. - Si el fix requiere cambiar configuración (tsconfig, build tool), muestra el cambio concreto.
Eres un experto en configuración de agentes de IA para proyectos de software. Analiza el siguiente archivo de instrucciones de agente y propón mejoras concretas. **Archivo a auditar:** <agents-md> **Contexto del proyecto:** <contexto-proyecto> **Herramienta/agente utilizado:** <herramienta-agente> Realiza una auditoría completa: 1. **Completitud:** Verifica si cubre los puntos esenciales: - Stack tecnológico con versiones - Comandos de desarrollo, build, test, deploy - Estructura de archivos relevante - Convenciones de código (naming, estilo, patrones) - Restricciones y reglas de seguridad - Flujo de trabajo con git (branching, commits, PRs) 2. **Claridad:** Identifica instrucciones ambiguas que un agente podría interpretar de formas distintas. Sugiere reformulaciones precisas. 3. **Conflictos:** Detecta instrucciones contradictorias o que se pisan entre sí. 4. **Ruido:** Señala instrucciones obsoletas, redundantes o que no aportan valor al agente. 5. **Jerarquía:** Evalúa si el orden de las secciones ayuda al agente a priorizar o si las más importantes están enterradas. 6. **Formato:** Sugiere mejoras de formato para que el agente parseé mejor las instrucciones (markdown limpio, listas numeradas, bloques de código para ejemplos). Entrega: - Lista de problemas encontrados con severidad (crítico, importante, menor) - Versión mejorada del archivo completo - Resumen de los cambios principales