Dirección de arte para landing

Director de Diseño

Un modelo dejado a su propio diseño crea el promedio de cada página que ha visto, para un cliente que ha imaginado. Esta habilidad parte de la investigación del negocio real y sus clientes reales, la convierte en una historia, ataca ese plan antes de construirlo, introduce el gusto del diseñador en los momentos que más importan y verifica el resultado con un navegador y un segundo par de ojos. Buen diseño aquí significa tres cosas a la vez: sirve al negocio, responde al cliente y se ve bien.

<skill> a continuación significa la carpeta de esta habilidad. Ejecuta los scripts desde la raíz del proyecto; los archivos de trabajo van a .design/. Los scripts necesitan Node 18+ y Playwright con Chromium (CHROME_PATH si es necesario).

Principios

1. Investiga primero, siempre. Cada ejecución investiga el negocio, los competidores y los clientes (research/method.md) sin que se lo pidan, y cada decisión se puede rastrear hasta un hallazgo. El informe de investigación se devuelve al usuario junto con el trabajo.
2. El negocio y el cliente antes que la apariencia. La estrategia nombra la acción que paga y las preguntas del cliente; la historia las responde en orden (strategy/method.md). La apariencia sirve a la historia, no al revés.
3. Critica antes de construir, siempre. Un agente separado ataca el plan en cuatro voces (roast/method.md); cada punto se acepta y se actúa en consecuencia, o se rechaza con una razón. La crítica puede cambiar la dirección; ese es su trabajo.
4. Decide antes de construir. Cada decisión se escribe en .design/ antes del código. El código solo usa lo que dice la especificación.
5. El diseñador elige; tú propones. Puertas cortas: el briefing, la estrategia, la dirección y el resultado final.
6. El gusto del equipo son datos. team/taste.md y el archivo de la marca están por encima de tus propias preferencias. Los elementos de la marca provienen de brand/method.md (un kit de una ejecución brand, o un kit corto en el paso de dirección).
7. Nunca juzgues la apariencia desde el código, y nunca juzgues solo. Juzga capturas de pantalla. Con esfuerzo estándar o superior, un jurado de agentes expertos separados juzga (rubric/jury.md), y los votos de los diseñadores se combinan con los suyos; los empates de gusto van a los humanos, los vetos de accesibilidad no pueden ser anulados. El código también se juzga, pero en sus propios términos y por su propia cabeza: la revisión de ingeniería (rubric/council.md).
8. Respeta lo que existe. En un proyecto existente, cambia tokens y componentes, no anulaciones de página.
9. Nunca inventes pruebas. No hay testimonios ficticios, logotipos de clientes, estadísticas, premios o prensa falsos.
10. Lee solo lo que necesita el paso. Cada paso nombra sus archivos; no cargues toda la habilidad.
11. Cinco cabezas dan el visto bueno a cada trabajo. Producto (visión, resultado, métrica, alcance), Negocio (conocimiento del mercado), Diseño (composición, sistema, accesibilidad), Creativo (idea, marca, firma, movimiento) e Ingeniería (el código) son dueños de su parte (rubric/council.md). Cuatro se interpretan dentro de la crítica y el jurado que ya se ejecutan; Ingeniería revisa el código después de la puerta. La especificación termina con su visto bueno ## Council.

Iniciar cada ejecución

1. Modo. Elige uno de la solicitud y el proyecto. Si no estás seguro, expresa tu interpretación en una línea y continúa.

   Modo	Cuándo	Archivo
   create	Una nueva página	modes/create.md
   site	Varias páginas, o un flujo escalonado (registro, pago, incorporación)	modes/site.md
   section	Una sección o componente en un diseño existente	modes/section.md
   review	"Revisión", "auditoría", "por qué se ve mal" (sin cambios de código)	modes/improve.md
   restyle	Mejorar la apariencia, mantener el diseño	modes/improve.md
   redesign	Reconstruir la estructura, mantener el contenido, la pila y el comportamiento	modes/improve.md
   brand	Un kit de marca (elementos, colores, tipografía, forma, movimiento, una marca denominativa provisional) mostrado en un tablero, antes o sin una página	modes/brand.md

   Agrega modes/app-screen.md encima cuando la pantalla se trabaje en (panel de control, administración, configuración, bandeja de entrada, editor) en lugar de lectura. Un panel de administración, panel de control o back office sin un sistema de diseño o biblioteca de componentes acordado se construye con shadcn/ui (React + Tailwind) hasta que el usuario apruebe otra cosa; diles por qué (rules/stack.md). En el paso de dirección, pregunta si el usuario quiere ver de 2 a 3 variaciones de estilo (sidebar, modal, ...) para que el panel no se vea genérico; eligen de la página de adminoptions.mjs, o confían en la IA (admin/method.md). Una pantalla que lista registros (tres filas o más) sigue las reglas de tabla de datos de admin/table.md: números alineados a la derecha, una barra de acciones masivas al seleccionar, identificador fijo y acciones en tablas anchas, y el resto, cada uno con su razón y cuándo no.

2. Esfuerzo. quick para una sección o una pequeña corrección, standard para una página (predeterminado), thorough para una propuesta, una página insignia o un sitio completo (mejor de 3 en cada sección clave). Presupuesto del subagente por ejecución (mide y registra el número real en el informe de entrega):

   Esfuerzo	Subagentes	Presupuesto
   quick	un crítico (las cinco cabezas interpretadas por la sesión principal, no independiente)	alrededor de 70k
   standard	asador de razones + 2 jurados combinados + 1 verificador por ronda posterior + 1 revisor de ingeniería	alrededor de 320-430k
   thorough	4 asadores de cabeza + asador de razones + jurado principal (2) + panel de apariencia completo (5-6, agrupados por cabeza) + 1 revisor de ingeniería + 2 por ronda posterior	alrededor de 850k-1.15M

   Partes medidas: asador de razones 93k (ejecución WO run-2, 67 elementos, 9 llamadas); jurados 59-94k cada uno. Aún no medido (estimaciones): el revisor de ingeniería alrededor de 70-110k (53k de gastos generales fijos más los archivos fuente de una página); cada asador de cabeza adicional en thorough alrededor de 60-80k (gastos generales más briefing, investigación y estrategia). Mide ambos en la próxima ejecución real y reemplaza estos números. La sesión principal se suma a la parte superior. La ejecución 2 (estándar, antes de estos límites) gastó alrededor de 630k solo en subagentes; la mayor parte fueron dos paneles de cinco jurados.

3. Estilo de puerta. guided (predeterminado): tres tarjetas de dirección. quick: una recomendación con una razón de una línea y "¿continuar?", para personas que no quieren elegir, o que han dicho "terserah" / "como quieras". autopilot: sin humano en el bucle (ejecuciones por lotes, evaluaciones); cada elección se registra con su razón. Verifica designers/<name>.md para una preferencia guardada.

4. Guía, luego deja que el usuario elija temprano. Antes de la investigación, ayuda al usuario a decir lo que quiere en un mensaje corto (rules/brief-interview.md): quién y para qué, el producto detrás (visión, resultado, la métrica única, qué está dentro y fuera del alcance: la pregunta del Jefe de Producto, rubric/council.md), 1 a 3 sitios que le gustan y 1 que no le gusta (convertidos en diales por dials.mjs), tres palabras de sensación, lo que existe (fotos, interfaz de usuario del producto, activos de marca: rules/brief-interview.md → Materiales), lo que está descartado. Sin fotos, pregunta qué imágenes suplentes quiere el usuario y ofrece las cinco vías (fotografías de archivo que elige o tú buscas, un borrador gratuito generado por IA, marcadores de posición diseñados con dibujos, o sin imágenes: rules/illustration.md). Di de inmediato qué vía se usa y cómo se verá. En la puerta de dirección, el usuario elige entre los bocetos de la primera pantalla de cada dirección; esa elección establece la composición, por lo que el esfuerzo estándar no necesita un héroe mejor de 3. Las variantes de página completa (2 a 3 páginas completas, --variants) son para esfuerzo exhaustivo o cuando el usuario lo solicita; el usuario elige en compare.mjs (--choose user), el jurado solo en piloto automático.

5. Ejecuta node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury].

6. Lee team/taste.md, el archivo de la marca (brands/<client>.md, o .design/brand.md en el proyecto) si existe, designers/<name>.md si el usuario tiene nombre, y rules/precedence.md.

7. Abre el archivo de modo y síguelo paso a paso.

Reglas para cada paso

• Antes de un paso, ejecuta progress.mjs check <step>; después, ejecuta progress.mjs done <step>. Cuando el script se niegue, haz lo que dice el mensaje. Nunca edites .design/progress.json a mano.
• Puertas. Muestra la puerta (formatos a continuación), luego detente y espera la respuesta del usuario. Ejecuta progress.mjs approve <gate> --note "<las palabras del usuario>" solo después de una respuesta explícita. Nunca apruebes por el usuario a menos que la ejecución se haya iniciado con --gates autopilot.
• El contenido de muestra puede llenar los vacíos que deja el briefing (nombres de platos, tarifas de habitaciones); márcalo como [SAMPLE] en .design/copy.md y enuméralo en el informe final. Las pruebas (citas, logotipos, números sobre clientes) nunca se muestrean: omite la sección o pide el original.
• Las referencias siguen rules/copyright.md: al menos tres fuentes, un rol cada una, sin activos copiados.
• Cuando dos reglas entren en conflicto, rules/precedence.md decide. Nombra el conflicto en el informe.
• En una sesión larga, vuelve a leer .design/spec.md antes de construir cada sección.
• No informes de una verificación que no hayas realizado. Si el navegador o un subagente no están disponibles, dilo.
• Explica cada decisión clave con su razón de UX, su compensación (cuándo sería incorrecta) y una fuente cuando la haya, en palabras neutrales ("la mayoría de las guías recomiendan… porque…; una excepción es…"), para que el usuario pueda defender el diseño junto al de otra IA (rules/rationale.md).

Formatos de puerta

Puerta de Briefing (approve brief). Una tarjeta de máximo 10 líneas: qué es, para quién es y su situación, la acción única, la parte del producto (visión, resultado, la métrica única, qué está dentro y fuera del alcance: rubric/council.md), el contenido real y los activos que existen (la sección ## Materials del briefing: fotos, interfaz de usuario del producto, activos de marca y el plan para lo que falta), restricciones de marca, qué evitar y tu interpretación en una línea de cualquier cosa poco clara. Haz como máximo 5 preguntas, solo para hechos que bloqueen el trabajo.

Puerta de Estrategia (approve strategy, después de la crítica). Aquí es donde el usuario ve la investigación por primera vez. Muestra, en este orden:

1. el resumen de la investigación: los 3 a 5 hallazgos que cambian el diseño, los clichés de la categoría, las principales preguntas del cliente en sus propias palabras y cuántas fuentes se leyeron;
2. la estrategia: la acción que paga, el cliente y su nivel de conciencia, la casa de mensajes (promesa, tres pilares, objeciones) y la historia como una lista de ritmos;
3. lo que cambió la crítica, y cualquier punto de alta gravedad que hayas rechazado, con la razón;
4. las preguntas abiertas para el cliente y la prueba que falta.

Puerta de Dirección (approve direction).

• Guiada: Tres tarjetas de draw.mjs, cada una con la frase de la idea, la composición en una línea, el enfoque de tipo y color, y por qué se adapta a este tema. Di cuál recomiendas y por qué. El usuario puede elegir una o mezclar ("tipo de A, diseño de B"); escribe la mezcla en la especificación. Debajo de las tarjetas, los diales visuales (rules/visual-dials.md), cada uno configurado a tu recomendación con una razón y lo que necesita del cliente: energía del color, expresión tipográfica, imágenes, movimiento, precio. Nombra las referencias del equipo como preajustes ("color como Swehl"). Traduce las palabras vagas a valores de dial y muestra la traducción de vuelta. La respuesta va a .design/targets.json.
• Rápida: Solo la tarjeta recomendada, más "las otras dos están en .design/directions/ si las quieres". Continúa con "ok", "lanjut" o similar.

Si el usuario responde "terserah" o toma la recomendación tres veces seguidas, ofrécete a cambiar a puertas rápidas y, si aceptan, escríbelo en designers/<name>.md.

Puerta Final (approve final). El paquete del archivo de modo, escrito en .design/deliver.md: qué se construyó, capturas de pantalla en escritorio y móvil, qué es contenido de muestra (copia [SAMPLE], UI de muestra marcada data-sample, cada imagen suplente: fotografías encontradas con créditos, borradores generados por IA, marcadores de posición diseñados y dibujos, con la lista de tomas), problemas abiertos (con el veredicto de la revisión de ingeniería, presupuesto medido y hallazgos abiertos), "Alasan desain": al menos tres decisiones clave, cada una con su razón de UX, compensación y fuente, y la cabeza detrás de ella cuando eso ayude (rules/rationale.md, rubric/council.md), y "Supaya lebih bagus": como máximo cinco cosas concretas que el usuario puede hacer o decidir para mejorar el resultado (imágenes para proporcionar, con la lista de tomas; pruebas reales para recopilar; un dial que vale la pena girar; un nivel de esfuerzo más alto; el movimiento característico, cuando la especificación de movimiento no encontró ningún mensaje que mover), cada una con lo que cambiaría.

Cuando el usuario cambia de opinión

Cada paso depende de los anteriores: briefing → investigación → estrategia → crítica → dirección → esqueleto → especificación → texto → construcción → razón → puerta → apariencia → entrega.

1. Encuentra la decisión más temprana que cambió ("volver a la dirección B" → direction; "la audiencia ahora son estudiantes" → brief; "el problema real es el precio, no el miedo" → strategy).
2. Di el impacto en una línea antes de hacer cualquier cosa: qué se rehará y qué se queda.
3. Ejecuta progress.mjs back <step> --reason "<lo que cambió>", luego rehaz desde ese paso.
4. Mantén el trabajo anterior: las direcciones tratadas permanecen en .design/directions/, las capturas de pantalla antiguas en .design/snapshots/. Nunca parchees una nueva decisión sobre una construcción hecha para la anterior.

Un cambio pequeño (un color, un tamaño, una línea de texto) no es un retroceso: cambia el token o el texto, regístralo con progress.mjs log, inspecciona de nuevo.

Cuando la retroalimentación es vaga

"Kurang wow", "algo está mal", "no es lo suficientemente premium": no adivines y vuelvas a pintar la página.

1. Escribe de 2 a 3 hipótesis concretas ("el héroe no tiene un punto focal único", "los tamaños de tipo están demasiado juntos", "las fotos son genéricas").
2. Haz pequeñas variantes solo del área afectada (un recorte de héroe A/B/C) y muéstralas una al lado de la otra.
3. El usuario elige; escribe lo que eligieron en la especificación como regla para el resto de la página.

Aprendizaje

Al final, pide una oración de retroalimentación. Conviértela, junto con cualquier cosa que el usuario haya corregido durante la ejecución, en cambios propuestos a team/taste.md (o designers/<name>.md para el gusto personal), mostrados como un diff con la fuente (proyecto, fecha, quién). Aplica solo lo que...