Handoff de design
O texto está aprovado. O que um designer ou um gerador de wireframe precisa dele não são as palavras — é o que cada bloco de palavras precisa fazer com o leitor, em que ordem, e quais dessas coisas precisam sobreviver em um telefone. Esta skill transforma um no outro, e não decide nada que o texto já tenha decidido.
O portão: texto aprovado e uma especificação de seção por seção
Duas entradas. A segunda é a que costuma faltar.
Texto aprovado, não um rascunho. Um layout construído em torno de um parágrafo que ainda está sendo discutido é reconstruído, e a reconstrução é sempre pior, porque a essa altura é um remendo em uma forma que foi escolhida para palavras diferentes. Se o texto ainda está em movimento, pare e diga isso.
Uma especificação de seção por seção. ../conversion-page-build/SKILL.md produz uma junto com o texto, sob seu cabeçalho ## A especificação de seção, e esta skill a lê por cinco nomes-chave e nenhum outro: section_type, purpose, content_hierarchy, components, responsive_intent. Esse arquivo define a forma da especificação e o motivo pelo qual ela é escrita após o texto, e não antes.
O texto que chega sem especificações ainda pode ser entregue — escreva as especificações a partir do texto primeiro, e marque-as como inferidas na saída. Uma especificação reconstituída a partir de texto finalizado registra o que o texto parece fazer, que não é a mesma coisa que o que foi construído para fazer. Onde esses dois diferem, um designer implementará fielmente a intenção errada, e nada a jusante detectará isso.
A sequência
Quatro etapas. As três primeiras sempre executam. A quarta geralmente não.
- Mapeie cada especificação de seção para componentes —
references/section-to-component.md. Transforma as cinco chaves em uma lista de componentes por seção, mais a única coisa sobre essa seção que restringe um layout. - Escreva o briefing de wireframe —
references/relume-brief.md. Enquadramento no nível da página, depois um bloco por seção: estrutura e função de conteúdo, sem aparência. - Escreva a especificação de refinamento —
references/figma-refinement-spec.md. Hierarquia visual, ênfase, prioridade acima da dobra e caminho de varredura: as quatro coisas que o wireframe não resolve. - Notas de plataforma, condicionalmente — veja abaixo.
As etapas 2 e 3 permanecem como documentos separados intencionalmente, e nessa ordem. O motivo é declarado na abertura de references/figma-refinement-spec.md e não é repetido aqui.
O passo de plataforma é executado apenas quando a plataforma foi nomeada
Não abra references/platform-notes-wordpress.md a menos que o destino de build tenha sido nomeado e seja WordPress. Um build Webflow, um build Framer, um build codificado manualmente e um build sem nome não carregam nada aqui.
Isso não é organização de arquivos. Uma nota de plataforma descreve uma restrição que é real em uma plataforma e falsa em outra, então uma especificação carregando uma restrição que não se aplica faz o designer resolver um problema que não existe — e então defender a solução quando alguém a questiona. Notas erradas custam mais do que nenhuma nota.
Se o destino não foi nomeado, pergunte. Se a resposta for "ainda não decidido", escreva o handoff sem plataforma e registre na saída que o passo de plataforma não foi executado, para que quem retomar o build saiba que uma verificação está pendente, em vez de assumir que passou.
Cada arquivo de plataforma tem a mesma forma e nada mais: uma nota por comportamento, cada uma declarando três coisas — o comportamento da plataforma, a falha que esse comportamento causa e a redação que o evita. Uma plataforma sem arquivo nesta skill não recebe notas; nunca as do WordPress como padrão, que é o erro específico que a condicional existe para prevenir.
Os nomes das ferramentas estão nas portas, não no método
Dois arquivos de referência são nomeados após ferramentas — references/relume-brief.md e references/figma-refinement-spec.md — porque esses são os nomes que as pessoas pedem. Nada em nenhum deles depende da ferramenta, e nenhum deles faz uma afirmação sobre o que qualquer ferramenta faz com o que recebe.
Essa restrição é deliberada. Uma skill que diz "a ferramenta X aceita uma descrição com esta forma" está fazendo uma afirmação sobre o produto de outra pessoa que se torna obsoleta silenciosamente, e o leitor não tem como distinguir uma afirmação atual de uma com dois anos. Então esses arquivos descrevem o que o documento contém e por que ele tem essa forma. Onde algo sobre uma ferramenta foi genuinamente verificado, o arquivo diz isso com a data em que foi verificado, e não diz nada além do que a verificação cobriu.
O registro atinge o design em exatamente um lugar
O registro é herdado do Brief de Conversão e nunca redecidido aqui; a lógica por trás disso pertence a ../audience-research/SKILL.md. Os cinco perfis em si vivem em ../audience-research/references/register-profiles.md.
Ele toca uma decisão nesta skill: quanta ênfase a página tem permissão para gastar. Todo o resto aqui é estrutural e viaja inalterado — a mesma seção tem que fazer a mesma coisa para um leitor, independentemente de quem seja esse leitor. references/figma-refinement-spec.md carrega essa única interseção, e é o único arquivo nesta skill que lê uma linha de registro.
O que esta skill não faz
- Ela não reescreve texto. Se uma seção não pode ser estruturada porque o texto nunca diz para que serve a seção, isso é
../copy-sweeps/SKILL.mdquando o problema é a redação e../conversion-page-build/SKILL.mdquando o problema é um argumento ausente. Nomeie qual deles e pare. - Ela não escolhe um estilo visual. Nenhuma paleta, nenhuma escala tipográfica, nenhum valor de espaçamento, nenhum número de ponto de quebra. Ela define classificação e relacionamento; um sistema de design fornece os valores.
references/figma-refinement-spec.mddeclara a recusa na íntegra e o que fazer quando não há sistema de design para fornecê-los. - Ela nunca trabalha a partir de uma página que já foi publicada. Esta skill avança, do texto aprovado em direção a um layout que ninguém construiu. Julgar um layout existente funciona no sentido oposto e precisa de evidências que esta skill não possui —
../conversion-page-audit/SKILL.md. - Ela não constrói. As notas de plataforma existem para que uma especificação não peça algo que o destino de build não pode fazer de forma barata. Elas não são instruções de build e não fazem desta uma skill de build.
Itens não resolvidos
Qualquer coisa que o handoff não possa resolver a partir do texto e do brief é escrita como NÃO ESTABELECIDO — <o que o fecharia> no documento, em vez de adivinhada. A disciplina e sua lógica são declaradas uma vez para todo o plugin em ../audience-research/SKILL.md e se aplicam aqui inalteradas. Dois casos aparecem com mais frequência: um recurso do qual o layout depende e que ninguém produziu ainda, e um elemento de prova que o texto promete e que não existe.
O que isso produz
Um único documento de handoff. Sob a organização de arquivos deste vault, ele cai em 03 Projetos/<Projeto>/<Página>/[C] Handoff de Design — <Página>.md; em qualquer outro lugar, onde o projeto mantém especificações. Ele carrega, nesta ordem: o mapa de componentes por seção, o briefing de wireframe, a especificação de refinamento e — apenas onde uma plataforma foi nomeada — as notas de plataforma que se aplicam a ela.
Diga onde você o arquivou e diga se o passo de plataforma foi executado. Um handoff que é omisso sobre a plataforma é lido como um handoff onde a plataforma foi verificada.