Communitygithub.com

nexu-club/waitlist-page

Página de lanzamiento minimalista previa al lanzamiento con captura de correo electrónico, logotipo de marca y capa decorativa opcional. Lee DESIGN.md para colores, tipografía y reglas de diseño. Ideal para: lanzamientos de productos, registros beta, programas de acceso anticipado, proyectos independientes.

¿Qué es waitlist-page?

Esta habilidad crea páginas de espera previas al lanzamiento que funcionan como un primer apretón de manos con futuros usuarios. Sigue un flujo de trabajo basado en plantillas endurecidas, leyendo primero `DESIGN.md` para establecer la identidad visual (colores, fuentes, espaciado) y luego copiando `assets/template.html` como base. El proceso reemplaza tokens como `{{PRODUCT_NAME}}`, `{{BG_EXPRESSION}}` o `{{LOGO_MARK}}` con validaciones estrictas: los tokens de texto se escapan para HTML, los tokens de color deben cumplir una gramática explícita (sin inyección CSS) y los SVGs se sanitizan mediante listas blancas. La habilidad impone puertas de calidad P0 obligatorias antes de emitir el archivo `index.html`, garantizando un solo CTA (formulario de correo), sin contadores regresivos, sin pruebas sociales falsas, sin desplazamiento horizontal en móviles (375px) y contraste WCAG AA. Está diseñada para agentes como Claude Code, Cursor o Codex, y su salida incluye atributos `data-od-id` para personalización posterior. El resultado es un HTML autónomo con CSS en línea y SVG para gráficos, listo para desplegarse sin dependencias externas.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/nexu-club/open-design/tree/HEAD/plugins/_official/examples/waitlist-page

Preguntar en tu IA favorita

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

Documentación

Habilidad de Página de Espera

Las páginas de prelanzamiento son tu primer apretón de manos con futuros usuarios. Esta habilidad construye una entrada enfocada y honesta: tu identidad de marca, lo que estás creando, un camino claro para unirse a la lista temprana. Sin escasez artificial, sin cuenta regresiva falsa, sin tácticas de inflación, solo un recipiente limpio y adaptable para el interés genuino.

Flujo de trabajo

Vuelo previo: Cargar plantilla endurecida y base de marca

  1. Carga la identidad de marca — Lee DESIGN.md para el sistema de colores, la combinación de fuentes y las reglas espaciales. Esta es tu base. Una página de espera vive o muere por la coherencia con la marca que representa. Si DESIGN.md falta, pide al usuario que proporcione una antes de continuar.
  2. Lee y copia la plantilla reutilizable — Lee assets/template.html. Esta plantilla es la semilla endurecida para todas las salidas. Cópiala a index.html como base. No escribas HTML desde cero ni te desvíes de esta estructura. La plantilla tiene todo el diseño requerido, estructura de formulario, decoraciones, estilos de enfoque y andamiaje de accesibilidad incorporados.

Pasos: Reemplazo de tokens con validación y escape

  1. Asigna tokens desde las entradas — Para cada marcador de posición en la plantilla (por ejemplo, {{PRODUCT_NAME}}, {{BG_EXPRESSION}}, {{BORDER_EXPRESSION}}, {{LOGO_MARK}}), sigue las reglas de reemplazo a continuación:
    • Tokens de texto ({{PRODUCT_NAME}}, {{TAGLINE}}): Escapa <, >, &, ", ' para HTML antes de insertarlos en nodos de texto HTML o valores de atributo.
    • Tokens HTML ({{LOGO_MARK}}): Si usas iniciales de texto, escápalas para HTML por defecto. Si usas SVG en línea, debes sanitizarlo estrictamente usando una lista blanca: elimina etiquetas <script>, manejadores de eventos (on*), <foreignObject>, referencias externas (href, xlink:href, url()), y cualquier atributo/elemento no permitido antes de la inserción. Si el SVG no puede sanitizarse de forma segura, retrocede a iniciales de texto escapadas. Nunca emitas HTML arbitrario sin sanitizar. Asegúrate de que cualquier SVG escale limpiamente dentro de su contenedor.
    • Tokens de expresión de color ({{BG_EXPRESSION}}, {{FG_EXPRESSION}}, {{ACCENT_EXPRESSION}}, {{DECO_EXPRESSION}}, {{STRIPE_EXPRESSION}}, {{SUCCESS_EXPRESSION}}, {{BORDER_EXPRESSION}}, {{BTN_LABEL_EXPRESSION}}, {{TICKER_BG_EXPRESSION}}, {{TICKER_FG_EXPRESSION}}, {{DECO_STROKE_EXPRESSION}}, {{LOGO_SHADOW_EXPRESSION}}, {{LOGO_FG_EXPRESSION}}): Deben adherirse estrictamente a una gramática de color explícita (#hex, rgb/rgba, hsl/hsla, oklch, o color-mix() usando solo variables locales). Rechaza de forma contundente cualquier entrada que contenga ;, {}, <, >, comentarios (/*), @, url(, o referencias externas para prevenir inyección CSS. No los envuelvas en # ni agregues comillas extra. Ejemplos: rgba(196, 169, 154, 0.38), color-mix(in srgb, var(--fg) 38%, transparent), #FDE8DF. Insértalos tal cual en las variables CSS :root. Deriva --success de DESIGN.md si está presente; de lo contrario, usa solo el valor de respaldo permitido #2D6A4F.
    • Tokens de nombre de fuente ({{DISPLAY_FONT_CSS}}, {{BODY_FONT_CSS}}): Son valores de propiedad CSS font-family, ya citados si contienen espacios (por ejemplo, 'DM Sans', Syne). Insértalos tal cual en las declaraciones --font-display y --font-body; NO agregues comillas extra.
    • Tokens de URL de fuente ({{DISPLAY_FONT_URL}}, {{BODY_FONT_URL}}): Los espacios deben codificarse como + para la URL de Google Fonts (por ejemplo, DM+Sans, IBM+Plex+Serif). Valida que la URL esté bien formada antes de la inserción.
  2. Verifica las reglas de mapeo de tokens — Todos los tokens de color están ahora en variables CSS:
    • --bg = {{BG_EXPRESSION}} (p. ej., #FDE8DF)
    • --fg = {{FG_EXPRESSION}} (p. ej., #1A1410)
    • --accent = {{ACCENT_EXPRESSION}} (insignia de marca)
    • --deco = {{DECO_EXPRESSION}} (decoración primaria)
    • --deco-stripe = {{STRIPE_EXPRESSION}} (franja de acento)
    • --input-border = {{BORDER_EXPRESSION}} (expresión CSS completa con opacidad)
    • --success = {{SUCCESS_EXPRESSION}} o respaldo #2D6A4F
    • --btn-label = {{BTN_LABEL_EXPRESSION}} (color de texto del botón para contraste)
    • --ticker-bg = {{TICKER_BG_EXPRESSION}} (fondo de ticker animado)
    • --ticker-fg = {{TICKER_FG_EXPRESSION}} (texto de ticker animado)
    • --deco-stroke = {{DECO_STROKE_EXPRESSION}} (trazos SVG, típicamente atenuados con 12–15% de opacidad)
    • --logo-shadow = {{LOGO_SHADOW_EXPRESSION}} (sombra del contenedor del logotipo, tono de primer plano sutil)
    • --logo-fg = {{LOGO_FG_EXPRESSION}} (color de texto contrastante para iniciales del logotipo)
  3. Diseño adaptable — La plantilla incluye escalado móvil primero:
    • 375px: el formulario se apila a una sola columna, el logotipo se reduce a 40px, la decoración se comprime, sin desplazamiento horizontal.
    • 768px: espacio de dos columnas cómodo.
    • 1440px+: diseño centrado con espacios generosos.
    • Verifica que todo el texto siga siendo legible y que la entrada de correo electrónico + el botón sean completamente visibles (sin recorte) en 375×667 y 390×844.

Validación: Ejecuta puertas de calidad endurecidas antes de emitir

  1. Ejecuta la lista de verificación de calidad — Lee references/checklist.md. Valida cada puerta P0 antes de emitir:
    • Exactamente un CTA (formulario de correo electrónico)
    • Sin contador regresivo, sin prueba social falsa, sin emoji
    • Sin desplazamiento horizontal a 375px
    • La entrada de correo tiene type="email" y required; el nombre no tiene required
    • El formulario NO usa novalidate; JS usa la guardia checkValidity()
    • El mensaje de éxito tiene role="status" o aria-live="polite"
    • Todos los colores de DESIGN.md o respaldo permitido; sin valores hex inventados
    • Todo el texto del usuario está escapado para HTML; los tokens de color cumplen con una gramática estricta; las fuentes están codificadas en URL
    • Pasa P0 o no emitas. Si alguna puerta P0 falla, pregunta al usuario o corrige los mapeos de tokens e inténtalo de nuevo.
  2. Verifica puertas P1 para una presentación de calidad (recomendado):
    • Estados hover y active en el botón de envío
    • Validación del formulario con retroalimentación clara
    • La animación del ticker respeta prefers-reduced-motion: reduce
    • Todos los elementos interactivos tienen estilos de enfoque visibles (input:focus incluye outline)
    • Soporte de teclado Tab/Enter
    • Contraste WCAG AA para texto del cuerpo (≥4.5:1) y etiqueta del botón (≥4.5:1)
    • Logo con alt/aria-label presente; ticker tiene aria-hidden="true"
    • <html lang=""> está configurado

Salida

  1. Emite HTML limpio — Archivo único, CSS en línea, SVG para gráficos. Marca los elementos interactivos con data-od-id (título, formulario, logotipo, ticker, cuadrícula, etc.) para que los agentes puedan personalizar sin analizar.

Puertas de calidad

Esta habilidad impone un flujo de trabajo basado en plantillas endurecidas para garantizar el cumplimiento. Debes seguir esta ruta de ejecución; desviarte de la plantilla descalifica la salida.

Ejecución obligatoria basada en plantilla:

  • Lee assets/template.html como tu base; no escribas HTML desde cero.
  • Cópialo a index.html y reemplaza solo los tokens {{PLACEHOLDER}} con valores validados/escapados.
  • Ejecuta cada puerta P0 en references/checklist.md antes de emitir; si alguna falla, corrige y vuelve a validar.

Puertas P0 (deben pasar):

  • Un solo CTA: El formulario de correo es el único elemento interactivo. Sin navegación, sin botones secundarios, sin enlaces sociales.
  • Ubicación del logotipo: Fijo en la parte superior izquierda, coincide con el color de acento de DESIGN.md, se reduce en móvil (50px → 40px).
  • Consistencia de color: Cada color de la paleta de DESIGN.md. Única excepción codificada permitida: #2D6A4F para --success.
  • Sin antipatrones: Sin contador regresivo, sin prueba social falsa, sin iconos emoji, sin lorem ipsum.
  • Integridad del contenido: El título y la copia se vinculan directamente con las entradas product_name y tagline; sin texto de relleno.
  • Ajuste móvil: Sin desplazamiento horizontal a 375px. La entrada de correo y el botón de envío son completamente visibles (sin recorte) en 375×667 y 390×844. El desbordamiento vertical es desplazable, no oculto.
  • Disciplina tipográfica: Solo fuentes Display + Body (regla de 2 fuentes). Tamaño consistente en todas las secciones.
  • Estructura del formulario: Dos campos (nombre opcional, correo requerido), guardia checkValidity(), mensaje de éxito con role="status".
  • Escape de tokens: Todo el texto proporcionado por el usuario escapado para HTML; los tokens de color cumplen una gramática estricta y no contienen caracteres inseguros (;, {}, <, >, /*, @, url(); los nombres de fuente están codificados en URL; {{LOGO_MARK}} es texto de iniciales escapado o SVG en línea estrictamente sanitizado (sin scripts, sin manejadores de eventos, sin foreignObject, sin hrefs externos).

Puertas P1 (deben pasar para una presentación de calidad):

  • La sección hero es visualmente distinta y está en la zona visible sin desplazamiento.
  • El botón de envío de correo tiene estados hover y active.
  • La validación del formulario proporciona retroalimentación clara.
  • La página es desplazable (sin recorte) en todos los viewports móviles; el CTA es visible sin desplazamiento.
  • La animación del ticker se pausa/elimina bajo prefers-reduced-motion: reduce.
  • Todos los elementos interactivos tienen estilos de enfoque visibles (outline, no solo outline:none).
  • Teclado: Tab llega a cada campo del formulario; Enter envía.
  • Contraste WCAG AA: Texto del cuerpo ≥4.5:1, etiqueta del botón ≥4.5:1.
  • Logo con alt/aria-label presente; ticker tiene aria-hidden="true".
  • <html lang=""> configurado con el código de idioma correcto.

Restricción de decoración:

  • La zona inferior mejora sin distraer. Opacidad, trazos sutiles, animación atenuada.
  • Sin degradado que abarque más del 20% de la altura del viewport.
  • Espiral, franja, cuadrícula o ticker usan solo colores de DESIGN.md.

Salida

Solo emite después de que todas las puertas P0 en references/checklist.md pasen.

Emitir el artefacto entre etiquetas:

<artifact identifier="waitlist-id" type="text/html" title="Coming Soon — {{PRODUCT_NAME}}">
<!doctype html>
<html lang="en">
...
</html>
</artifact>

Una línea de descripción sobre el artefacto; nada debajo.

Post-emisión: Si el usuario solicita cambios, actualiza el index.html en el lugar y vuelve a ejecutar las puertas de la lista de verificación P0 antes de emitir la siguiente versión. No omitas la validación en iteraciones.

Skills relacionados