muhammad-ahmed-ghani/ai-website-builder

Construtor de sites com IA

Um aplicativo é classe mundial quando cinco coisas são verdadeiras ao mesmo tempo. Ele responde ao que a pessoa realmente queria. Ele não se parece com o de ninguém e ainda converte. Ele diz apenas o que é verdade. Tudo nele funciona. E alguém o olhou em um navegador real antes de dizer que estava pronto. Esta skill é o método para obter todas as cinco, em qualquer stack, sozinho ou com agentes auxiliares.

Comece aqui: o que as pessoas FARÃO nele?

Antes de qualquer chamada de ferramenta, decida qual destes você está construindo. Leia references/01-read-the-request.md se não for óbvio.

A pessoa pede...	Construa	Leia
Um aplicativo sobre um negócio, pessoa, lugar ou coisa que eles vendem	Um aplicativo de leitura: história, prova real que eles deram, uma forma de contatá-los	01, 02, 03, 09, 04, 10
Algo para USAR: um dashboard, ferramenta, portal, "como o Slack mas...", um redesign de uma ferramenta funcional	Um aplicativo funcional: / é a tela funcional, com dados de demonstração e, se as pessoas fizerem login, credenciais de demonstração visíveis	01, 05 primeiro, depois 03, 09, 04
Uma atividade (aprender um idioma, praticar para um exame, planejar, acompanhar) com um público e nenhum negócio nomeado	Um aplicativo funcional. Para aprendizado: uma página inicial projetada com seções, depois lições, prática, progresso. NÃO um folheto para uma escola inventada	01, 05, 09
Uma página que apresenta um produto existente	Um aplicativo de leitura sobre esse produto	01, 02, 03, 09, 04, 10

A palavra "site" em uma solicitação não decide isso; palavras do proprietário ("minha academia", "nossa loja") e o que as pessoas farão nele decidem. Em caso de dúvida, construa a leitura do aplicativo funcional e diga isso em sua primeira mensagem.

O ciclo (detalhes em references/00-operating-loop.md)

1. Leia a solicitação. Escreva .app-notes/brief.json (fatos com as próprias palavras da pessoa, desconhecidos, suposições) e .app-notes/requirements.json (tudo o que eles disserem, agora e depois). Faça no máximo uma pergunta agrupada, apenas se um palpite errado mudar a construção.
2. Pesquisa e estratégia (ao lado do passo 3). Estude a categoria real, escreva as nove respostas da estratégia e a tese de design. references/02-research-and-strategy.md
3. Quadros de inspiração (ao lado do passo 2). Seis quadros por rodada; cada quadro é UM design mostrado como quatro telas do mesmo aplicativo, aproximadamente 2048 x 1280; a pessoa pode pedir mais rodadas até ficar satisfeita. Os seis vêm de seis mundos candidatos na cultura do público, não de seis adjetivos (references/09-design-craft.md seção 2). references/03-design-direction.md
4. Conceitos, provas, painel. Um conceito por quadro, estruturalmente diferente; renderize cada um como uma página real; pontue-os; escolha.
5. Vincule a direção. DESIGN.md, tokens.css, fonts.css, verificação de contraste, um blueprint por página.
6. Planeje. Páginas e seções com tarefas de uma linha, funcionalidades com passos de aceitação executáveis, imagens com tarefas.
7. Construa. Fundação primeiro, depois construtores de página em paralelo, depois um integrador. Apenas tokens, texto real, imagens reais, controles funcionais. references/04-build-system.md e references/05-working-apps.md para aplicativos funcionais.
8. Verifique com scripts/check-app.mjs na build de produção: três tamanhos, role como um visitante rola, imagens, fatos medidos, uma varredura de design (contraste, tipografia, hierarquia, texto coberto, gerador diz), fluxos de funcionalidades, um tour gravado. references/06-qa-and-repair.md
9. Critique, depois repare. Julgue o design primeiro, sem ancoragem; depois leia a varredura; depois execute as passagens nomeadas (layout, tipos, colorir, ousar, endurecer, polir...) uma de cada vez, cada uma com escopo, cada uma terminando em evidência. Corrija causas; re-verifique; reverta o que piorou. references/09-design-craft.md
10. Policie contra a imagem escolhida, depois relate honestamente apenas a partir de medições.

Não pule 3, 4, 8 e 9: eles são onde um aplicativo deixa de ser um modelo e onde "pronto" deixa de ser uma afirmação. Execute etapas independentes juntas.

Inegociáveis

1. Honestidade supera tudo. Nunca invente depoimentos, logotipos, imprensa, avaliações, estatísticas, prêmios, membros da equipe, endereços, e-mails, números de telefone, preços, horários, tempos de resposta, políticas, garantias ou qualificações. Um fato ausente é omitido (o padrão), transformado em um convite, ou marcado uma vez com um visível <Draft> para o proprietário. Contar o que a pessoa não listou é inventar. Dados de amostra em um aplicativo funcional são permitidos apenas porque o aplicativo diz "Dados de demonstração" na tela.
2. Nada finge funcionar. Sem href="#", sem formulário que não leva a lugar nenhum, sem botão desabilitado "ainda não conectado", sem serviço de formulário de terceiros que a pessoa não escolheu, sem login que aceita qualquer coisa. Conecte para valer ou deixe de fora e diga isso.
3. Nunca afirme o que não foi medido. Nem "testado", "verificado", "acessível", "polido" ou "responsivo" sem evidência para essa afirmação exata. "Não pôde olhar" nunca é "limpo". Nunca diga que o trabalho começou a menos que você tenha feito a chamada que o inicia.
4. Decida a aparência a partir de imagens, antes do código, e construa de acordo com a imagem escolhida. Sem aparências padrão. Recuse os sinais de IA de primeira e segunda ordem, a menos que o mundo deste cliente os mereça (09 os lista como regras que o script de QA mede; uma descoberta de review é mantida apenas com um motivo).
5. Um sistema de design. Cor, tipo, raio, sombra e easing vêm apenas de tokens. No máximo duas famílias tipográficas. Um momento de assinatura e uma imperfeição deliberada. Destaque usado com moderação.
6. Imagens são generosas, dirigidas artisticamente e nunca falsificadas. Cerca de uma por tela de rolagem, um estilo compartilhado, através do manifesto de imagens, texto alternativo real; sem imagens SVG desenhadas à mão de objetos ou pessoas; sem letras dentro de imagens; sem imagem de IA legendada como um evento real.
7. Idioma certo, script certo. lang e dir definidos; script real (nunca transliteração no lugar dele); propriedades CSS lógicas; traduções que você não pode verificar são sinalizadas para o proprietário.
8. Tudo que a pessoa diz é registrado e usado. Acompanhamentos, direcionamentos e respostas vão para o registro de requisitos e são lidos por cada etapa posterior. Um acompanhamento continua o mesmo projeto.
9. Evidência supera código. Toda afirmação visual vem de uma imagem que você olhou nesta execução, em 390, 768 e 1440.
10. Corrija causas, a menor mudança. Reproduza, corrija a causa, re-verifique. Dois patches falhos: reescreva o componente. Uma falha dentro de uma imagem gerada precisa de uma nova imagem, não de CSS.

O iniciador e os scripts

<skill> abaixo é a pasta onde este SKILL.md está (por exemplo ~/.claude/skills/ai-website-builder). Execute os scripts a partir da pasta do projeto.

bash <skill>/scripts/scaffold.sh ./my-app [--app]           # copia o iniciador, instala, lint, build (--app adiciona src/app/ para um aplicativo funcional)
node <skill>/scripts/contrast.mjs --tokens src/styles/tokens.css   # cada par de cores que um componente usa, claro e escuro
node <skill>/scripts/optimize-images.mjs --src .app-notes/originals --alt .app-notes/alt.json   # conjunto avif + webp e o manifesto
pnpm build && pnpm preview                                  # sirva a build de PRODUÇÃO (deixe-a executando)
node <skill>/scripts/check-app.mjs --url http://localhost:4173 --flows .app-notes/flows.json --tour [--extremes]
                                                            # imagens, fatos medidos, varredura de design, fluxos de funcionalidades, visita gravada, relatório
                                                            # --extremes adiciona 320x640 e 1920x1080; --no-design pula a varredura

O script de QA precisa do Playwright (pnpm add -D playwright && npx playwright install chromium) ou --chrome /path/to/chrome. O otimizador precisa de sharp.

assets/template/ é Vite + React 19 + TypeScript + Tailwind v4 com pré-renderização por rota, um contrato de tokens, 18 primitivas de UI, um kit de movimento, um kit imersivo, um kit de aplicativo e um lint que falha a build nos erros comuns. Seu AGENTS.md é o mapa de arquivos autoritativo; STANDALONE.md diz o que fazer manualmente sem uma plataforma de hospedagem (tokens de autor, criar imagens, definir o endpoint do formulário). Para um aplicativo funcional use scaffold.sh --app (ele escreve src/app/{accounts,db,seed}.ts; um aplicativo onde ninguém faz login mantém demoAccounts vazio). Use outra stack se o projeto da pessoa já tiver uma: o método, as regras e os scripts não dependem do modelo.

Usando auxiliares

Com uma ferramenta de sub-agente, divida por references/08-role-briefs.md e dê a cada auxiliar um escopo de escrita disjunto (fundação: arquivos compartilhados; construtores de página: uma pasta de página cada; integrador por último). Sozinho, siga a mesma ordem. Mantenha uma lista de tarefas compartilhada: os itens da pessoa são deles para alterar; não devolva enquanto um que se encaixa na sua parte estiver aberto; no final, cada item está feito, bloqueado com uma nota, ou não feito com um motivo.

O relatório de encerramento (apenas a partir de medições)

O que você construiu (páginas, funcionalidades); para um aplicativo funcional, o que é real e o que é simulado; o que a pessoa deve fornecer; o que foi verificado (veredito) e o que NÃO foi; o que ainda está aberto em palavras simples; por requisito: construído e verificado, construído não verificado, ou não feito e por quê. Curto, simples, sem tom de marketing. Use assets/checklists/done.md antes de enviá-lo.

Mapa de referências

Arquivo	Leia quando
references/00-operating-loop.md	planejando a execução, dividindo o trabalho, mantendo os registros e a lista de tarefas
references/01-read-the-request.md	nos primeiros dez minutos de cada trabalho; aplicativo de leitura ou aplicativo funcional; idioma; reivindicações; acompanhamentos
references/02-research-and-strategy.md	pesquisando a categoria, escrevendo a estratégia e a tese de design, escolhendo esqueletos de página
references/03-design-direction.md	quadros, conceitos, movimentos, tipografia, leis do ofício, sinais de IA, provas, painel, fidelidade
references/04-build-system.md	escrevendo código: tokens, páginas, texto, formulários, imagens, movimento, SEO, acessibilidade, orçamentos
references/05-working-apps.md	qualquer coisa que as pessoas usam: backend de demonstração, login, regiões, fluxos, aplicativos de aprendizado
references/06-qa-and-repair.md	verificando, julgando, reparando, crítica, o relatório de encerramento
references/07-failure-catalogue.md	antes de começar e antes de relatar: o que deu errado antes e a cura
references/08-role-briefs.md	instruindo agentes auxiliares; mapeando nomes de ferramentas
references/09-design-craft.md	escolhendo o quão forte pressionar (modos de visitante), construindo um mundo, pisos de cor e tipo, os sinais como regras, as passagens de refinamento, as duas avaliações, pontuação
references/10-copy-and-voice.md	escrevendo ou revisando quaisquer palavras no aplicativo: voz a partir de fatos, regras de slot, os sinais de prosa gerada
references/11-listening-to-the-audience.md	a etapa de pesquisa: ouvindo as preocupações e palavras do público sem tomar emprestadas suas afirmações
references/12-diagrams.md	uma imagem de como-funciona, processo, fluxo ou arquitetura; construída em markup a partir de tokens
references/13-reference-teardown.md	medindo até três aplicativos de referência para ofício e estrutura durante a pesquisa
references/14-scripts-and-app-jobs.md	fontes para um script não latino; o que os visitantes vêm fazer em cada tipo de aplicativo; adições de acessibilidade
references/15-redesign-and-extension.md	um aplicativo já existe: registre-o, escolha polir, reestilizar ou completo, prove que nada foi perdido
references/NOTICE.md	créditos e licenças dos projetos públicos dos quais esta skill aprendeu
assets/checklists/brief.md, done.md	as formas dos registros; a última verificação