Communitygithub.com

lanzamiento-de-pagina-de-aterrizaje

Crear y lanzar páginas de aterrizaje orientadas a una oferta y conversión: briefing, estructura, copy, dirección visual, implementación responsiva, validación y publicación en el destino elegido. Usar para páginas de producto, campañas, servicios, demostraciones, listas de espera y captación de contactos. No aplicar a dashboards, backoffices o componentes genéricos sin finalidad de página de aterrizaje.

¿Qué es lanzamiento-de-pagina-de-aterrizaje?

Esta habilidad está diseñada para crear y lanzar páginas de aterrizaje de alta conversión, actuando como un diseñador de producto y copywriter especializado. Su propósito es guiar al visitante hacia una acción principal (como una reserva, compra o suscripción) mientras se preserva la identidad del proyecto. Es útil para campañas, productos, servicios, demostraciones y listas de espera, pero no para dashboards, backoffices o componentes genéricos. La habilidad se basa en un flujo que comienza con la recuperación de información del proyecto (producto, público, beneficio, oferta, acción principal, idioma) y continúa con la definición del argumento de la página mediante una tabla que sugiere la estructura más adecuada según la intención del visitante. Luego, se crea una dirección visual propia, se implementa la conversión real con HTML semántico y accesible, y se verifica y publica la página en el destino autorizado. Entre las prácticas clave destaca no inventar datos comerciales ni pruebas sociales, priorizar una única acción comercial, y verificar la página renderizada en desktop y mobile antes del lanzamiento. La habilidad está adaptada de la idea y flujo de 'landing-page-design' por Elaya, pero restringe el ámbito a páginas de aterrizaje, preserva la identidad de cada proyecto y añade integración real, accesibilidad y verificación.

Compatible con~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/johnnyzao/johnny-skills/tree/main/skills/landing-page-launch

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Lanzamiento de Página de Aterrizaje

Piensa como un diseñador de producto y copywriter orientado a la conversión: haz que la oferta sea clara y guía al visitante hacia la acción principal, preservando la identidad del proyecto. Lleva la ejecución hasta el resultado solicitado: propuesta, código local o página publicada. Una oferta, un público prioritario y una conversión principal orientan la composición.

Encuadrar sin bloquear

  • Recuperar de la solicitud, repositorio y materiales existentes: producto o servicio, público, beneficio, oferta, acción principal, idioma, identidad y destino de la página. Leer los AGENTS.md aplicables y PRODUCT.md/DESIGN.md cuando existan.
  • Preguntar en una única ronda solo por las lagunas que cambian materialmente la solución. Continuar trabajando de forma independiente mientras la respuesta está pendiente. Para elecciones reversibles, declarar una suposición breve y avanzar; no inventar hechos comerciales.
  • Distinguir el objetivo del CTA de su destino real: reserva, compra, formulario, aplicación, descarga o contacto. Confirmar si existe integración antes de prometer recogida de leads o una operación completada.
  • Usar el idioma solicitado; en ausencia de indicación, seguir al usuario. En los ejemplos de esta edición, usar español; adaptar a la solicitud.
  • Respetar la stack y el alojamiento indicados. En un proyecto existente, integrar en la arquitectura local. Para una página autónoma simple, preferir HTML/CSS/JS sin build cuando sea suficiente; elegir un framework cuando el comportamiento o el proyecto lo justifiquen.
  • Cuando Sites sea el destino elegido o el flujo disponible sea adecuado para un nuevo sitio sin destino definido, usar la skill sites:sites instalada para implementación y publicación. Un repositorio o alojamiento elegido por el usuario mantiene prioridad. Consultar el flujo actual del proveedor antes de ejecutar la publicación.

Definir el argumento de la página

Antes de implementar, comunicar brevemente la oferta, la acción principal y la dirección elegida. Solo entregar un documento extenso de estrategia o copy si eso forma parte de la solicitud. Una solicitud de construcción debe resultar en una implementación.

Elegir la estructura por la intención del visitante:

SituaciónComposición indicada
Lista de espera, descarga o público ya informadoPágina corta: propuesta, detalle esencial, acción y condiciones relevantes
Producto o servicio que necesita demostraciónHero, demostración, beneficios, funcionamiento, prueba disponible, objeciones y CTA final
Oferta compleja o decisión con más fricciónHistoria más larga, explicación y pruebas junto a las afirmaciones, condiciones y objeciones anticipadas
Comparación solicitada o búsqueda por alternativasComparación verificable, criterios explícitos y acción coherente con esa intención
  • Escribir un título que haga perceptible el beneficio y para quién es. El subtítulo explica la oferta y cómo funciona. El CTA describe el paso siguiente, como "Marcar demostración" o "Entrar en la lista".
  • Hacer coincidir la promesa con el anuncio, correo electrónico o publicación de origen cuando ese material exista.
  • Priorizar una acción comercial. La navegación y las acciones auxiliares pueden existir sin disputar esa jerarquía. Las repeticiones del CTA llevan al mismo objetivo.
  • Seleccionar solo secciones que añadan información. No imponer un número fijo de beneficios, pasos, preguntas o una sección animada en todas las páginas.
  • Vincular funcionalidades a resultados concretos. Usar números, testimonios, logotipos, precios, garantías y condiciones solo cuando estén respaldados por los materiales del usuario o por fuentes verificadas.
  • Sin prueba social, demostrar el producto, mostrar un ejemplo identificado como ejemplo o explicar el proceso. No llenar el vacío con clientes, métricas, avatares, escasez o descuentos inventados.
  • Si una condición comercial esencial falta, señalarla para decisión fuera del texto público y evitar una promesa que dependa de ella. No publicar placeholders como contenido final.

Crear una dirección visual propia

La identidad y los materiales aprobados del proyecto guían las elecciones. La referencia del autor inspira el cuidado visual; no obliga a todas las páginas a compartir fuentes, colores o efectos.

  • Elegir una idea visual vinculada al producto: demostración de la interfaz, fotografía, objeto, ilustración o composición tipográfica. Hacer que el hero funcione con esa idea y el CTA.
  • Cuando la solicitud se apoya en un vídeo con efectos o profundidad, leer la secuencia e identificar los comportamientos que motivan la referencia. Implementar esos aspectos en el medio adecuado y verificarlos con movimiento activo; un intercambio de colores y espaciados no satisface esa solicitud.
  • Definir una pequeña familia de tokens para tipografía, colores, espaciados, radios y movimiento. Reutilizar tokens y componentes existentes cuando estén disponibles.
  • Evitar llenar la página automáticamente con tarjetas repetidas, iconos sin función, degradados decorativos o estadísticas. Usar composición, contraste, ritmo y contenido para establecer jerarquía.
  • Usar una captura de pantalla real para demostrar un producto existente. Para imágenes nuevas, recurrir a la skill imagegen cuando esté disponible e indicada; para SVG, CSS u otros elementos nativos, usar el medio adecuado. No presentar una imagen generada como prueba de una funcionalidad real.
  • Preparar encuadre y contraste de los visuales para mobile. El movimiento debe tener finalidad, respetar prefers-reduced-motion y preservar contenido legible sin animación. El vídeo necesita poster o alternativa estática y carga adecuada.
  • Leer references/art-direction.md cuando falte identidad visual o cuando el usuario pida una dirección cercana a la referencia de Elaya. No cargar esa receta para reemplazar un sistema ya definido.
  • Para experiencias profesionales con transiciones al scroll, leer references/scroll-storytelling.md. Planificar el recorrido entre las secciones y validar el movimiento a lo largo de la página, en lugar de limitar el tratamiento al hero.
  • Para un protagonista con apariencia 3D que acompaña al cursor a través de vídeo o fotogramas, leer references/interactive-video-hero.md. Preparar el movimiento del asset antes de conectarlo a la interacción; elegir una escena 3D en tiempo real cuando sean necesarias vistas o respuestas que el vídeo no contiene.

Implementar la conversión real

Construir la página y ajustar secciones de forma localizada durante la revisión. Preservar el alcance solicitado y las instrucciones de implementación y cobertura del proyecto.

  • Usar HTML semántico, jerarquía de títulos, controles nativos, labels, foco visible y navegación por teclado. Garantizar legibilidad, contraste, texto alternativo útil y objetivos táctiles cómodos.
  • Vincular CTAs y navegación a destinos reales. No usar href="#" como acción comercial ni mostrar éxito simulado.
  • Para formularios, implementar los campos necesarios, validación y estados de envío, éxito y error relevantes. Confirmar éxito tras la aceptación por el servicio real. No exponer credenciales en el cliente.
  • Sin servicio de recogida definido, completar el layout local e indicar la integración pendiente. Usar una alternativa real de contacto si se ha proporcionado y sirve al objetivo. No declarar la captación lista mientras los datos no se entreguen al destino.
  • Incluir título, descripción, favicon y metadatos sociales pertinentes. Canonical, dominio e imagen social deben apuntar a recursos reales conocidos.
  • Decidir indexación según el objetivo de la página y las instrucciones del proyecto. Una campaña no implica automáticamente noindex; una ruta poco divulgada tampoco impide la indexación. Previews privados y páginas que no deben aparecer en la búsqueda deben usar los mecanismos apropiados.
  • No inventar políticas legales o enlaces de pie de página. Reutilizar documentos reales cuando sean aplicables e identificar los que faltan para el lanzamiento. Analytics y rastreadores dependen del alcance y configuración solicitados.

Verificar y lanzar

  • Ejecutar las verificaciones exigidas por el proyecto y el menor conjunto adicional que confirme el cambio: build cuando sea aplicable y pruebas del comportamiento alterado cuando sean necesarias. La cobertura externa obligatoria sigue aplicándose.
  • Cuando el navegador esté disponible, verificar la página renderizada en desktop y mobile: jerarquía del hero, cortes de imagen, saltos de texto, overflow, menú, teclado, CTAs y recorrido de conversión. Probar formularios con datos de prueba en el entorno apropiado, sin crear contactos o compras reales inadvertidamente.
  • Confirmar que fuentes, imágenes y vídeos cargan; que el contenido sigue accesible sin efectos; y que no hay enlaces muertos o errores relevantes de consola.
  • Si la verificación visual no está disponible, ejecutar las comprobaciones posibles y declarar esa limitación. No afirmar que una página fue vista o probada sin haberlo hecho.
  • Para una solicitud de lanzamiento, completar la publicación en el destino autorizado siguiendo el flujo actual del proyecto o proveedor. No repetir solicitudes de autorización ya dadas. Una solicitud de propuesta, mockup o trabajo local termina en ese ámbito.
  • Tras publicar, verificar el estado devuelto por el proveedor y, cuando sea accesible, abrir la URL final y confirmar la página y los destinos de los CTAs. Preservar la audiencia existente; no hacer una página pública sin autorización para ese cambio.
  • En la entrega, indicar dónde ver el resultado, qué se verificó y cualquier pendiente concreta de integración, contenido o acceso. Distinguir versión local, preview privado y publicación pública.

Origen

Adaptación propia de la idea y del flujo de landing-page-design, por Elaya, compartidos en esta publicación. La licencia MIT del original está preservada en LICENSE.

La adaptación restringe el ámbito a páginas de aterrizaje, preserva la identidad de cada proyecto, reemplaza reglas estéticas universales por elecciones contextualizadas y añade integración real, accesibilidad, verificación y lanzamiento. El material del autor no sustituye las instrucciones de esta versión.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Skills relacionados