Carousel Studio

Guillermo Casaus

@_guillecasaus

Si todavía programas sin Claude, estás perdiendo horas cada semana. Con los prompts adecuados, puedes acelerar todo tu flujo de desarrollo. Aquí tienes 8 prompts que deberías conocer 👇

Apply Image

Guillermo Casaus

@_guillecasaus

1/ El Validador de Arquitectura Este prompt hace que Claude revise toda la arquitectura de tu proyecto antes de escribir una sola línea de código. Prompt: "<task> Revisa la arquitectura de mi [tipo de proyecto] y proporciona un análisis completo </task> <context> <tech_stack> [Tus tecnologías: por ejemplo, React, Node.js, PostgreSQL, Redis] </tech_stack> <current_structure> [Pega la estructura de carpetas o describe tu arquitectura actual] </current_structure> <requirements> - Debe soportar [X] usuarios concurrentes - Necesita incluir [funcionalidades específicas] - Planificado para escalar hasta [escala objetivo] </requirements> </context> <output_format> 1. Fortalezas de la arquitectura (qué funciona bien) 2. Cuellos de botella críticos (qué fallará al escalar) 3. Vulnerabilidades de seguridad (qué puede salir mal) 4. Mejoras recomendadas (cambios concretos y accionables) 5. Prioridad de implementación (qué arreglar primero) </output_format> <constraints> - Enfócate en soluciones listas para producción - Ten en cuenta los costes - Prioriza mantenibilidad frente a código “ingenioso” </constraints> "

Guillermo Casaus

@_guillecasaus

3/ El Maestro del Diseño de APIs Este prompt diseña APIs listas para producción que realmente tienen sentido. Lo he usado en 8 proyectos distintos. Cero breaking changes. Prompt: "<api_design_task> Diseña una API REST completa para [tu producto o funcionalidad] </api_design_task> <business_requirements> <core_functionality> [Qué debe hacer esta API. Sé específico sobre las acciones del usuario] </core_functionality> <data_relationships> [Cómo se relacionan las entidades: Usuarios → Posts → Comentarios, etc.] </data_relationships> <scale_expectations> - Requests por segundo esperadas: [número] - Volumen de datos: [cantidad] - Distribución geográfica: [regiones] </scale_expectations> </business_requirements> <design_constraints> - Debe ser RESTful (sin atajos) - Autenticación: [JWT / OAuth / etc.] - Rate limiting: [requisitos] - Estrategia de versionado: [URL / headers / etc.] </design_constraints> <deliverables> 1. Lista completa de endpoints con métodos HTTP 2. Esquemas request/response en JSON 3. Manejo de errores con códigos de estado 4. Diagrama del flujo de autenticación 5. Estrategia de rate limiting 6. Recomendaciones de esquema de base de datos 7. Estrategia de caché para endpoints de lectura </deliverables> <success_criteria> La API debe ser tan intuitiva que un frontend pueda usarla sin hacer preguntas. </success_criteria> </api_design_task> "

Guillermo Casaus

@_guillecasaus

BONUS🪙 Por cierto, Microsoft acaba de lanzar un Certificado Profesional de Python con 6 cursos completos para aprender desde cero y aplicarlo en proyectos reales. Si estás aprendiendo programación, guárdalo porque merece mucho la pena 👇 <a target="_blank" href="https://x.com/_guillecasaus/status/2006319438447133124" color="blue">x.com/_guillecasaus/…</a>

Guillermo Casaus

@_guillecasaus

4/ El Genio del Refactor Convierte código legacy en código limpio, sin romper nada. Usado para refactorizar una app Node.js de 5 años, cero bugs en producción. Prompt: "<refactoring_request> Refactoriza este código para que sea apto para producción manteniendo exactamente el mismo comportamiento </refactoring_request> <current_code> [Pega aquí tu código desordenado] </current_code> <context> <current_issues> [¿Qué problemas ves? ¿Lento? ¿Difícil de testear? ¿Lógica confusa?] </current_issues> <constraints> - No se puede cambiar el comportamiento externo de la API - Debe mantenerse compatibilidad hacia atrás - Se deben añadir tests después </constraints> </context> <refactoring_priorities> 1. Legibilidad (cualquier dev debe entenderlo en 30 segundos) 2. Rendimiento (identificar y corregir cuellos de botella) 3. Testabilidad (facilitar unit tests) 4. Manejo de errores (sin fallos silenciosos) 5. Seguridad de tipos (añadir TypeScript si aplica) </refactoring_priorities> <output_requirements> - Mostrar comparación antes / después - Explicar CADA cambio importante - Señalar posibles breaking changes (incluso sutiles) - Proporcionar guía de migración si cambia alguna estructura - Incluir análisis de impacto en rendimiento </output_requirements> <testing_guide> Incluye también 3–5 tests que demuestren que el código refactorizado funciona igual. </testing_guide> </refactoring_request> "

Guillermo Casaus

@_guillecasaus

5/ El Optimizador de Base de Datos Pasé de consultas de 8 segundos a 200 ms usando este prompt. Claude detecta problemas de índices que los humanos suelen pasar por alto. Prompt: "<database_optimization> Optimiza mis consultas y esquema de base de datos para rendimiento en producción </database_optimization> <current_situation> <schema> [Pega tu esquema de base de datos: tablas, columnas, relaciones] </schema> <problematic_queries> [Pega las consultas lentas con salida de EXPLAIN ANALYZE si la tienes] </problematic_queries> <performance_metrics> - Tiempo actual de consulta: [tiempo] - Tiempo esperado: [objetivo] - Frecuencia de consultas: [llamadas por segundo] - Volumen de datos: [filas en las tablas relevantes] </performance_metrics> </current_situation> <optimization_scope> 1. Recomendaciones de índices (qué falta, qué sobra) 2. Reescritura de consultas (SQL más eficiente) 3. Mejoras de esquema (decisiones de normalización / desnormalización) 4. Estrategias de caché (qué cachear, dónde y cuánto tiempo) 5. Recomendaciones de particionado (si aplica) </optimization_scope> <analysis_requirements> - Explica la causa raíz de la lentitud - Muestra el impacto de rendimiento de cada cambio - Ten en cuenta el equilibrio entre lectura y escritura - Considera el crecimiento de datos en los próximos 2 años </analysis_requirements> <deliverables> 1. Lista priorizada de cambios (mayor impacto primero) 2. Scripts de migración (sentencias ALTER TABLE) 3. Planes de ejecución antes / después 4. Mejora estimada de rendimiento </deliverables> </database_optimization> "

Guillermo Casaus

@_guillecasaus

6/ El Auditor de Seguridad Este prompt me salvó dos veces. Claude encontró vulnerabilidades que mi equipo no vio en el code review. Prompt: "<security_audit> Realiza una auditoría de seguridad completa de mi base de código </security_audit> <code_to_audit> [Pega autenticación, autorización, manejo de datos, endpoints de la API] </code_to_audit> <application_context> <type>[App web / API / Backend móvil / etc.]</type> <sensitive_data>[¿Qué datos de usuario manejas?]</sensitive_data> <compliance_requirements>[GDPR / HIPAA / PCI-DSS / etc.]</compliance_requirements> <current_security_measures>[JWT, HTTPS, rate limiting, etc.]</current_security_measures> </application_context> <audit_checklist> 1. Vulnerabilidades de autenticación (contraseñas débiles, sesiones) 2. Fallos de autorización (escalado de privilegios, IDOR) 3. Validación de entradas (SQL injection, XSS, command injection) 4. Exposición de datos (logs, respuestas, errores) 5. Problemas criptográficos (algoritmos débiles, gestión de claves) 6. Seguridad de la API (rate limiting, CORS, bypass de auth) 7. Vulnerabilidades en dependencias (paquetes obsoletos) 8. Problemas de configuración (modo debug, endpoints expuestos) </audit_checklist> <output_format> Por cada vulnerabilidad encontrada: - Severidad: [Crítica / Alta / Media / Baja] - Ubicación: [archivo y línea exacta] - Escenario de explotación: [cómo lo atacaría un atacante] - Solución: [cambio exacto de código] - Prevención: [cómo evitar este patrón en el futuro] </output_format> <priorities> Enfócate en vulnerabilidades que puedan causar: 1. Fugas de datos 2. Secuestro de cuentas 3. Pérdidas económicas 4. Incumplimientos legales </priorities> </security_audit> "

Guillermo Casaus

@_guillecasaus

7/ El Generador de Tests Pasé de 0% a 80% de cobertura en una sola tarde. Claude escribe mejores tests que muchos devs junior. Prompt: "<test_suite_generation> Genera una batería completa de tests para este código </test_suite_generation> <code_to_test> [Pega tus funciones, clases o módulos] </code_to_test> <context> <testing_framework>[Jest / Mocha / PyTest / etc.]</testing_framework> <mocking_library>[Si es necesaria]</mocking_library> <current_coverage>[Qué está ya cubierto]</current_coverage> </context> <test_requirements> 1. Tests unitarios (cada función por separado) 2. Tests de integración (componentes funcionando juntos) 3. Casos límite (null, vacío, valores extremos) 4. Casos de error (cuando algo falla) 5. Tests de rendimiento (si aplica) </test_requirements> <test_quality_criteria> - Cada test debe tener UN objetivo claro - Los nombres deben leerse como documentación - Usar patrón arrange–act–assert - Mockear dependencias externas correctamente - Tests deterministas (sin valores aleatorios ni tiempos) - Casos positivos y negativos </test_quality_criteria> <deliverables> 1. Archivo(s) de tests completos con imports y setup 2. Descripción de qué valida cada test 3. Estimación de cobertura (% de rutas cubiertas) 4. Instrucciones para ejecutar los tests 5. Recomendaciones para integración CI/CD </deliverables> <special_focus> Presta especial atención a: - Condiciones límite - Concurrencia (si aplica) - Validación de datos - Reglas de negocio complejas </special_focus> </test_suite_generation> "

Guillermo Casaus

@_guillecasaus

8/ El Generador de Documentación Convirtió un caos sin documentar en algo que mi equipo realmente entiende. Mejor que cualquier desarrollador con el que haya trabajado. Prompt: "<documentation_task> Crea documentación lista para producción para esta base de código </documentation_task> <code_context> <codebase> [Pega archivos clave: lógica principal, rutas de API, algoritmos complejos] </codebase> <project_info> - Nombre del proyecto: [nombre] - Propósito: [qué problema resuelve] - Usuarios objetivo: [quién lo usa] - Stack tecnológico: [tecnologías] </project_info> </code_context> <documentation_requirements> <readme_structure> 1. Visión general del proyecto (qué es y por qué) 2. Funcionalidades (lista clara) 3. Instalación (paso a paso) 4. Configuración (variables de entorno) 5. Ejemplos de uso (código real) 6. Documentación de la API 7. Arquitectura (cómo funciona) 8. Guía de contribución 9. Resolución de problemas comunes </readme_structure> <code_comments> - Añade comentarios en lógica compleja - Explica el POR QUÉ, no el QUÉ - Documenta parámetros y valores de retorno - Incluye ejemplos en usos no evidentes </code_comments> <api_documentation> Para cada endpoint: - Propósito - Autenticación requerida - Formato de request (con ejemplo) - Formato de response (con ejemplo) - Errores posibles (códigos HTTP) - Límites de uso </api_documentation> </documentation_requirements> <audience_considerations> Escribe pensando en: - Nuevos miembros del equipo (onboarding en 1 hora) - Tu yo del futuro (6 meses después) - Colaboradores open source (si aplica) </audience_considerations> <output_format> 1. <a target="_blank" href="http://README.md" color="blue">README.md</a> completo 2. Documentación inline en el código 3. <a target="_blank" href="http://API.md" color="blue">API.md</a> (si aplica) 4. <a target="_blank" href="http://CONTRIBUTING.md" color="blue">CONTRIBUTING.md</a> (si es open source) 5. Descripción del diagrama de arquitectura </output_format> <quality_standards> - Lenguaje claro y sencillo - Ejemplos reales y funcionales - Sin información obsoleta - Fácil de escanear (títulos, listas, bloques de código) </quality_standards> </documentation_task> "

Guillermo Casaus

@_guillecasaus

BONUS🪙 Obtén las últimas noticias sobre inteligencia artificial y marketing digital. Tips, guías prácticas y mucho más. Únete ahora👇 <a target="_blank" href="https://gdnagency.com/newsletter-gpt/" color="blue">gdnagency.com/newsletter-gpt/</a>