webiscorp/designskill-open

Frontend Slides

Crie apresentações HTML sem dependências e ricas em animação, que são executadas inteiramente no navegador.

Princípios Fundamentais

1. Zero Dependências — Arquivos HTML únicos com CSS/JS inline. Sem npm, sem ferramentas de build.
2. Mostre, Não Conte — Gere prévias visuais, não escolhas abstratas. As pessoas descobrem o que querem vendo.
3. Design Distinto — Sem "AI slop" genérico. Cada apresentação deve parecer feita sob medida.
4. Divulgação Progressiva — Leia primeiro índices de estilo leves. Para templates ousados, use pequenos cartões de prévia de estilo e carregue o design.md completo apenas após o usuário escolher aquele template.
5. Stage Fixo 16:9 (INEGOCIÁVEL) — Cada deck usa uma tela de slide de 1920×1080 dimensionada como um todo para a viewport. Os slides devem permanecer 16:9 em todas as telas, incluindo celulares. Não reorganize o conteúdo do slide para caber no dispositivo.

Estética de Design

Você tende a convergir para resultados genéricos e "em distribuição". Em design frontend, isso cria o que os usuários chamam de estética "AI slop". Evite isso: faça frontends criativos e distintos que surpreendam e encantem.

Concentre-se em:

• Tipografia: Escolha fontes bonitas, únicas e interessantes. Evite fontes genéricas como Arial e Inter; opte por escolhas distintas que elevem a estética do frontend.
• Cor e Tema: Comprometa-se com uma estética coesa. Use variáveis CSS para consistência. Paletas com cores dominantes e acentos nítidos superam paletas tímidas e uniformemente distribuídas. Inspire-se em temas de IDE e estéticas culturais.
• Movimento: Use animações para efeitos e micro-interações. Priorize soluções apenas com CSS para HTML. Use a biblioteca Motion para React quando disponível. Concentre-se em momentos de alto impacto: um carregamento de página bem orquestrado com revelações escalonadas (animation-delay) cria mais encantamento do que micro-interações dispersas.
• Fundos: Crie atmosfera e profundidade em vez de usar cores sólidas por padrão. Faça camadas de gradientes CSS, use padrões geométricos ou adicione efeitos contextuais que combinem com a estética geral.

Evite estéticas genéricas geradas por IA:

• Famílias de fontes usadas em excesso (Inter, Roboto, Arial, fontes do sistema)
• Esquemas de cores clichê (particularmente gradientes roxos em fundos brancos)
• Layouts e padrões de componentes previsíveis
• Design padronizado que carece de caráter específico do contexto

Interprete criativamente e faça escolhas inesperadas que pareçam genuinamente projetadas para o contexto. Varie entre temas claro e escuro, fontes diferentes, estéticas diferentes. Você ainda tende a convergir para escolhas comuns (Space Grotesk, por exemplo) entre gerações. Evite isso: é fundamental que você pense fora da caixa!

Regras de Stage Fixo

Essas invariantes se aplicam a TODOS os slides em TODAS as apresentações:

• Cada deck tem um wrapper de viewport que preenche a janela do navegador.
• Cada slide é criado dentro de um stage fixo de 1920×1080.
• O stage é dimensionado uniformemente para caber na viewport. Pode usar letterbox/pillarbox; não deve reorganizar o layout do conteúdo.
• Não use breakpoints responsivos para reorganizar o conteúdo do slide para celulares.
• Use medidas internas fixas do slide no tamanho de design 1920×1080.
• A visibilidade do slide deve ser controlada por .active / .visible usando visibility, opacity e pointer-events de viewport-base.css. Não use display: none / display: block para alternar slides; classes de layout posteriores, como .slide-content { display: flex; }, podem substituí-las e tornar todos os slides visíveis ao mesmo tempo.
• Use clamp() apenas para UI não relacionada a slides fora do stage, ou para pequenas prévias de fallback onde um stage completo é impraticável.
• Inclua suporte a prefers-reduced-motion
• Nunca negue funções CSS diretamente (-clamp(), -min(), -max() são ignoradas silenciosamente) — use calc(-1 * clamp(...))

Ao gerar, leia viewport-base.css e inclua seu conteúdo completo em cada apresentação.

Modos de Densidade de Conteúdo

Pergunte ao usuário se esta é principalmente uma apresentação para leitura ou para fala, e então projete em torno dessa resposta:

Modo de densidade	Melhor para	Comportamento de design
Baixa densidade / liderada pelo palestrante	Palestras públicas, compartilhamento estilo keynote, explicação ao vivo	Uma ideia por slide, tipo grande, hierarquia visual forte, espaço negativo generoso, no máximo 1-3 marcadores, mais slides se necessário
Alta densidade / leitura primeiro	Relatórios, materiais impressos, revisão assíncrona, documentos internos detalhados	Mais slides autocontidos, grades/tabelas/anotações estruturadas, 4-8 marcadores ou 4-6 cartões quando legíveis, espaçamento mais justo, mas ainda intencional

Limites de linha de base ainda se aplicam: sem rolagem, sem estouro, sem painéis sobrepostos e sem texto abaixo do tamanho de leitura confortável. Se o conteúdo exceder o modo de densidade selecionado, divida-o em mais slides em vez de encolher até ficar apertado.

---

Fase 0: Detecte o Modo

Determine o que o usuário deseja:

• Modo A: Nova Apresentação — Crie do zero. Vá para a Fase 1.
• Modo B: Conversão de PPT — Converta um arquivo .pptx. Vá para a Fase 4.
• Modo C: Aprimoramento — Melhore uma apresentação HTML existente. Leia-a, entenda-a, aprimore. Siga as regras de modificação do Modo C.

Modo C: Regras de Modificação

Ao aprimorar apresentações existentes, o ajuste de stage fixo é o maior risco:

1. Antes de adicionar conteúdo: Conte os elementos existentes, verifique os limites de densidade
2. Adicionando imagens: Coloque-as dentro da tela do slide de 1920×1080. Se o slide já tiver o conteúdo máximo, divida em dois slides
3. Adicionando texto: Máximo de 4-6 marcadores por slide. Excede limites? Divida em slides de continuação
4. Após QUALQUER modificação, verifique: o stage do slide permanece 16:9, nenhum texto excede seu cartão, nenhum painel se sobrepõe, e as capturas de tela parecem corretas em 1280×720 mais uma viewport de celular
5. Reorganize proativamente: Se as modificações causarem estouro, divida o conteúdo automaticamente e informe o usuário. Não espere ser perguntado

Ao adicionar imagens a slides existentes: Mova a imagem para um novo slide ou reduza outro conteúdo primeiro. Nunca adicione imagens sem verificar se o conteúdo existente já preenche o stage do slide de 1920×1080.

---

Fase 1: Descoberta de Conteúdo (Novas Apresentações)

Faça TODAS as perguntas juntas para que o usuário preencha tudo de uma vez. Se o ambiente atual fornecer uma UI nativa de perguntas estruturadas, use-a; caso contrário, pergunte em uma mensagem concisa com escolhas claramente numeradas:

Pergunta 1 — Propósito (cabeçalho: "Propósito"): Qual é o propósito desta apresentação? Opções: Pitch deck / Ensino-Tutorial / Palestra em conferência / Apresentação interna

Pergunta 2 — Extensão (cabeçalho: "Extensão"): Aproximadamente quantos slides? Opções: Curta 5-10 / Média 10-20 / Longa 20+

Pergunta 3 — Conteúdo (cabeçalho: "Conteúdo"): Você tem o conteúdo pronto? Opções: Todo o conteúdo pronto / Notas aproximadas / Apenas o tópico

Pergunta 4 — Densidade (cabeçalho: "Densidade"): Qual deve ser a densidade do deck? Opções:

• "Baixa densidade / liderada pelo palestrante" — Ideias grandes, menos palavras, mais espaço visual
• "Alta densidade / leitura primeiro" — Mais detalhes autocontidos para leitura assíncrona

Não pergunte sobre edição inline durante a Fase 1. Os usuários não devem ter que escolher o comportamento de edição antes de ver um rascunho. Edição inline é uma funcionalidade pós-rascunho: inclua-a por padrão, a menos que o usuário solicite explicitamente um arquivo bloqueado/somente exportação.

Lembre-se da escolha de densidade do usuário. Ela afeta a contagem de slides, a escala tipográfica, a quantidade de texto por slide, a densidade do layout e se deve favorecer slides de apresentador cinematográficos ou slides de leitura autocontidos.

Se o usuário tiver conteúdo, peça para ele compartilhá-lo.

Etapa 1.2: Avaliação de Imagens (se fornecidas)

Se o usuário selecionar "Sem imagens" → pule para a Fase 2.

Se o usuário fornecer uma pasta de imagens:

1. Digitalize — Liste todos os arquivos de imagem (.png, .jpg, .svg, .webp, etc.)
2. Inspecione cada imagem — Use a capacidade de compreensão de imagem disponível do agente. Se a leitura de imagem não estiver disponível, use nomes de arquivo/metadados e peça ao usuário para esclarecer apenas quando necessário
3. Avalie — Para cada uma: o que mostra, USÁVEL ou NÃO USÁVEL (com motivo), qual conceito representa, cores dominantes
4. Codesenhe o esboço — Imagens selecionadas informam a estrutura do slide junto com o texto. Isso NÃO é "planejar slides e depois adicionar imagens" — projete em torno de ambos desde o início (ex.: 3 capturas de tela → 3 slides de funcionalidades, 1 logotipo → slide de título/encerramento)
5. Confirme o esboço usando o mesmo mecanismo de perguntas estruturadas quando disponível: "Este esboço de slides e seleção de imagens parecem corretos?" Opções: Parece bom / Ajustar imagens / Ajustar esboço

Logotipo em prévias: Se um logotipo usável foi identificado, incorpore-o (base64) em cada prévia de estilo na Fase 2 — o usuário vê sua marca estilizada de três maneiras diferentes.

---

Fase 2: Descoberta de Estilo

Esta é a fase "mostre, não conte". A maioria das pessoas não consegue articular preferências de design em palavras.

Etapa 2.0: Gere 3 Prévias de Estilo Diretamente

Com base no propósito, público, clima e densidade de conteúdo, gere 3 prévias HTML de slide único distintas, mostrando tipografia, cores, animação e estética geral.

Não pergunte ao usuário se ele deseja opções ou um seletor predefinido. A experiência de descoberta padrão é sempre a comparação visual.

Se o usuário já deu um vibe, use-o. Se não, infira o clima provável a partir da ocasião, público, conteúdo e importância. Mantenha as opções diversificadas o suficiente para que o usuário possa reagir visualmente em vez de precisar articular seu gosto de antemão.

Se o usuário nomear explicitamente uma predefinição ou template ousado, honre isso como uma opção e gere os slots de prévia restantes em torno dela.

Leia STYLE_PRESETS.md para candidatos seguros a predefinições. Se bold-template-pack/selection-index.json existir, leia esse índice compacto também, mas não leia nenhum arquivo design.md ainda.

Clima	Predefinições Sugeridas
Impressionado/Confiante	Sinal Ousado, Estúdio Elétrico, Botânico Escuro
Empolgado/Energizado	Voltagem Criativa, Neon Cyber, Pastel Dividido
Calmo/Focado	Abas de Caderno, Papel e Tinta, Suíço Moderno
Inspirado/Comovido	Botânico Escuro, Editorial Vintage, Geometria Pastel

Regras de mistura de prévias:

• Gere 3 prévias por padrão: 1 predefinição segura de STYLE_PRESETS.md, pelo menos 1 template ousado de bold-template-pack/selection-index.json e 1 curinga.
• O curinga pode ser um segundo template ousado ou um design personalizado auto-gerado. Escolha o que criar o contraste mais forte e útil para a ocasião, público, clima e conteúdo do usuário.
• Não force toda opção expressiva a vir da biblioteca de templates. Se o briefing tiver uma oportunidade de design mais nítida e específica do que os templates disponíveis, use o slot curinga para projetar livremente.
• Para decks conservadores ou de alto risco, faça a predefinição segura especialmente contida; escolha um template ousado calmo e de maior formalidade; faça o curinga ser outro template contido ou um design personalizado que pareça autoritário em vez de decorativo.
• Para decks expressivos, mantenha a predefinição segura como um fallback legível; escolha um template ousado forte; faça o curinga ser aventureiro, específico ao contexto e claramente diferente das outras duas prévias.
• Se as correspondências de template ousado parecerem fracas, use o curinga como um design personalizado ou recorra a outra predefinição segura em vez de forçar um template.

Regras de design curinga personalizado:

• Siga a seção de Estética de Design acima: sem "AI slop" genérico, sem escolhas padrão de fonte/cor/layout, sem clichês de gradiente roxo em branco, sem aparência de painel/cartão genérico.
• Combine com a ocasião declarada, público, clima/vibe e densidade de conteúdo do usuário. O design personalizado deve parecer criado para este deck, não meramente "estiloso".
• Faça uma tese visual deliberada: tipografia distinta, uma paleta comprometida, um sistema de layout reconhecível e um dispositivo atmosférico ou gráfico forte.
• Mantenha-o viável para um deck completo. A prévia deve implicar um sistema de design que possa se expandir para slides de seção, conteúdo, citação, comparação e encerramento.
• Use regras de stage fixo 1920×1080 e passe pelas mesmas verificações de autenticidade de prévia que todas as outras opções.
• Nunca renderize rótulos como "personalizado", "curinga", "gerado por IA" ou rótulos de processo de design no próprio slide.

Regras de seleção de template ousado:

• Corresponda o propósito e clima do usuário com mood, tone, best_for, avoid_for, formality, density e scheme.
• Trate os exemplos de best_for como sinais suaves, não filtros estritos de indústria.
• Mantenha as três prévias genuinamente diferentes umas das outras.
• Após escolher o(s) candidato(s) a template ousado, leia apenas os arquivos preview.md desse(s) candidato(s) dos caminhos preview_md no índice de seleção.
• Use preview.md apenas para prévias de slide de título. Não leia arquivos design.md completos até que o usuário escolha o template final.
• Não leia ou copie template.html a menos que o design.md final selecionado esteja faltando um detalhe crítico de implementação.

Regras de autenticidade de prévia (INEGOCIÁVEIS):

• Cada prévia de estilo deve parecer um primeiro slide real do deck do usuário, não um cartão de diagnóstico.
• Nunca renderize texto de fluxo de trabalho interno em um slide: nenhum preview, generated from, preview.md, template, preset, style option, Option A/B/C, nomes de arquivo, caminhos ou rótulos de documento fonte.
• Nunca renderize nomes de template ou slugs no próprio slide. Nomes de template/estilo pertencem apenas à mensagem para o usuário.
• Nunca renderize notas de requisitos do usuário como conteúdo do slide, como "afiado e provocativo", "opção segura", "opção ousada", "para compartilhamento interno" ou "público: ...", a menos que o usuário queira explicitamente essa frase exata no deck.
• Se o slide precisar de moldura, use apenas moldura de deck real: o título do deck, título da seção, data, autor, empresa, número da página ou uma frase de conteúdo genuína do material do usuário.
• Antes de abrir prévias, inspecione o texto visível e revise se algum metadado interno aparecer.

Salve as prévias em .frontend-slides/slide-previews/ (style-a.html, style-b.html, style-c.html). Cada um deve ser um arquivo HTML completo inline que passe nas regras de stage fixo, sem dependências externas.

---

Fase 3: Construção do Deck

Após a seleção do estilo, construa o deck completo: leia design.md para o template escolhido (se aplicável), divida o conteúdo do usuário em slides e crie o HTML completo inline.

---

Fase 4: Conversão de PPT

(Detalhes omitidos para brevidade — siga as regras de conversão de PowerPoint.)

---

Regras de Saída Final

• O arquivo HTML final deve ser totalmente autocontido (CSS/JS inline, imagens base64).
• Nenhuma dependência externa (CDNs, fontes web são permitidas apenas se inline via base64 ou data URI).
• O stage fixo 1920×1080 deve ser mantido.
• O deck deve ser uma única página HTML.