Como criar e publicar seu portfólio com Claude Code, mesmo sem saber programar

Você já refez seu portfólio umas três vezes. Uma no Behance, que ficou com a cara do Behance. Uma numa ferramenta de arrastar e soltar, que cobrava por mês pra manter no ar uma página que você mal editava. E uma numa pasta do Figma chamada "portfolio-final-v2", linda, que ninguém nunca viu porque nunca virou um site.

O bloqueio nunca foi falta de projeto. Você sabe projetar produtos. O bloqueio é que, entre o seu trabalho e uma URL pública (um endereço que qualquer pessoa consegue abrir na internet), sempre existiu uma muralha: código, terminal, deploy, domínio. Quatro nomes que este guia traduz na hora certa, um de cada vez. Do outro lado da muralha, um desenvolvedor. Ou um template.

E se a muralha tiver encolhido?

Claude Code é uma ferramenta de IA que trabalha dentro de uma pasta do seu computador. Ele inspeciona arquivos, propõe mudanças, escreve código e executa verificações sob sua revisão. Também pode diagnosticar errado e introduzir um problema novo. Você conversa em português; ele opera a parte técnica. Você continua dirigindo e conferindo.

Esse é o argumento inteiro deste guia, então vale deixar em uma frase:

Você não precisa saber programar pra publicar um bom portfólio. Precisa especificar o que importa, limitar cada mudança e exigir prova do que foi verificado.

São habilidades de designer, não de engenheiro. O resultado que interessa não é só um site bonito. É um portfólio operável: conteúdo que você controla, publicação que você consegue explicar, verificação que você consegue provar e manutenção que não exige recomeçar do zero. O resto deste artigo é o método: prompts copiáveis, pausas de revisão, GitHub pra guardar os arquivos com histórico e Netlify pra colocar a versão final na internet.

O fim deste guia é uma URL que você controla

O resultado deste método é um site próprio, com seu nome, publicado numa URL pública, que você mesmo consegue atualizar depois. Na versão enxuta, apresentação, projetos, experiência e contato vivem numa página. Na completa, entram home, listagem de projetos, uma página por estudo de caso e sobre. As duas precisam ser responsivas, ou seja, legíveis no celular e no computador. Preparadas para uma revisão de acessibilidade, não presumidas acessíveis porque a IA afirmou. Com o básico de SEO configurado (SEO é o conjunto de dados que ajuda buscadores e cartões de compartilhamento a entender a página).

Se o conteúdo e as imagens já estiverem prontos, uma versão mínima pode caber numa primeira sessão. A rota completa leva de 5,5 a 8,5 horas, geralmente divididas em dois blocos. Base existente, autenticação e erros encontrados mudam esse tempo. O conteúdo continua sendo a parte lenta, e é sua.

O que você não precisa saber: nenhuma linguagem de programação, nenhum framework (o nome dado a uma estrutura pronta de código, como Next.js ou Astro), nenhum comando de terminal decorado. Os comandos estáveis deste guia vêm prontos pra copiar; os comandos que dependem da base do seu projeto precisam ser descobertos e confirmados antes de executar.

O que você precisa ter: um computador com acesso pra instalar programas, uma conta no GitHub, uma conta no Netlify, acesso ao Claude Code e, principalmente, conteúdo. Que é o próximo assunto, e o mais importante.

Seu portfólio começa antes do Claude

Aqui está a inversão que separa este guia de um tutorial de ferramenta: o portfólio não melhora porque ganhou partículas, gradiente ou um cursor que brilha. Melhora quando cinco coisas ficam claras em segundos: quais projetos você fez, quais decisões você tomou, por que elas fazem sentido, que evidência sustenta o resultado e como falar com você.

Projetos, decisões, clareza, evidência, contato. Essa é a hierarquia. Todo o resto é embalagem.

Então, antes de abrir qualquer ferramenta, separe uma ou duas horas pra montar sua matéria-prima. É o trabalho que nenhuma IA faz por você, porque só você viveu os projetos. E tem um bônus prático: conteúdo organizado de antemão evita rodadas desnecessárias e tende a consumir menos limite de uso, porque o Claude não fica indo e voltando te perguntando o que escrever.

Salve o checklist preenchido como CONTEUDO.md dentro da pasta do projeto. Se a pasta ainda não existe, crie agora uma pasta vazia com um nome simples, como meu-portfolio. Esse arquivo é a matéria-prima que o Claude vai ler durante a construção; uma nota guardada só no seu aplicativo de texto continua invisível pra ele. Coloque as imagens numa pasta do projeto com nomes que você reconheça, sem apagar os arquivos originais.

Se algum projeto está na memória mas não no papel, não trave aqui: a seção sobre estudos de caso, mais abaixo, tem um prompt que transforma notas bagunçadas em estrutura. O checklist não precisa estar perfeito. Precisa existir dentro do CONTEUDO.md.

Se você tem projetos demais, dê de 0 a 2 pontos para cada um em quatro critérios: aderência à oportunidade que busca, clareza da sua responsabilidade, força da evidência e qualidade do material visual disponível. Comece pelos dois com maior soma. Um projeto famoso em que sua participação ficou nebulosa perde para um projeto menor em que a decisão, a restrição e o resultado são seus. A IA pode montar a tabela. A nota precisa ser sua.

Publique uma página antes de projetar cinco

Portfólio de designer tem uma arquitetura conhecida, e resistir a ela raramente compensa no primeiro site. A versão completa:

• Home: quem você é e seus 2 a 4 melhores projetos, em destaque
• Projetos: a listagem completa
• Página de projeto: um estudo de caso por página
• Sobre: sua história em mais profundidade
• Experiência: trajetória profissional (pode viver dentro do Sobre)
• Contato: email visível e links

E a versão enxuta, que eu recomendo pra primeira publicação: uma página só, com apresentação, projetos, experiência e contato em sequência. Quando usar cada uma? Se você tem 2 projetos documentados, comece com a enxuta e publique essa semana. Se tem 3 ou mais estudos de caso completos, vá de versão completa. A enxuta pode evoluir sem descartar o conteúdo, embora rotas e estrutura precisem mudar. Esse tipo de transformação cabe num plano futuro, não numa promessa de retrabalho zero.

O Claude Code trabalha na pasta, não numa caixa de chat

Você provavelmente já conversou com uma IA num site: você pergunta, ela responde, e copiar o resultado pra algum lugar é problema seu. Depois vieram as IAs que geram um bloco de código isolado: útil, mas alguém ainda precisa saber onde colar.

Claude Code é a terceira etapa dessa escada: um agente. O nome é mais dramático que a coisa: agente é uma IA que, além de responder, executa ações. Ele trabalha dentro da pasta do seu projeto, então enxerga o que existe, cria e edita arquivos, roda o site na sua máquina, lê a mensagem de erro quando algo quebra e propõe uma correção. Também pode errar a causa. A diferença prática é essa: em vez de te entregar peças, ele monta o móvel sob revisão. Você fica com o papel de quem encomendou: define o que quer, olha o resultado, pede ajuste.

Escrevi em outro artigo que o designer que trabalha com IA vira arquiteto de contexto: o valor não está em decorar prompts, está em estruturar o que a IA precisa saber. Este guia é esse princípio aplicado ao caso mais concreto possível, o seu próprio site.

Quatro ferramentas, um fluxo

Quatro ferramentas sustentam o fluxo. Uma ponte opcional aparece no final da lista. Vamos desarmar os nomes um por um, porque cada peça tem função clara:

Terminal é a janela onde você digita instruções de texto pro computador, em vez de clicar. É a porta de entrada do Claude Code. Você vai usar meia dúzia de comandos, todos copiáveis deste guia; ninguém aqui vai decorar terminal.

GitHub é onde os arquivos do projeto ficam guardados com o histórico que você registrou. Pense numa sequência organizada de pontos de salvamento: cada versão que entrou num commit, como se chama cada ponto de salvamento, pode ser comparada e recuperada. É também de onde o site é publicado.

Netlify é o serviço que pega os arquivos do GitHub, monta o site e o serve na internet, numa URL pública, com certificado de segurança (o cadeado do navegador) incluído.

Claude Code é o agente que costura tudo: lê, cria, testa e prepara cada etapa.

E MCP? É a sigla que mais gera confusão e a que você menos precisa agora. MCP (Model Context Protocol) é um padrão que funciona como ponte entre a IA e serviços externos: com a ponte ligada, o Claude consegue operar seu Netlify direto, com a sua autorização. É opcional. O Claude Code fala com GitHub e Netlify pelo terminal sem nenhum MCP, e este guia tem os dois caminhos.

Esse fluxo é o mapa mental do guia inteiro: você dirige o Claude, o Claude constrói os arquivos, os arquivos sobem pro GitHub, o Netlify publica. Quando algo der errado, localizar em qual estação do fluxo o problema mora já é metade do conserto.

Monte o terreno antes de pedir a casa

Hora de preparar o terreno. Escolha uma rota de acordo com sua disposição, sabendo que dá pra trocar depois.

Rota guiada (recomendada): tudo pelo Claude Code. Instale o Claude Code seguindo a documentação oficial de instalação. Em agosto de 2026, o instalador nativo não exige Node.js, o programa usado para executar muitos projetos de site. Abra o terminal (no Mac: aperte Cmd+Espaço e digite "Terminal"; no Windows: abra o menu Iniciar e digite "PowerShell") e cole o comando do seu sistema:

Instalou? Feche e reabra o terminal, digite claude --version e aperte Enter. Um número confirma o Claude Code, não o ambiente inteiro. Digite também git --version; Git é o sistema que registra versões e envia os arquivos ao GitHub. Se o segundo comando falhar, siga o guia oficial do GitHub para começar com Git antes de construir. Depois crie ou acesse suas contas no GitHub e no Netlify, ambas com cadastro gratuito. Se quiser a ponte MCP com o Netlify, o serviço tem um guia próprio pra Claude Code; a conexão usa login autorizado, nunca senha colada em arquivo.

Rota simplificada: sem MCP, com as interfaces dos sites. O Claude Code constrói o projeto na sua máquina; você cria o repositório (a pasta do projeto que fica guardada no GitHub, explicada em detalhe mais adiante) clicando pelo site do GitHub, sobe os arquivos com os comandos guiados que o próprio Claude te passa e conecta o repositório ao Netlify pela interface deles ("Add new project", importar do GitHub, confirmar). Depois que a publicação contínua estiver configurada, cada atualização enviada dispara uma nova tentativa de publicação. As duas rotas chegam ao mesmo destino; esta exige mais ações manuais.

Uma regra vale pras duas rotas: teste cada conexão antes de seguir pra próxima. Conta criada? Faça login. Claude instalado? Rode claude --version. Git disponível? Rode git --version. Erros de ambiente descobertos cedo custam minutos; descobertos no meio, custam a tarde.

Três controles que devolvem a direção pra você

Comece o diagnóstico em Plan Mode, o modo que permite investigar e planejar sem editar arquivos. Abra a sessão com:

Durante a sessão, Esc interrompe a ação atual. /rewind abre os pontos de retorno do Claude Code para voltar a uma conversa, ao código ou aos dois. claude --continue retoma a conversa mais recente naquela pasta. São controles nativos documentados nas boas práticas, no guia de como o Claude Code funciona e nos fluxos comuns. Eles reduzem o custo do erro. Não substituem um commit, que é o registro revisado da versão no Git.

O primeiro entregável não é código

Aqui entra o hábito mais barato e mais subestimado do método: escrever um briefing antes de pedir qualquer código. Designer entende disso melhor que ninguém: ninguém abre o Figma sem saber pra quem é o produto. Com IA é igual. Um briefing específico evita correções previsíveis e tende a consumir menos limite de uso do que uma conversa caótica, porque cada correção abre outra rodada de processamento.

Agora existem dois artefatos dentro da pasta. CONTEUDO.md guarda a matéria-prima real: bio, experiência, projetos, decisões, evidências e resultados. BRIEFING.md dirige a construção: público, arquitetura, direção visual, restrições e critério de pronto. Um não substitui o outro. Crie o BRIEFING.md e preencha:

Não sabe responder um campo? Escreva "não sei, me recomende" no campo. Isso também é informação: diz ao Claude onde ele decide e onde ele pergunta.

O primeiro prompt deve terminar sem código

A tentação é abrir o Claude Code e pedir "crie meu portfólio completo". Resista. Pedido gigante gera resposta gigante, consumo gigante e um monte de decisão tomada sem você. O primeiro prompt do método não constrói nada: ele analisa, pergunta o mínimo e devolve um plano. Barato, rápido e te deixa no comando.

O prompt abaixo é para projeto novo. Se você já tem site ou template, não crie outra base e não cole um prompt de construção por cima: abra a rota de base existente no workspace, que primeiro faz o inventário de arquivos, dependências (os pacotes externos de código que o projeto usa), licença e estado do Git. Se o site já está pronto, a rota de publicação pula direto para ambiente, revisão e deploy.

Para projeto novo, confirme que CONTEUDO.md e BRIEFING.md estão dentro da pasta que você criou. Abra o terminal nessa pasta. O truque pra quem nunca fez isso: abra o terminal, digite cd (com um espaço depois) e arraste a pasta do Finder ou do Explorer pra dentro da janela; o caminho se preenche sozinho, aí é só apertar Enter. Rode claude --permission-mode plan e cole:

Você vai planejar um projeto novo de portfólio. Leia BRIEFING.md e CONTEUDO.md como fontes.

1. Confirme que a pasta está vazia ou liste qualquer arquivo inesperado. Se houver projeto existente, pare.
2. Liste apenas o conteúdo indispensável que falta e faça as perguntas essenciais de uma vez.
3. Proponha a arquitetura mínima e a base técnica mais simples e estável, com o mínimo de dependências.
4. Estime esforço, riscos e decisões que continuam sendo minhas.
5. Devolva o plano no chat, em etapas numeradas, e pare.

É um projeto novo. Não instale, não crie, não altere nem apague arquivos. Aguarde minha aprovação.

O Plan Mode não edita arquivos. O plano aparece na conversa, e isso é parte da proteção. Leia de verdade: se ele propõe cinco páginas e você pediu uma, corrija agora, em texto, quando mudar custa uma frase.

Quando o plano estiver certo, saia do Plan Mode. Pressione Shift+Tab até o indicador voltar ao modo padrão, no qual mudanças pedem sua aprovação. Então cole:

Saí do modo de planejamento e aprovei o plano apresentado no chat.
Salve exatamente esse plano em um arquivo chamado PLANO.md dentro da pasta atual.
Não implemente nenhuma etapa, não instale nada e não altere outro arquivo.
Ao terminar, informe apenas o caminho do PLANO.md criado e pare.

Aprove apenas a criação de PLANO.md e confirme que o arquivo apareceu na pasta. Construção nenhuma começou ainda. Essa separação transforma uma intenção aprovada em fonte de trabalho sem abrir a porta para implementação antecipada.

Oito prompts, oito decisões suas

Com o plano aprovado e salvo, a construção anda em seis etapas independentes, do prompt 2 ao 7. Cada prompt abaixo tem escopo fechado de propósito: diz o que fazer, o que reutilizar e o que não tocar. Isso evita o efeito mais irritante de trabalhar com IA, que é pedir um ajuste no rodapé e receber um site redesenhado. Rode um por vez, revise no navegador, só então avance. Se seu limite de uso acabar no meio, sem drama: o progresso fica salvo nos arquivos, e você continua na sessão seguinte do ponto onde parou.

O prompt 1 você já rodou: é o diagnóstico da seção anterior. O prompt 8 fica reservado para depois da sua revisão humana, quando o site estiver pronto para sair da máquina.

Execute esta etapa apenas se a fundação visual estiver no PLANO.md aprovado. Implemente tipografia, escala de espaçamento, cores com contraste adequado, grid e navegação.
Use o BRIEFING.md como fonte das decisões visuais.
Preserve toda estrutura existente que o plano não colocou no escopo. Não crie conteúdo nem páginas além do esqueleto de navegação.
Não altere arquivos fora do projeto.
Ao terminar, rode o projeto localmente e informe a URL exata pra abrir no navegador.
Não avance pra próxima etapa.

Ao terminar, entregue um recibo curto com:
- arquivos alterados;
- comando de verificação executado e código de saída, o número que indica sucesso ou falha;
- o que você verificou no navegador;
- o que não conseguiu verificar e ainda depende de revisão humana.

Execute esta etapa apenas se a página inicial estiver no PLANO.md aprovado. Implemente a página com o conteúdo real de BRIEFING.md e CONTEUDO.md: apresentação, projetos em destaque, resumo de experiência e contato.
Não invente texto, número, cargo ou resultado. Onde faltar conteúdo, insira [PREENCHER] e liste todos os marcadores no final.
Reutilize a fundação visual pronta. Preserve toda estrutura existente que o plano não colocou no escopo. Não altere tipografia nem cores.
Abra a página no navegador e verifique navegação, conteúdo e erros no console, a área que mostra mensagens técnicas do site.

Ao terminar, entregue um recibo curto com:
- arquivos alterados;
- comando de verificação executado e código de saída, o número que indica sucesso ou falha;
- o que você verificou no navegador;
- o que não conseguiu verificar e ainda depende de revisão humana.

Execute esta etapa apenas se projetos estiverem no PLANO.md aprovado. Leia BRIEFING.md, CONTEUDO.md e a arquitetura aprovada no plano.
Se o plano define página única, crie ou complete a seção de projetos e estudos de caso nessa mesma página. Se define arquitetura completa, crie a listagem e as páginas individuais previstas. Use estas seções quando houver material: resumo, contexto, desafio, minha responsabilidade, decisões, evidências e resultado.
Preencha apenas com o conteúdo de CONTEUDO.md. Texto que não existe vira [PREENCHER], nunca invenção.
Preserve toda estrutura existente que o plano não colocou no escopo. Não altere a fundação visual.
No final, liste as seções ou páginas criadas, os endereços de acesso e os marcadores pendentes.

Ao terminar, entregue um recibo curto com:
- arquivos alterados;
- comando de verificação executado e código de saída, o número que indica sucesso ou falha;
- o que você verificou no navegador;
- o que não conseguiu verificar e ainda depende de revisão humana.

Revise o site inteiro em três larguras de tela: 375 px, 768 px e 1280 px. Corrija apenas problemas de layout, sem redesenhar.
Faça uma revisão de acessibilidade: navegação por teclado, foco visível, contraste, texto alternativo em imagens, hierarquia correta de títulos e respeito a prefers-reduced-motion, a preferência do sistema por menos animação.
Não declare que um leitor de tela foi testado se você não tiver executado esse teste.

Ao terminar, entregue um recibo curto com:
- arquivos alterados;
- comando de verificação executado e código de saída, o número que indica sucesso ou falha;
- o que você verificou no navegador;
- o que não conseguiu verificar e ainda depende de revisão humana.

Configure o básico de SEO, o conjunto de dados que ajuda buscadores e cartões de compartilhamento a entender o site, sem instalar dependências novas.
Inclua título e descrição únicos por página, Open Graph para o cartão de preview, sitemap.xml para listar as páginas, favicon para o ícone da aba e URLs limpas.
Aponte textos confusos ou genéricos, mas não os reescreva sem me mostrar antes.

Ao terminar, entregue um recibo curto com:
- arquivos alterados;
- comando de verificação executado e código de saída, o número que indica sucesso ou falha;
- o que você verificou no navegador;
- o que não conseguiu verificar e ainda depende de revisão humana.

Rode o build de produção, a geração da versão final do site, e corrija apenas erros causados ou pertencentes a este projeto.
Depois verifique links quebrados, imagens ausentes, marcadores [PREENCHER], páginas órfãs e erros no console do navegador.
Não adicione nenhuma funcionalidade nova. Se encontrar um problema fora do escopo ou não relacionado, pare e reporte antes de mudar.

Entregue um recibo de prontidão com:
1. comando executado e código de saída;
2. rotas verificadas e resultado de cada uma;
3. larguras de tela abertas no navegador;
4. erros de console encontrados;
5. pendências que dependem de mim;
6. qualquer item que não conseguiu verificar. Não trate ausência de teste como aprovação.

Seis prompts de construção, seis etapas de revisão suas. Repare no padrão que se repete: fonte, objetivo, limite, pausa e prova. A fonte diz onde buscar verdade. O objetivo fecha a entrega. O limite protege o que não deve mudar. A pausa devolve a decisão. A prova mostra o que realmente aconteceu.

Chamo a última prova de recibo de prontidão. Não é um "está tudo certo" escrito pelo mesmo agente que fez a mudança. É um registro curto que você consegue conferir:

O atalho remove o que torna o método seguro

O atalho de pedir o site inteiro numa conversa só elimina justamente o que torna o método confiável: plano antes de código, uma mudança por vez, revisão no navegador e prova antes de avançar. Um prompt enorme pode repetir essas palavras, mas continua concentrando contexto, decisões e risco numa execução difícil de interromper e cara de revisar.

O caminho curto é reduzir o escopo da primeira versão, não remover as pausas. Uma página, dois projetos, seis etapas de construção. Menos site. Mesma disciplina.

O portfólio médio da IA tem quatro vícios

Peça um portfólio a uma IA sem direção e você tende a receber algo tecnicamente plausível e completamente esquecível. O problema não é a origem da ferramenta. É a repetição sem critério. Os sinais se agrupam em quatro vícios, e cada um tem conserto de uma frase.

Vício 1: decoração sem função. Gradientes aleatórios, glassmorphism (o efeito de vidro fosco) em todo bloco, animação em cada elemento que entra na tela, cursor customizado brilhando. Cada efeito compete com seu trabalho pela atenção do visitante, e efeito pesado ainda derruba o desempenho no celular. O portfólio é a moldura; o quadro são os projetos.

Vício 2: conteúdo que ninguém escreveu. Frase de abertura vazia ("Transformando ideias em experiências"), texto que parece currículo corporativo, métricas sem fonte ("aumentei a conversão em 300%"), depoimentos genéricos, simulações de tela de banco de imagem sem contexto. É o vício mais grave, porque mina a única moeda que portfólio tem: credibilidade. A regra é a mesma que dei ao Claude nos prompts: nada de inventar. Se a frase de abertura pudesse estar no site de qualquer designer, ela não diz nada sobre você.

Vício 3: hierarquia invertida. Bloco inicial gigante que ocupa a tela inteira com o seu nome, projetos escondidos três rolagens abaixo, blocos todos idênticos onde o projeto forte tem o mesmo peso do exercício de curso. O visitante veio ver trabalho; faça o trabalho aparecer antes que a rolagem canse.

Vício 4: peso invisível. Fotos genéricas de banco de imagem, ícones de três bibliotecas diferentes misturados, fontes demais, efeitos que travam o celular. Individualmente pequenos, juntos gritam "montado sem revisão".

A boa notícia sobre esses quatro vícios: quem sabe reconhecê-los é você. É exatamente o olho de designer que a IA não substitui, e é por isso que a revisão fecha cada etapa do método.

Um case forte mostra encruzilhadas

Existe um formato de estudo de caso que todo mundo aprendeu e todo recrutador já decorou: dupla diamante, persona, jornada, wireframe, telona final, "aprendi muito". Não é errado. É previsível, e previsível não diferencia ninguém.

A estrutura que recomendo conta uma história de decisões, não de etapas:

1. Resumo: o projeto em 3 linhas, com resultado
2. Produto e contexto: onde isso aconteceu, que momento era
3. Desafio: o problema real, não o enunciado polido
4. Minha responsabilidade: o que era seu, explícito (times existem, recrutador sabe)
5. Restrições: prazo, tecnologia, política. Restrição dá mérito à solução
6. Decisões principais: 2 ou 3 encruzilhadas e por que você virou pra onde virou
7. Evidências: teste, dado, feedback, o que sustenta as decisões
8. Solução: agora sim, as telas
9. Resultado: número com fonte, ou a consequência real que dá pra afirmar
10. Aprendizados e próximos passos: o que faria diferente

Nem todo projeto precisa das dez seções, e é bom que não precise: um case forte de 6 seções vale mais que um fraco de 10 esticadas. Priorize onde houve conflito, trade-off (a troca consciente de um benefício por outro) e impacto. Processo completo é o que todo mundo mostra; decisão sob restrição é o que ninguém consegue copiar.

Pra sair das notas bagunçadas e chegar nessa estrutura, use o Claude como organizador, com a trava de sempre contra invenção. Antes de colar, releia as notas e substitua qualquer credencial, dado pessoal, nome protegido ou material coberto por NDA pelos marcadores definidos no CONTEUDO.md.

Referência sem critério vira colagem

Referência boa acelera; referência mal digerida transforma o site numa colagem. Eu mantenho uma biblioteca de referências de design com IA aqui no site, organizada por categoria, incluindo portfólios, tipografia, componentes e acessibilidade, e ela funciona como anexo natural deste guia.

Catálogos de componentes prontos podem ajudar, mas envelhecem e mudam de licença. Trate qualquer biblioteca externa com a mesma régua de um sistema de design, o conjunto de regras e componentes reutilizáveis que mantém as telas coerentes: compatível com a sua base técnica, licença de uso adequada, adaptada aos seus tokens (as regras de cor, fonte e espaçamento), testada no celular e respeitando movimento reduzido. Componente instalado "pra parecer sofisticado" é o vício 1 de novo, só que terceirizado.

Antes de instalar qualquer um, faça o Claude auditar:

Direção visual cabe em dez respostas

"Escolha uma cor" não é direção visual. Direção é um conjunto pequeno de decisões coerentes, e dá pra chegar nele respondendo dez perguntas num papel: três adjetivos que o site deve transmitir; três referências com o que tirar de cada uma; quanta animação (nenhuma, sutil, presente); densidade (arejado ou compacto); contraste (suave ou marcado); uma cor principal e por quê; fonte com serifa, sem, ou uma de cada; fotografia real, ilustração ou nenhuma das duas; o que o visitante deve sentir em 5 segundos; e o que o site não pode parecer de jeito nenhum.

As respostas viram um bloco no seu BRIEFING.md, e o Claude passa a ter critério visual em toda decisão, em vez de puxar pro gosto médio da internet.

No guia interativo que acompanha este artigo, a etapa de briefing traz essas dez perguntas em template pronto pra copiar e um gerador que monta o prompt inicial personalizado a partir das suas respostas. Tudo roda no seu navegador: nada do que você digita é enviado pra servidor nenhum.

No ar ainda não é pronto

Um site no ar ainda pode estar errado. Por isso, neste método, a revisão acontece antes do primeiro envio público. Faça cinco passadas, cada uma com pergunta própria:

Conteúdo. Os projetos são reais e as responsabilidades estão claras? As decisões estão explicadas? Todo número tem fonte? O contato está visível sem caçada? Os textos foram lidos em voz alta uma vez (o teste mais barato que existe contra texto artificial)?

Experiência. A navegação se explica sozinha? Os projetos são encontráveis em um clique? A leitura é confortável no celular? Botões e links reagem quando tocados?

Acessibilidade. Dá pra navegar o site inteiro só com Tab e Enter? O foco está sempre visível? Toda imagem informativa tem texto alternativo? Títulos seguem hierarquia? Movimento respeita quem pediu menos movimento? Alvos de toque têm tamanho digno de dedo?

Desempenho. Imagens comprimidas? Fontes só as necessárias? O site abre rápido num celular mediano com rede mediana, não no seu computador de trabalho com fibra?

SEO e compartilhamento. Cada página tem título e descrição únicos? O link compartilhado no LinkedIn mostra um cartão decente? O sitemap existe? A URL é limpa e compreensível?

O guia interativo tem essa revisão como checklist clicável que salva seu progresso no navegador, sem conta e sem cadastro. Pro fechamento técnico, o prompt 7 da construção cobre a auditoria automatizável; esta revisão aqui cobre o que só olho humano pega.

Terminou as cinco passadas e resolveu as pendências? Agora começa a publicação. O prompt 8 abre essa fase com revisão de credenciais e confirmação dos destinos. Ele deve parar antes de cada envio; as duas seções seguintes explicam o vocabulário e os campos que você precisa conferir antes de aprovar.

Prepare o projeto pra publicação. Confira se o .gitignore, o arquivo que impede o envio de itens locais, exclui node_modules, a pasta de pacotes instalados, arquivos .env de configuração local e qualquer credencial.
Revise os arquivos procurando segredos ou dados pessoais que não devem ser públicos. Se encontrar uma credencial, informe o tipo e o arquivo, sem repetir o valor.
Confirme a pasta atual, o repositório do GitHub e o site de destino no Netlify. Mostre os três destinos e espere minha confirmação.
Depois me guie, um passo de cada vez, para registrar a versão em Git, enviar ao GitHub e conectar o repositório ao Netlify.
Espere minha confirmação antes de cada envio. Nunca desative proteções, nunca exponha valores de variáveis de ambiente e nunca publique em outro destino por suposição.

Ao terminar, entregue um recibo curto com:
- arquivos alterados;
- comando de verificação executado e código de saída, o número que indica sucesso ou falha;
- o que você verificou no navegador;
- o que não conseguiu verificar e ainda depende de revisão humana.

GitHub vira seguro depois do primeiro commit

Chegou a hora de tirar o projeto da sua máquina. Vocabulário mínimo, sem cerimônia:

Repositório é a pasta do projeto hospedada no GitHub, com o histórico registrado. Commit é um ponto de salvamento: uma foto revisada do projeto naquele momento, com uma descrição como "adiciona case da fintech". Push é enviar seus commits da sua máquina pro GitHub. O histórico só protege o que entrou num commit. Arquivo criado e apagado antes disso pode não ter volta. O seguro começa quando você registra a versão.

Público ou privado? O plano gratuito do GitHub permite repositórios ilimitados dos dois tipos. Público significa que qualquer pessoa vê o código, mas não ganha permissão pra editar. Privado limita o acesso a você, às pessoas convidadas e aos aplicativos autorizados. Pra portfólio, os dois funcionam. Confirme essa escolha antes do primeiro push.

A regra inegociável é uma só: credencial nunca entra em repositório. É pra isso que existe o .gitignore, um arquivo que lista o que o Git deve ignorar e nunca versionar: senhas, chaves, arquivos de ambiente, a pasta de dependências. Um detalhe que importa: ele não apaga segredo que já entrou no histórico, só impede os próximos. Por isso o prompt 8 configura o seu antes do primeiro envio, e a revisão antes de cada commit mantém.

Um limite prático pra conhecer antes do primeiro push: o GitHub bloqueia arquivos individuais acima de 100 MB. Imagem comprimida costuma ficar muito abaixo disso, mas vídeo pode passar. Vídeo pesado não entra no repositório: reduza o arquivo ou hospede fora e incorpore no site.

E aqui o Claude vira seu revisor de segurança permanente. Antes de qualquer envio importante, o hábito:

Não entendeu o que uma mudança faz? "Me explica essa mudança antes de commitar" é um prompt perfeitamente válido, e é o equivalente técnico de pedir pro dev explicar o que vai subir. A diferença é que esse dev não revira os olhos.

Registre um commit depois de cada etapa que você revisou, não depois de cada tentativa. O ponto de retorno do Claude ajuda a desfazer uma interação; o commit preserva uma versão intencional do projeto. São proteções diferentes.

O deploy começa antes do botão de publicar

Deploy é o ato de publicar: pegar os arquivos, montar a versão final e disponibilizar na internet. No Netlify, isso vira um circuito automático: você conecta o repositório uma vez e cada push futuro dispara uma nova tentativa de deploy. A duração varia com o projeto e a fila do serviço. O painel mostra quando terminou.

O caminho pela interface: entre no painel do Netlify, escolha "Add new project", importe do GitHub, autorize e selecione o repositório que acabou de confirmar. O Netlify tenta detectar a base técnica e preencher dois campos: o comando de build (a instrução que monta o site) e a pasta de publicação (onde a versão montada fica). Não aceite por reflexo. Compare com a verificação abaixo. Quando o painel marcar o deploy como publicado, abra a URL .netlify.app no celular e no computador. Domínio próprio é outro passo e a compra do endereço tem custo separado.

Vou conectar este projeto ao Netlify. Me responda:
1. Confirme a pasta atual, o repositório do GitHub e o site de destino no Netlify. Pare se algum destino for ambíguo.
2. Qual é o comando de build e qual pasta contém o site pronto?
3. Rode o build de produção local e reporte o comando e o código de saída.
4. Alguma variável de ambiente é necessária? Liste só os nomes, nunca os valores.
5. Algo depende de uma versão específica do Node, o programa que executa a montagem de muitos sites? Mostre onde está definido.
6. Liste as rotas que eu preciso abrir depois do deploy.
Se encontrar problema, reporte a causa e a correção proposta. Não altere nem envie nada antes da minha confirmação.

Sobre limites, o aviso que permite calcular: em agosto de 2026, contas novas do Netlify Free recebem 300 créditos por mês. Cada deploy de produção usa 15 créditos. Cada GB de banda, o volume de dados entregue aos visitantes, usa 20. Vinte deploys sem tráfego já consumiriam os 300 créditos; tráfego reduz essa quantidade. Se os créditos acabarem, o site pausa até o ciclo seguinte, sem cobrança. O consumo fica visível no painel. Reconfirme os valores na fonte quando publicar.

E quando o deploy falha? O log, o registro textual da tentativa, mostra onde investigar. Antes de copiar qualquer trecho, remova tokens, valores de variáveis, emails e dados pessoais. O roteiro de diagnóstico dos oito sintomas mais úteis, do build vermelho à página em branco, está na seção de problemas do guia interativo. Cada item começa por identificar a base técnica e provar a causa antes de editar.

Manutenção boa é pequena

A vantagem menos óbvia de ter um site próprio construído assim: atualizar não exige recomeçar do zero. Cada mudança futura é um prompt pequeno, com a mesma disciplina de escopo dos oito prompts numerados do método. Três exemplos do dia a dia:

O padrão dos três: alterar só o necessário, confirmar que o resto continua de pé, build verde antes de push. A versão interativa tem a lista completa de dez prompts de manutenção, incluindo troca de imagem, página nova, atualização de dependências e revisões periódicas de SEO e acessibilidade.

A assinatura continua sendo sua

Se este guia deu certo, ele te convenceu de que a parte técnica encolheu. O que ele não pode fazer é encolher a sua parte, porque ela não é técnica. Continua sendo seu, e só seu, validar:

• A verdade do conteúdo: cada projeto, número e responsabilidade que o site afirma
• A qualidade da curadoria: quais projetos entram e quais ficam de fora (cortar é design)
• A narrativa: se os cases contam decisões ou só listam etapas
• A hierarquia e o visual: se o site parece você ou parece o gosto médio da internet
• A privacidade: o que sobre você e sobre clientes pode ser público (NDA é um acordo de confidencialidade; cheque os seus)
• A acessibilidade real: testada com Tab e leitor de tela, não presumida
• As permissões concedidas: cada comando aprovado no Claude, cada acesso autorizado
• Os custos: os limites de cada ferramenta, verificados nas páginas oficiais, hoje e daqui a seis meses

A IA mudou o custo de construir. Não mudou de quem é a assinatura.

A primeira versão precisa existir, não impressionar

O roteiro mínimo cabe em quatro linhas: salve CONTEUDO.md e BRIEFING.md, rode o diagnóstico e salve o plano, execute os prompts 2 a 7 com revisão entre eles, faça a revisão humana e só então rode o prompt 8. Um portfólio simples no ar evolui toda semana com prompts de manutenção. Uma pasta perfeita no seu computador não abre nenhuma porta.

Daqui, três caminhos:

• Abra o guia interativo: o mesmo método em formato de painel de trabalho, com etapas, checklists que salvam progresso, gerador de prompt personalizado e diagnóstico de problemas
• Explore os outros recursos pra designers: prompts, referências, vocabulário de frontend e frameworks de IA
• Se quiser acompanhamento de gente, não de agente, na construção do seu portfólio ou na transição pra design com IA, conheça minha mentoria

E quando o seu portfólio estiver no ar, me manda o link no LinkedIn. Sério. Quero ver o que você construiu quando parou de esperar saber programar.