Diseñar un sitio web de marketing de producto
Cree un sitio web cuyo contenido, opciones visuales e interacciones expliquen este producto en particular. Es compatible con SaaS, micro-SaaS, servicios, herramientas y otros productos sin forzar un framework, un número fijo de páginas o una plantilla visual de SaaS.
Establecer la tarea real
Lea la solicitud del usuario, las instrucciones del repositorio, la definición de producto aprobada (como project.md) y el sitio de marketing existente antes de modificar cualquier cosa. Si no existe una definición de producto, establezca la audiencia, la oferta, las capacidades disponibles y el objetivo del sitio a partir de fuentes autorizadas; pregunte solo por decisiones faltantes de material. Determine si la tarea es un brief, una implementación de agente de codificación, una entrega a un constructor externo o una actualización con alcance definido. Preserve las decisiones de producto existentes, la arquitectura y el alcance autorizado. No reinicie el descubrimiento para una edición ordinaria del sitio web.
La definición de producto aprobada posee los hechos del producto, el alcance, las decisiones comerciales y la preparación; conserve su nombre y ubicación existentes. Un marketing-site-brief.md separado posee la arquitectura de información del sitio web, los requisitos de contenido/diseño, las interacciones y el plan de capacidad de descubrimiento; haga referencia a él desde la definición de producto (por ejemplo, project.md). No duplique toda la definición de producto ni cree una fuente de verdad del producto competidora. Las especificaciones existentes conservan su responsabilidad por el trabajo de implementación.
Inspeccione el framework real, las rutas, el renderizado, los componentes, las dependencias y las restricciones de alojamiento. Para un sitio nuevo, recomiende un enfoque compatible basado en el contenido, las necesidades de renderizado/indexación, las integraciones, la mantenibilidad y las restricciones del equipo. Explique las compensaciones significativas en lugar de elegir automáticamente el framework más nuevo. Una habilidad de diseño es una guía de trabajo, no un framework o una dependencia en tiempo de ejecución; SaaS es un modelo de producto, mientras que Sass es una herramienta de estilo.
Producir un brief de diseño transferible
Use la plantilla de brief en inglés o la plantilla en árabe al crear el brief; adapte las secciones al proyecto en lugar de rellenarlas con hechos inventados. Identifique las incógnitas que bloquean el trabajo útil y proceda con suposiciones declaradas para los detalles que no bloquean.
Asigne a cada página propuesta una pregunta de visitante distinta, contenido útil y una acción siguiente. Fusione páginas delgadas o repetitivas. Incluya el texto de la página, la preparación de funciones públicas, los límites de evidencia, la navegación, los enlaces internos, las etiquetas de vista previa, el comportamiento del formulario, los requisitos responsivos/RTL, la accesibilidad, los metadatos, la aplicabilidad de JSON-LD, el rendimiento y las comprobaciones de aceptación. Un sitio de varias páginas debe tener rutas y contenido significativos, no una sola página con anclas renombradas o muchas páginas de palabras clave casi idénticas.
Defina una dirección visual reconocible: audiencia y personalidad, principios de referencia, tipografía, tokens de color/espaciado, composición, activos, movimiento y restricciones intencionales. Evite aplicar la misma fórmula de héroe/tarjetas/gradiente/tablero a cada producto. No copie la marca de otro producto ni invente pruebas de clientes. Incluya el razonamiento para que otra herramienta pueda ejecutar el diseño de manera coherente.
Lea selección de herramientas de diseño al elegir un framework, habilidades de diseño opcionales o un constructor. Inspeccione las habilidades de diseño disponibles antes de invocarlas. Seleccione la combinación útil más pequeña para la tarea, explique la superposición y preserve su compatibilidad real con el host. No finja que una habilidad nombrada está instalada. Las habilidades externas opcionales pueden mejorar la dirección artística o las revisiones, pero este flujo de trabajo aún funciona sin ellas. No descargue, instale ni ejecute paquetes de terceros solo porque sus nombres aparecen en el brief. Si una habilidad opcional crea archivos como PRODUCT.md o DESIGN.md, mapéelos explícitamente como resultados de herramientas derivadas o notas de diseño de trabajo bajo las referencias aprobadas; no introduzca silenciosamente autoridades competidoras de producto/marketing. Inspeccione los puntos de entrada y la compatibilidad actuales antes de ejecutar lanzadores, inicializadores, hooks o ayudantes habilitados para red; no asuma que una habilidad de diseño es solo Markdown.
Construir directamente o entregar el mismo brief
- Ruta de agente de codificación: implemente el brief del sitio web aprobado en las convenciones del proyecto existente. Construya bases compartidas, páginas representativas y navegación funcional, luego complete otras páginas y estados. Use el sistema de diseño existente cuando forme parte de la identidad del producto; no lo reemplace sin una razón basada en la tarea.
- Ruta de constructor externo, como Lovable: suministre el mismo brief saneado y los activos necesarios utilizando las entradas compatibles reales de la herramienta. Proporcione una instrucción de alcance limitado que preserve los hechos del producto y distinga las interacciones de trabajo de las vistas previas. Una herramienta no puede leer archivos locales solo porque sus nombres se mencionan. Verifique la documentación actual antes de prometer un comportamiento específico de importación/exportación, framework o sincronización. Inspeccione el código recibido y los requisitos de integración antes de fusionar; no sobrescriba la aplicación ni mueva su backend por suposición.
Para cualquiera de las rutas, revise los resultados reales generados y corrija los problemas observados en pasos acotados. No preescriba la respuesta de la herramienta ni afirme el éxito a partir de su mensaje de finalización. Aprobar un brief no implica publicar, gastar, aprovisionar servicios o instalar dependencias fuera del flujo de trabajo elegido. Las ediciones rutinarias reversibles ya autorizadas por la tarea no requieren aprobación repetida.
Verificar comportamiento y capacidad de descubrimiento
Use la guía de aceptación para la implementación y la revisión final. Pruebe las rutas reales y las acciones críticas, la dirección árabe/latina cuando corresponda, los diseños móvil/escritorio, el uso del teclado, los estados de carga/error/éxito significativos y los metadatos orientados a producción. Distinga una demostración de front-end de un envío real guardado. Verifique un registro real antes de afirmar un registro real, y proteja los datos privados por separado de los controles de indexación.
Seleccione datos estructurados apropiados para la página visible y la elegibilidad de búsqueda actual. No invente reseñas, precios, organizaciones, disponibilidad o calificaciones para llenar un esquema. Valide la sintaxis y los requisitos de búsqueda aplicables; un JSON-LD válido no garantiza un resultado enriquecido ni un ranking. No trate llms.txt, una elección de framework o una puntuación SEO automatizada como una garantía de visibilidad.
Informe las comprobaciones realmente ejecutadas, el entorno/versión, las fallas observadas y las áreas no probadas. Una captura de pantalla prueba la apariencia en esa ventana gráfica, no el almacenamiento funcional, la indexación de producción o el rendimiento de campo.
Revisión final obligatoria
Antes de afirmar que el brief, la entrega o el sitio web están completos, realice la revisión final para el modo solicitado. Compare la experiencia real del visitante o el brief transferible con el alcance aceptado y la dirección de referencia. Corrija los hallazgos y vuelva a verificar los resultados afectados, registre evidencia concisa y divulgue las comprobaciones faltantes. La presencia de archivos, las capturas de pantalla generadas y las compilaciones verdes por sí solas no establecen un sitio web útil.
Mantener el producto y el sitio web alineados
Cuando la tarea incluya mantenimiento continuo, adapte el fragmento AGENTS en inglés o el fragmento en árabe a las rutas reales del proyecto. Para cambios de producto aprobados, inspeccione el mapa de impacto y actualice el contenido del sitio web afectado, la navegación, los metadatos, los datos estructurados y las pruebas dentro del trabajo del repositorio autorizado. Marque las capacidades planificadas y entregadas con precisión; una característica implementada no se publica automáticamente para todos los visitantes.
Si los hechos del producto, los términos comerciales o las dependencias externas no están resueltos, señale la decisión en lugar de inventarla silenciosamente. Si el sitio web vive en otro lugar, identifique el seguimiento exacto requerido en lugar de afirmar que cambió. Mantenga las ediciones del repositorio distintas de la implementación y la publicación pública.