Entrega a diseño
El texto está aprobado. Lo que un diseñador o un generador de wireframes necesita de él no son las palabras, sino qué debe hacer cada bloque de palabras al lector, en qué orden, y cuáles de esas cosas tienen que sobrevivir en un teléfono. Esta skill convierte una cosa en la otra y no decide nada que el texto ya haya decidido.
La puerta de entrada: texto aprobado y una especificación de sección por sección
Dos entradas. La segunda es la que suele faltar.
Texto aprobado, no un borrador. Un layout construido alrededor de un párrafo que aún se está discutiendo se reconstruye, y la reconstrucción siempre es peor, porque para entonces es un parche sobre una forma que se eligió para palabras diferentes. Si el texto aún se está moviendo, detente y dilo.
Una especificación de sección por sección. ../conversion-page-build/SKILL.md produce una junto con el texto, bajo su encabezado ## The section spec, y esta skill la lee por cinco nombres clave y ningún otro: section_type, purpose, content_hierarchy, components, responsive_intent. Ese archivo es dueño de la forma de la especificación y de la razón por la que se escribe después del texto y no antes.
El texto que llega sin especificaciones aún se puede entregar: primero escribe las especificaciones a partir del texto y márcalas como inferidas en la salida. Una especificación reconstruida a partir de texto terminado registra lo que el texto parece hacer, que no es lo mismo que lo que se creó para hacer. Donde estos dos difieran, un diseñador plasmará fielmente la intención incorrecta, y nada más adelante lo detectará.
La secuencia
Cuatro pasos. Los tres primeros siempre se ejecutan. El cuarto normalmente no.
- Mapear cada especificación de sección a componentes —
references/section-to-component.md. Convierte las cinco claves en una lista de componentes por sección, más la única cosa de esa sección que limita el layout. - Escribir el brief del wireframe —
references/relume-brief.md. Encuadre a nivel de página, luego un bloque por sección: estructura y función del contenido, sin apariencia. - Escribir la especificación de refinamiento —
references/figma-refinement-spec.md. Jerarquía visual, énfasis, prioridad sobre el pliegue y ruta de escaneo: las cuatro cosas que el wireframe no resuelve. - Notas de plataforma, condicionalmente — ver más abajo.
Los pasos 2 y 3 se mantienen como documentos separados a propósito, y en ese orden. La razón se indica en la apertura de references/figma-refinement-spec.md y no se repite aquí.
El pase de plataforma solo se ejecuta cuando se ha nombrado la plataforma
No abras references/platform-notes-wordpress.md a menos que se haya nombrado el destino de construcción y sea WordPress. Una construcción en Webflow, una en Framer, una codificada a mano y una construcción sin nombre no cargan nada aquí.
Esto no es ordenación de archivos. Una nota de plataforma describe una restricción que es real en una plataforma y falsa en otra, por lo que una especificación que lleva una restricción que no aplica hace que el diseñador resuelva un problema que no existe, y luego defienda la solución cuando alguien la cuestione. Las notas incorrectas cuestan más que la ausencia de notas.
Si el destino no se ha nombrado, pregunta. Si la respuesta es "aún no está decidido", escribe la entrega sin plataforma y registra en la salida que el pase de plataforma no se ha ejecutado, para que quien retome la construcción sepa que hay una verificación pendiente en lugar de asumir que se completó.
Cada archivo de plataforma tiene la misma forma y nada más: una nota por comportamiento, cada una indicando tres cosas: el comportamiento de la plataforma, el fallo que ese comportamiento causa y la redacción que lo evita. Una plataforma sin archivo en esta skill no recibe notas; nunca las de WordPress por defecto, que es el error específico que el condicional existe para prevenir.
Los nombres de las herramientas están en las puertas, no en el método
Dos archivos de referencia llevan el nombre de herramientas — references/relume-brief.md y references/figma-refinement-spec.md — porque esos son los nombres que la gente pide. Nada en ninguno de ellos depende de la herramienta, y ninguno hace una afirmación sobre lo que cualquier herramienta hace con lo que se le da.
Esa restricción es deliberada. Una skill que dice "la herramienta X acepta una descripción con esta forma" está haciendo una afirmación sobre el producto de otra persona que queda obsoleta en silencio, y el lector no tiene forma de distinguir una afirmación actual de una de hace dos años. Así que estos archivos describen lo que el documento contiene y por qué tiene esa forma. Cuando algo sobre una herramienta se verificó realmente, el archivo lo dice con la fecha en que se verificó, y no dice nada más allá de lo que cubrió la verificación.
El registro llega al diseño exactamente en un lugar
El registro se hereda del Brief de Conversión y nunca se decide de nuevo aquí; el razonamiento detrás de esto pertenece a ../audience-research/SKILL.md. Los cinco perfiles en sí viven en ../audience-research/references/register-profiles.md.
Afecta una decisión en esta skill: cuánto énfasis puede gastar la página. Todo lo demás aquí es estructural y viaja sin cambios: la misma sección tiene que hacer lo mismo al lector sea quien sea ese lector. references/figma-refinement-spec.md lleva esa única intersección, y es el único archivo en esta skill que lee una fila del registro.
Lo que esta skill no hace
- No reescribe el texto. Si una sección no se puede diseñar porque el texto nunca dice para qué sirve la sección, eso es
../copy-sweeps/SKILL.mdcuando el problema es el fraseo y../conversion-page-build/SKILL.mdcuando el problema es un argumento faltante. Nombra cuál y detente. - No elige un estilo visual. Sin paleta, sin escala tipográfica, sin valores de espaciado, sin números de punto de ruptura. Establece rango y relación; un sistema de diseño proporciona los valores.
references/figma-refinement-spec.mdexpresa la negativa en su totalidad y qué hacer cuando no hay un sistema de diseño que los proporcione. - Nunca trabaja a partir de una página que ya se ha publicado. Esta skill avanza hacia adelante, desde el texto aprobado hacia un layout que nadie ha construido. Juzgar un layout que existe va en la otra dirección y necesita evidencia que esta skill no tiene —
../conversion-page-audit/SKILL.md. - No construye. Las notas de plataforma existen para que una especificación no pida algo que el destino de construcción no pueda hacer de forma económica. No son instrucciones de construcción y no convierten esto en una skill de construcción.
Elementos no resueltos
Cualquier cosa que la entrega no pueda resolver a partir del texto y el brief se escribe como NO ESTABLECIDO — <qué lo cerraría> en el documento en lugar de adivinarse. La disciplina y su razonamiento se exponen una vez para todo el plugin en ../audience-research/SKILL.md y se aplican aquí sin cambios. Dos casos surgen con más frecuencia: un activo del que depende el layout que nadie ha producido aún, y un elemento de prueba que el texto promete pero que no existe.
Lo que esto produce
Un único documento de entrega. Bajo el archivado de este vault, se ubica en 03 Projects/<Project>/<Page>/[C] Design Handoff — <Page>.md; en cualquier otro lugar, donde el proyecto guarde las especificaciones. Lleva, en este orden: el mapa de componentes por sección, el brief del wireframe, la especificación de refinamiento y — solo cuando se haya nombrado una plataforma — las notas de plataforma que le aplican.
Di dónde lo archivaste y di si el pase de plataforma se ejecutó. Una entrega que guarda silencio sobre la plataforma se lee como una entrega en la que la plataforma fue verificada.