slice-mockup-html

Slice Mockup para HTML

Copie um mockup para HTML fielmente; não o redesenhe. Um resultado correto, sobreposto ao mockup, mostra quase nenhuma diferença. Criatividade, "melhorias" e recursos extras contam como erros.

Fluxo de trabalho (em ordem, não pule)

1. Receber o mockup

Confirme que o mockup realmente existe (verifique /mnt/user-data/uploads e a conversa); se não, peça-o, nunca adivinhe. Se tiver muitas páginas/quadros, pergunte qual construir.

Entradas suportadas: PNG, SVG, Figma via MCP (JPG é tratado como PNG). Para qualquer outro formato, peça ao usuário que exporte PNG ou SVG. Como ler cada entrada está em references/mockup-audit.md. Para Figma, carregue a skill figma:figma-design-to-code antes de chamar get_design_context.

2. Fazer as duas perguntas

Pergunte ambas juntas, antes da auditoria e antes de codificar. Pule uma pergunta se o usuário já a respondeu. Use ask_user_input_v0 se disponível (uma chamada, duas perguntas); caso contrário, pergunte em texto simples curto.

1. Formato de saída: Arquivo único (HTML, CSS, JS inline em um index.html, mais assets/) ou Arquivos separados (index.html, css/style.css, js/main.js, mais assets/)
2. CSS: Vanilla CSS, Bootstrap via CDN ou Tailwind via CDN

Após as respostas, leia references/output-structure.md e o arquivo correspondente: references/vanilla.md, references/bootstrap.md ou references/tailwind.md. Não leia os outros dois.

3. Auditar antes de codificar

Leia references/mockup-audit.md e produza a especificação de auditoria (canvas, container, grid, cores, fontes, espaçamento, raio, sombras, assets, interações visíveis), cada valor marcado como medido ou estimado. Mostre ao usuário um resumo apenas se uma decisão for necessária (fonte não identificável, asset ausente); caso contrário, continue.

4. Escrever o código

• Regras: references/responsive-and-fidelity.md (pixel-perfect e responsivo), references/code-standards.md (HTML semântico, BEM), references/anti-slop.md (proibições). Aplique-as enquanto escreve, não depois.
• Os valores na largura do mockup devem corresponder exatamente à auditoria (em px, não arredondados para uma escala de framework).
• JS apenas para componentes interativos visíveis no mockup, seguindo o teste de conteúdo em anti-slop.md (construa o comportamento quando o mockup tiver o conteúdo necessário; caso contrário, mantenha estático e reporte); sem bibliotecas extras além do que o framework escolhido exige.

5. Verificar

Siga as etapas de verificação em references/responsive-and-fidelity.md, depois execute a verificação final em references/anti-slop.md. Se o sandbox não puder renderizar, diga isso claramente.

6. Entregar

Salve em /mnt/user-data/outputs/ e compartilhe com present_files. Para mais de um arquivo, empacote um único .zip com a estrutura de pastas intacta (para que os caminhos de assets permaneçam válidos) e também apresente index.html.

Em seguida, forneça um relatório de no máximo cerca de 6 linhas, apenas o que o usuário precisa saber: fontes não identificadas e seus substitutos, valores estimados, assets substitutos, ícones que não puderam ser recriados ou excedem o orçamento de tamanho, comportamento interativo construído ou deixado estático por falta de conteúdo, e partes de tablet/mobile derivadas porque o mockup não as possui. Sem sugestões de recursos, ideias de melhoria ou autoelogio.

Princípios centrais

• Fidelidade acima de tudo. Se o mockup parecer fraco, copie-o como está.
• Não adicione nada ausente do mockup; não adivinhe silenciosamente: toda suposição com impacto visual vai para o relatório.
• Copie o texto exatamente, incluindo capitalização, pontuação e números; sinalize texto ilegível.