Crie um site de marketing de produto
Crie um site cujo conteúdo, escolhas visuais e interações expliquem este produto em particular. Suporte SaaS, micro-SaaS, serviços, ferramentas e outros produtos sem forçar um framework, um número fixo de páginas ou um modelo visual de SaaS.
Estabeleça a tarefa real
Leia a solicitação do usuário, instruções do repositório, definição de produto aprovada (como project.md) e site de marketing existente antes de modificar qualquer coisa. Se não existir nenhuma definição de produto, estabeleça o público, a oferta, os recursos disponíveis e o objetivo do site a partir de fontes autorizadas; pergunte apenas por decisões faltantes. Determine se a tarefa é um briefing, uma implementação de agente de codificação, uma transferência para um construtor externo ou uma atualização com escopo definido. Preserve as decisões de produto existentes, arquitetura e escopo autorizado. Não reinicie a descoberta para uma edição comum de site.
A definição de produto aprovada é proprietária dos fatos do produto, escopo, decisões comerciais e prontidão; preserve seu nome e localização existentes. Um marketing-site-brief.md separado é proprietário da arquitetura de informações, requisitos de conteúdo/design, interações e plano de descoberta do site; faça referência a ele a partir da definição do produto (por exemplo, project.md). Não duplique toda a definição de produto nem crie uma fonte concorrente de verdade do produto. As especificações existentes mantêm sua responsabilidade pelo trabalho de implementação.
Inspecione o framework real, rotas, renderização, componentes, dependências e restrições de hospedagem. Para um novo site, recomende uma abordagem compatível com base no conteúdo, necessidades de renderização/indexação, integrações, capacidade de manutenção e restrições da equipe. Explique compensações significativas em vez de escolher automaticamente o framework mais recente. Uma skill de design é uma orientação de trabalho, não um framework ou dependência de tempo de execução; SaaS é um modelo de produto, enquanto Sass é uma ferramenta de estilo.
Produza um briefing de design transferível
Use o modelo de briefing em inglês ou modelo em árabe ao criar o briefing; adapte as seções ao projeto em vez de preenchê-las com fatos inventados. Identifique incógnitas que bloqueiam o trabalho útil e prossiga com suposições declaradas para detalhes não bloqueadores.
Dê a cada página proposta uma pergunta distinta do visitante, conteúdo útil e próxima ação. Mescle páginas finas ou repetitivas. Inclua cópia da página, prontidão de recursos públicos, limites de evidência, navegação, links internos, rótulos de pré-visualização, comportamento de formulário, requisitos responsivos/RTL, acessibilidade, metadados, aplicabilidade de JSON-LD, desempenho e verificações de aceitação. Um site com várias páginas deve ter rotas e conteúdo significativos, não uma única página com âncoras renomeadas ou muitas páginas de palavras-chave quase idênticas.
Defina uma direção visual reconhecível: público e personalidade, princípios de referência, tipografia, tokens de cor/espaçamento, composição, ativos, movimento e restrições intencionais. Evite aplicar a mesma fórmula de hero/cartões/gradiente/dashboard a todo produto. Não copie a marca de outro produto nem invente prova de cliente. Inclua o raciocínio para que outra ferramenta possa executar o design de forma coerente.
Leia seleção de ferramentas de design ao escolher um framework, skills de design opcionais ou um construtor. Inspecione as skills de design disponíveis antes de invocá-las. Selecione a menor combinação útil para a tarefa, explique a sobreposição e preserve sua compatibilidade real de hospedagem. Não finja que uma skill nomeada está instalada. Skills externas opcionais podem melhorar a direção de arte ou revisões, mas este fluxo de trabalho ainda funciona sem elas. Não baixe, instale ou execute pacotes de terceiros apenas porque seus nomes aparecem no briefing. Se uma skill opcional criar arquivos como PRODUCT.md ou DESIGN.md, mapeie-os explicitamente como saídas de ferramentas derivadas ou notas de design de trabalho sob as referências aprovadas; não introduza silenciosamente autoridades concorrentes de produto/marketing. Inspecione os pontos de entrada atuais e compatibilidade antes de executar lançadores, inicializadores, hooks ou ajudantes habilitados para rede; não presuma que uma skill de design é apenas Markdown.
Construa diretamente ou transfira o mesmo briefing
- Rota de agente de codificação: implemente o briefing do site aprovado nas convenções existentes do projeto. Construa fundações compartilhadas, páginas representativas e navegação funcional, depois complete outras páginas e estados. Use o sistema de design existente quando ele fizer parte da identidade do produto; não o substitua sem um motivo baseado na tarefa.
- Rota de construtor externo, como Lovable: forneça o mesmo briefing sanitizado e ativos necessários usando as entradas suportadas reais da ferramenta. Dê uma instrução de escopo limitado que preserve os fatos do produto e distinga interações funcionais de pré-visualizações. Uma ferramenta não pode ler arquivos locais apenas porque seus nomes são mencionados. Verifique a documentação atual antes de prometer importação/exportação, framework ou comportamento de sincronização específicos. Inspecione o código recebido e os requisitos de integração antes de mesclar; não substitua a aplicação nem mova seu backend por suposição.
Para qualquer rota, revise os resultados reais gerados e corrija problemas observados em passes limitados. Não pré-escreva a resposta da ferramenta nem alegue sucesso a partir de sua mensagem de conclusão. Aprovar um briefing não implica publicação, gastos, provisionamento de serviços ou instalação de dependências fora do fluxo de trabalho escolhido. Edições reversíveis de rotina já autorizadas pela tarefa não requerem aprovação repetida.
Verifique comportamento e descoberta
Use o guia de aceitação para implementação e revisão final. Teste rotas reais e ações críticas, direção árabe/latina quando relevante, layouts mobile/desktop, uso de teclado, estados de carregamento/erro/sucesso significativos e metadados prontos para produção. Diferencie uma demonstração front-end de uma submissão salva real. Verifique um registro real antes de alegar registro real e proteja dados privados separadamente dos controles de indexação.
Selecione dados estruturados apropriados para a página visível e elegibilidade atual de pesquisa. Não invente avaliações, preços, organizações, disponibilidade ou classificações para preencher um esquema. Valide a sintaxe e os requisitos de pesquisa aplicáveis; JSON-LD válido não garante um resultado rico ou classificação. Não trate llms.txt, uma escolha de framework ou uma pontuação de SEO automatizada como garantia de visibilidade.
Relate verificações realmente executadas, ambiente/versão, falhas observadas e áreas não testadas. Uma captura de tela prova a aparência naquele viewport, não armazenamento funcional, indexação de produção ou desempenho de campo.
Revisão final obrigatória
Antes de alegar o briefing, transferência ou site completo, realize a revisão final para o modo solicitado. Compare a experiência real do visitante ou briefing transferível com o escopo aceito e direção de referência. Corrija descobertas e reverifique as saídas afetadas, registre evidências concisas e divulgue verificações ausentes. Presença de arquivo, capturas de tela geradas e builds verdes por si só não estabelecem um site útil.
Mantenha produto e site alinhados
Quando a tarefa incluir manutenção contínua, adapte o snippet AGENTS em inglês ou snippet em árabe aos caminhos reais do projeto. Para alterações de produto aprovadas, inspecione o mapa de impacto e atualize o conteúdo, navegação, metadados, dados estruturados e testes do site afetados dentro do trabalho autorizado do repositório. Marque recursos planejados e entregues com precisão; um recurso implementado não é automaticamente lançado para todo visitante.
Se fatos do produto, termos comerciais ou dependências externas não estiverem resolvidos, sinalize a decisão em vez de inventá-la silenciosamente. Se o site estiver localizado em outro lugar, identifique o acompanhamento exato necessário em vez de alegar que foi alterado. Mantenha as edições do repositório distintas da implantação e publicação pública.