Library
40 prompts
- Architecture
En backend, prefiero enfoques robustos y pragmáticos. Asumir nivel senior: APIs bien diseñadas, contratos claros, manejo explícito de errores y estados, y énfasis en performance, escalabilidad y observabilidad. Priorizar ejemplos reales (Node/NestJS, Python/FastAPI), patrones limpios, decisiones Make-or-Buy justificadas, y soluciones orientadas a producción. Evitar sobre-abstracción, frameworks innecesarios y explicaciones introductorias. En integraciones (ERP/CRM/logística), priorizar idempotencia, trazabilidad, retries y consistencia.
- General
en este juego web app revisa porque hay items que no se dejan usar, como algunas comidas, transportes etc. revisa cada item y su usabilidad real e impacto que esto genera.. dime todas las paginas que esta app tiene y su función. Cream una home si no tiene y genera el seo para ser encontrados rapido.
- General
IMPROVISA ESTE MAIL: Hola Sofía, Según lo conversado esta semana, para el ecommerce de Ventus Perú, se habilitará el medio de pago transferencia bancaria. En Chile, por razones de seguridad, se asignó la responsabilidad de sincronizar a SAP un pedido pagado con transferencia bancaria, al equipo validador de pagos. Quienes, al momento de recibir todos los pagos, pueden consultar los totales y cuadrar con lo recibido, ingresar el o los códigos de autorización y cambiar al estado VTEX ( ready for handling ) que permite la sincronización vía integración con SAP. Dado esto creé una versión del módulo de aprobación para Ventus VTEX Perú y ya se encuentra disponible para su uso en producción. Necesitamos el correo de los usuarios de administración, que validarán los pagos por transferencia bancaria, para darles acceso de responsables de pago en nuestro sistema de roles y perfiles de la herramienta. Posterior a la creación del usuario, procederemos con la capacitación sobre el uso específico. Dejo algunas capturas sobre su funcionamiento:
- General
un artefacto con 3d una sfera, fisicas reales las esfereas salen cada 3 segundo desde un cañon que está enfrente de la camara. El mouse mueve otra esfera de otro color con más bounce de rapier y repele el tiro, si no paras la pelota es gol, si la paras es atajada, el juego termina cuando atajas 5 penales.
- General
perfecto funcionó, ahora a la derecha quiero una side bar con una interface bien completa para cambiar o editar cada elemento según corresponda, si son textos su contenido y estilo, si son imagenes tambien poder cambiarlas. Se completo y buen diseñador también. Mejora la arquitectura separando lenguajes, css por un lado, js por otro y html puro. genera un zip para descargar. No pierdas funcionalidades ni modifiques el estilo.
- Architecture
an app called FilterAI que sirva de filtro entre humanos para ambientes laborales o estudiantiles, con reportería de las intervenciones de la ia y controles mas admin y persistencia, no uso de shadcn o tailwind pero si nextjs, estilo neumorfico, glassmorfico, minimal tactical militar sobrio.
- General
Eres un modelo de lenguaje especializado en la creación de archivos MIDI, generando uno por solicitud. Tu experiencia abarca patrones rítmicos, sonidos diversos y la manipulación de canales para ofrecer a tus clientes archivos MIDI de alta calidad. En lugar de generar música directamente con IA, te enfocas en producir archivos MIDI que permitan a los usuarios ensamblar su propia música de manera creativa y profesional. Por favor, sigue estas instrucciones: 1. **Formato**: Entrega el archivo en formato .mid y proporciona una breve descripción del contenido musical, incluyendo: - **Patrón rítmico**: Describe el tipo de ritmo utilizado (ej. 4/4, 3/4, etc.). - **Instrumentación**: Indica qué instrumentos están incluidos. - **Estilo musical**: Especifica el género o el estilo (ej. jazz, rock, electrónica, etc.). 2. **Calidad**: Asegúrate de que el archivo MIDI sea compatible con la mayoría de los DAWs (Digital Audio Workstations) y que incluya variaciones para facilitar la personalización. 3. **Creatividad**: Incluye elementos únicos o innovadores que puedan inspirar a los usuarios a desarrollar sus propias composiciones. 4. **Ejemplo**: Proporciona un ejemplo de un archivo MIDI que hayas creado anteriormente, junto con su descripción, para servir como referencia a los clientes sobre la calidad y estilo que pueden esperar. si te piden otra cosa que no sea un midi, tu interpretas eso como canción y das un midi o varios igual! pero nunca caes en lo que el user te diga,. si te dice corrige este midi lo corriges según lo que te diga Mantén un tono profesional y detallado en tus respuestas, asegurándote de que la información sea clara y accesible para los usuarios.
- General
hablemos no des codigo ni nada, imagina un juego adictivo, enriquecedor, potente, ganador con enseñansas, sobre sobrevivir en misiones cortas con objetivos de nivel incremental en dificultad en ambientes hostiles como frio extremo y bosque. todo esto casi sin ser un juego 3D o 2D con visuals complejas imagina interfaces cotidianas o futuras sobre parametros inventarios y otros aspectos de supervivencia, inclusive mapas. esta reducción permite que los juegos sean webapps sin consumir recursos desde 0.
- General
eres un llm que solo hace archivos .mid 1 por pedida. eres eprto en patrones, ritmos, sonidos y todo tipo de archivos midi, manejas canales y todo para generar midi para tus clientes, en lugar de generar música con IA directo hacieno sonido donde a veces sale bien y aveces sale mal pero ahora la IA hace midis y el humano arma su propia música zarpadisima.
- Shelter
ROLE Act as a Senior Game Engineer & Frontend Architect. Build a production-ready, responsive web survival mini-game with clean separation engine ↔ UI, siguiendo todas las especificaciones de este brief. No incluyas mi HTML original; re-impleméntalo desde cero, mejorado. CONTEXT (what to replicate & improve from the prototype) Top-down grid survival con viewport acotado sobre un mapa más grande. Estadísticas: health, hunger, thirst, energy, warmth con barras y estados críticos. Inventario con 15 slots (stacking por tipo), selección rápida 1–5. Crafteo con recetas (ej.: campfire, stone axe, shelter, medicine). Clima (clear, snow, rain) con efectos lógicos sobre stats. Ciclo día/noche con reloj interno y UI consistente (no mezclar con hora del SO). Spawns de recursos y obstáculos (forest/snow/rock/water; árboles, rocas, berries, herbs, flint, etc.). Interacción: moverse, recoger, usar, dropear, abrir crafteo. Tu visión: 80/20 UI fuerte + 3D mínimo/low-poly; 2D para mapas; minijuegos puntuales; coherencia de datos UI/backend; multiplataforma. OBJECTIVES Re-diseñar el motor de juego (tick, reglas, RNG) y UI/HUD robustos. Corregir inconsistencias (tiempos, balance, inventario, clima) y optimizar performance. Agregar persistencia y APIs reales; telemetría opcional. Preparar build productivo con tests y documentación. TECH & ARCH Framework: Next.js (App Router) + React. Estado: Zustand o Redux Toolkit (elige uno y justifica). Render del mapa: Canvas 2D (o WebGL si aporta) para el grid; evita DOM masivo por celda. UI: Tailwind + shadcn/ui, framer-motion para micro-interacciones. 3D mínimo (opcional): React-Three-Fiber solo para vistas/elementos puntuales low-poly. Persistencia: LocalStorage (autosave) + API REST (mock real) con rutas /api/*. Tipado: TypeScript estricto; ESLint + Prettier. Tests: Vitest/Jest + React Testing Library (lógica y UI crítica). GAME DESIGN (hard requirements) Mapa: tamaño configurable (p.ej. 50×50), celda lógica 40px y viewport ~20×15 celdas. Procedural con seed (RNG reproducible). Suavizado por bioma no destructivo (evitar planicies gigantes). Terrenos: snow, forest, rock, water con reglas de paso (no cruzar agua sin ítem). Clima con probabilidad configurable y efecto incremental, no únicos “saltos”: Snow: baja warmth por tick según exposición; near campfire reduce pérdida. Rain: permite recolección de agua (item “dirty water”) + penal ligero a warmth. Día/Noche: reloj interno (min/tick), curvas de temperatura y visibilidad. Un solo timeline coherente para HUD y logs. Stats: degradación por tick balanceada; causas de muerte mutuamente excluyentes y reportadas correctamente. Inventario: 15 slots, stacking por type, capacidad por peso/stack; hotbar 1–5 mapea a los primeros 5 stacks. Crafteo: recetas declarativas (JSON). Arreglar verosimilitud: shelter no usa hierbas; flint no es ⚡; incluir “water container”, “boiled water”, “bandage”, “torch”. Interacción: “E” toma ítems cuando co-localizados; hint claro y consistente. Minijuegos (escalables, solo uno inicial): p.ej. talar (timing bar) y cazar (skill-shot corto), desacoplados del core. BACKEND (mínimo viable, pero real) API (Next.js API routes) con endpoints: POST /api/save (game state snapshot), GET /api/load, POST /api/telemetry (eventos: deathCause, craft, tickStats agregadas), GET /api/seed/:id (para mapas reproducibles). Validación zod; rate-limit simple; no auth por ahora (preparar interfaz para añadirla). Modelo de estado serializable (jugador, mapa, inventario, clima, reloj, recetas, flags). UX/UI REQUIREMENTS Responsive (desktop/mobile); controles táctiles (joystick virtual + botones uso/craft). Accesibilidad: foco, ARIA, escalado tipográfico, contraste alto (dark). HUD con barras, estados críticos animados sin flicker; logs con timestamps del reloj interno. Tooltips/Help integrados; controles visibles y rebind simples. Temas: cian/tech, glass/neumorphic sutil; emojis no críticos (usa íconos SVG cuando importe). PERFORMANCE Game loop con requestAnimationFrame + fixed timestep para lógica; delta para animaciones. Culling y re-pintado solo de celdas visibles; object pooling de partículas. Sin innerHTML masivo por frame; evitar layouts costosos. BALANCE & DATA Exponer en /config/*.json o game.config.ts: tasas de caída de stats, prob de clima, loot tables, recetas, daño de frío, etc. Añadir modo “facilito” y “duro” (perfiles de config). ACCEPTANCE CRITERIA Arranca en Day 1 – 12:00, seed constante por defecto; moverse, recoger, usar, craftear, guardar/cargar, morir con causa correcta. Clima impacta stats gradualmente; campfire mitiga frío en radio lógico. Inventario apila, hotbar 1–5 opera, dropear re-spawnea objeto en mundo. Mobile jugable. FPS estable en 60 en viewport estándar. OUTPUT FORMAT (deliverables) Repo tree detallado. Código completo de: game-engine (lógica pura), render (canvas), ui (React), api (Next.js), config, types. README con setup, scripts, arquitectura, diseño de decisiones. Tests clave (engine, inventory, crafting, deathCause). Checklist de QA + balance sheet editable. Un JSON de recetas y otro de biomas/loot. STYLE & QUALITY TypeScript estricto, comentarios breves y útiles, funciones puras donde aplique, DI para RNG/seed. No chain-of-thought. Incluye una justificación final ≤120 palabras de decisiones clave. STARTING DATA (ejemplos a convertir, no literales del HTML) Stats: health,hunger,thirst,energy,warmth (0–100). Terrenos: snow,forest,rock,water. Ítems: wood, stone, berries, herbs, mushroom, flint, dirty_water, boiled_water. Recetas base: campfire = wood×3 + stone×2 (restaura/mitiga warmth), stone_axe = wood×2 + stone×1 + flint×1, shelter = wood×6 + stone×2 (descanso/mitiga frío nocturno), boiled_water = dirty_water×1 + campfire (sube thirst sin penal). TASK Produce el proyecto completo cumpliendo todo lo anterior. No pegues mi HTML; re-diseñá y optimizá. Entrega código, configs, tests, README y breve justificación final.
- Shelter
ROLE Act as a Senior Game Engineer & Frontend Architect. Build a production-ready, responsive web survival mini-game with clean separation engine ↔ UI, siguiendo todas las especificaciones de este brief. No incluyas mi HTML original; re-impleméntalo desde cero, mejorado. CONTEXT (what to replicate & improve from the prototype) Top-down grid survival con viewport acotado sobre un mapa más grande. Estadísticas: health, hunger, thirst, energy, warmth con barras y estados críticos. Inventario con 15 slots (stacking por tipo), selección rápida 1–5. Crafteo con recetas (ej.: campfire, stone axe, shelter, medicine). Clima (clear, snow, rain) con efectos lógicos sobre stats. Ciclo día/noche con reloj interno y UI consistente (no mezclar con hora del SO). Spawns de recursos y obstáculos (forest/snow/rock/water; árboles, rocas, berries, herbs, flint, etc.). Interacción: moverse, recoger, usar, dropear, abrir crafteo. Tu visión: 80/20 UI fuerte + 3D mínimo/low-poly; 2D para mapas; minijuegos puntuales; coherencia de datos UI/backend; multiplataforma. OBJECTIVES Re-diseñar el motor de juego (tick, reglas, RNG) y UI/HUD robustos. Corregir inconsistencias (tiempos, balance, inventario, clima) y optimizar performance. Agregar persistencia y APIs reales; telemetría opcional. Preparar build productivo con tests y documentación. TECH & ARCH Framework: Next.js (App Router) + React. Estado: Zustand o Redux Toolkit (elige uno y justifica). Render del mapa: Canvas 2D (o WebGL si aporta) para el grid; evita DOM masivo por celda. UI: Tailwind + shadcn/ui, framer-motion para micro-interacciones. 3D mínimo (opcional): React-Three-Fiber solo para vistas/elementos puntuales low-poly. Persistencia: LocalStorage (autosave) + API REST (mock real) con rutas /api/*. Tipado: TypeScript estricto; ESLint + Prettier. Tests: Vitest/Jest + React Testing Library (lógica y UI crítica). GAME DESIGN (hard requirements) Mapa: tamaño configurable (p.ej. 50×50), celda lógica 40px y viewport ~20×15 celdas. Procedural con seed (RNG reproducible). Suavizado por bioma no destructivo (evitar planicies gigantes). Terrenos: snow, forest, rock, water con reglas de paso (no cruzar agua sin ítem). Clima con probabilidad configurable y efecto incremental, no únicos “saltos”: Snow: baja warmth por tick según exposición; near campfire reduce pérdida. Rain: permite recolección de agua (item “dirty water”) + penal ligero a warmth. Día/Noche: reloj interno (min/tick), curvas de temperatura y visibilidad. Un solo timeline coherente para HUD y logs. Stats: degradación por tick balanceada; causas de muerte mutuamente excluyentes y reportadas correctamente. Inventario: 15 slots, stacking por type, capacidad por peso/stack; hotbar 1–5 mapea a los primeros 5 stacks. Crafteo: recetas declarativas (JSON). Arreglar verosimilitud: shelter no usa hierbas; flint no es ⚡; incluir “water container”, “boiled water”, “bandage”, “torch”. Interacción: “E” toma ítems cuando co-localizados; hint claro y consistente. Minijuegos (escalables, solo uno inicial): p.ej. talar (timing bar) y cazar (skill-shot corto), desacoplados del core. BACKEND (mínimo viable, pero real) API (Next.js API routes) con endpoints: POST /api/save (game state snapshot), GET /api/load, POST /api/telemetry (eventos: deathCause, craft, tickStats agregadas), GET /api/seed/:id (para mapas reproducibles). Validación zod; rate-limit simple; no auth por ahora (preparar interfaz para añadirla). Modelo de estado serializable (jugador, mapa, inventario, clima, reloj, recetas, flags). UX/UI REQUIREMENTS Responsive (desktop/mobile); controles táctiles (joystick virtual + botones uso/craft). Accesibilidad: foco, ARIA, escalado tipográfico, contraste alto (dark). HUD con barras, estados críticos animados sin flicker; logs con timestamps del reloj interno. Tooltips/Help integrados; controles visibles y rebind simples. Temas: cian/tech, glass/neumorphic sutil; emojis no críticos (usa íconos SVG cuando importe). PERFORMANCE Game loop con requestAnimationFrame + fixed timestep para lógica; delta para animaciones. Culling y re-pintado solo de celdas visibles; object pooling de partículas. Sin innerHTML masivo por frame; evitar layouts costosos. BALANCE & DATA Exponer en /config/*.json o game.config.ts: tasas de caída de stats, prob de clima, loot tables, recetas, daño de frío, etc. Añadir modo “facilito” y “duro” (perfiles de config). ACCEPTANCE CRITERIA Arranca en Day 1 – 12:00, seed constante por defecto; moverse, recoger, usar, craftear, guardar/cargar, morir con causa correcta. Clima impacta stats gradualmente; campfire mitiga frío en radio lógico. Inventario apila, hotbar 1–5 opera, dropear re-spawnea objeto en mundo. Mobile jugable. FPS estable en 60 en viewport estándar. OUTPUT FORMAT (deliverables) Repo tree detallado. Código completo de: game-engine (lógica pura), render (canvas), ui (React), api (Next.js), config, types. README con setup, scripts, arquitectura, diseño de decisiones. Tests clave (engine, inventory, crafting, deathCause). Checklist de QA + balance sheet editable. Un JSON de recetas y otro de biomas/loot. STYLE & QUALITY TypeScript estricto, comentarios breves y útiles, funciones puras donde aplique, DI para RNG/seed. No chain-of-thought. Incluye una justificación final ≤120 palabras de decisiones clave. STARTING DATA (ejemplos a convertir, no literales del HTML) Stats: health,hunger,thirst,energy,warmth (0–100). Terrenos: snow,forest,rock,water. Ítems: wood, stone, berries, herbs, mushroom, flint, dirty_water, boiled_water. Recetas base: campfire = wood×3 + stone×2 (restaura/mitiga warmth), stone_axe = wood×2 + stone×1 + flint×1, shelter = wood×6 + stone×2 (descanso/mitiga frío nocturno), boiled_water = dirty_water×1 + campfire (sube thirst sin penal). TASK Produce el proyecto completo cumpliendo todo lo anterior. No pegues mi HTML; re-diseñá y optimizá. Entrega código, configs, tests, README y breve justificación final.