jove525/portfolio-builder

Portfolio Builder

Transforma o trabalho de uma pessoa em um portfólio de uma página. Claude planeja o conteúdo no chat, bloqueia em um BRIEF.md e então entrega prompts para Claude Code. Claude Code constrói localmente, envia para o GitHub e faz o deploy no Netlify. Claude então audita o repositório e o site ao vivo.

Regras de escrita para tudo que esta skill produz: tom casual e direto, frases curtas, sem travessões (apenas hífens comuns).

Fase 1: Coletar antes de perguntar

• Puxe o que já é conhecido: memória, conversas passadas, sites ao vivo (busque-os para listas reais de funcionalidades e cópia).
• Faça um inventário de conteúdo primeiro. Nunca comece com um questionário em branco.

Fase 2: Rascunho do brief v1, depois pergunte no máximo 4 decisões

Esboce seções com cópia real, depois pergunte apenas o que muda a construção:

1. Público-alvo (clientes, gerentes de contratação, ou ambos, e qual lidera).
2. Restrições de visibilidade (empregador atual nomeado ou genérico; algo a manter privado).
3. Quais projetos entram.
4. Onde fica (um subdomínio Netlify para começar é suficiente).

Diretrizes:

• Nenhuma métrica, depoimento ou cliente inventado.
• Nenhuma afirmação que a pessoa não tenha feito (por exemplo, trabalho com IA em um emprego diário que ela não fez).
• Vitórias em equipe creditadas como vitórias da equipe.
• Se o empregador ficar genérico, também omita detalhes que o identifiquem (listas de países, títulos exatos mais setor). Diga "cinco mercados", não a lista.
• Cuidado com a redação de região (por exemplo, "mercados asiáticos" quando um país abrange continentes) e pronomes vagos na cópia do herói.

Regra de inclusão de projeto: um projeto merece um lugar quando está ao vivo e mostra uma habilidade pela qual o público pagaria. Muitos empreendimentos sinalizam "não tenho tempo para você." Trabalhos parados ou passados vão em uma pequena linha "Do laboratório", rotulados honestamente. Projetos sem nome ou não lançados esperam.

Ferramentas: liste apenas ferramentas usadas na prática. Ferramentas com as quais a pessoa é apenas familiarizada vão em uma nota de rodapé de uma linha ("Também confortável com X e Y").

Fase 3: Preencher as lacunas

Peça: nome de exibição, foto, uma captura de tela por construção, URLs ao vivo, URL do GitHub, e-mail de contato, redes sociais. Reescreva qualquer cópia de site fornecida para ser apropriada para portfólio (o que é, para quem é, o que construíram). Todo link de cartão deve apontar para uma página ao vivo que realmente descreva aquele item. Se a página não estiver pronta, sem link e marque-a (por exemplo, "Lançamento"). Adie qualquer coisa não pronta (link de agendamento, "trabalhe comigo", depoimentos) para uma lista "Depois" em vez de bloquear a v1.

Fase 4: Bloquear BRIEF.md

Escreva BRIEF.md com estas seções, em ordem:

• Objetivo (teste de 10 segundos: o que constroem, prova, como alcançá-los)
• Público
• Regras para cópia (tom, sem travessões, diretrizes de visibilidade e precisão, use a cópia como escrita)
• Tecnologia (HTML/CSS/JS puro, sem build step; index.html, styles.css, main.js, /assets; GitHub + Netlify; Lighthouse 95+; mobile first)
• Direção de design (padrão Apple-like: fonte Inter ou do sistema, bastante espaço em branco, largura máxima ~1080px, blocos de texto ~680px, títulos grandes e apertados, paleta neutra, raio de cartão 20-24px, bordas finas, um acento usado com moderação, claro/escuro com alternância, fade-up sutil respeitando reduced motion, capturas de tela em um cartão minimalista com moldura de navegador, nav pegajosa e desfocada)
• Regras de layout (incorpore-as desde o início):
  • Nav e cada seção compartilham um contêiner, para que todas as bordas esquerdas se alinhem.
  • Um token de espaçamento entre seções (cerca de 96px desktop, 56px mobile) para cada lacuna; sem paddings empilhados.
  • Herói cabe acima da dobra em 1366x768 e 375x812 incluindo barras de ferramentas do navegador (cerca de 650px e 635px visíveis).
  • Título: text-wrap pretty no mobile, balance no desktop; sem quebras de linha forçadas.
  • Cada seção tem um título visível ou rótulo, para que nada flutue.
• Ativos (caminhos de arquivo exatos; capturas de tela convertidas para WebP com tamanhos menores para mobile, lazy-load abaixo da dobra; placeholder se faltar, nunca uma imagem quebrada)
• Conteúdo da página, de cima a baixo, com cópia final: Herói, O que faço (3 cartões), Construções (cartão em destaque + grade + linha do laboratório), Como construo, Ferramentas (pílulas agrupadas), Faixa de fundo, Princípios (nas próprias palavras da pessoa, não citações emprestadas), Contato, Rodapé
• SEO e meta (título, descrição, imagem OG, favicon, HTML semântico, texto alternativo, estados de foco, contraste AA)
• Detalhes pré-preenchidos: URL do repositório, subdomínio preferido mais alternativo, perfis sociais, e-mail, para que Claude Code não precise perguntar
• Depois (não na v1)

Cor de acento: escolha uma que se separe das cores nas capturas de tela das construções. Dê valores hexadecimais exatos para modo claro e escuro, e verifique contraste AA para links E texto de botões no acento em ambos os modos (botões no modo escuro geralmente precisam de texto escuro em um acento claro).

Entregue BRIEF.md como um arquivo.

Fase 5: Passos de configuração + 4 prompts

Configuração (uma vez):

1. Crie um repositório vazio no GitHub, então git clone <repo-url> em uma pasta local para que o git já esteja configurado.
2. Coloque BRIEF.md na raiz; adicione /assets e /assets/shots com os arquivos nomeados.
3. Abra Claude Code nessa pasta.

Prompt 1, Planejar:

Leia BRIEF.md completamente. Ainda não escreva código.
Me dê um plano de construção curto: estrutura de arquivos, layout seção por seção, os tokens de cor e escala tipográfica que você usará, e quaisquer perguntas ou conflitos que você veja no brief. Mantenha em menos de uma tela.
Cor de acento: <LIGHT_HEX> no modo claro, <DARK_HEX> no modo escuro. Use com moderação e confirme que ambos passam no contraste AA, incluindo texto de botão.

Ajude a pessoa a responder às perguntas em uma resposta colável.

Prompt 2, Construir:

Construa o site exatamente conforme BRIEF.md e o plano que acordamos.
- Use a cópia palavra por palavra. Sem travessões em lugar nenhum.
- HTML puro, CSS, JS puro. Sem frameworks, sem build step.
- Acento: <LIGHT_HEX> claro, <DARK_HEX> escuro. Todo o resto neutro.
- Siga as regras de layout em BRIEF.md (contêiner compartilhado, um token de espaçamento, herói acima da dobra).
- Use as imagens em /assets como WebP. Mostre um placeholder limpo se uma estiver faltando.
- Modo claro e escuro, nav pegajosa desfocada, fade-up no scroll com suporte a reduced motion.
Quando terminar, inicie um servidor local e me diga a URL para que eu possa revisar.

Prompt 3, Polir:

Revise o site como um designer sênior da Apple faria, então corrija o que encontrar:
1. Verifique em 375px, 768px, 1366px e 1440px. Sem scroll horizontal, nada apertado.
2. Todas as bordas esquerdas alinhadas; cada lacuna de seção usa o único token de espaçamento.
3. Herói cabe acima da dobra com barras de ferramentas do navegador em 1366 e 375.
4. Modo escuro parece intencional, não invertido. Acento é legível em ambos os modos.
5. Acessibilidade: texto alternativo, estados de foco, contraste AA, títulos semânticos.
6. Pesquise todos os arquivos por travessões e substitua-os.
7. Execute Lighthouse e obtenha todas as quatro pontuações para 95+.
Me dê uma lista curta do que você mudou.

Então a pessoa dá feedback em linguagem simples até ficar satisfeita.

Prompt 4, Enviar e implantar:

Esta pasta já está clonada de <REPO_URL>.
1. Adicione um .gitignore e um netlify.toml (publish dir = raiz, cabeçalhos de cache sensatos, e 404 para BRIEF.md e PNGs fonte para que não sejam públicos).
2. Commite tudo com uma mensagem clara e envie para main.
3. Conecte o repositório ao Netlify. Tente <SUBDOMAIN> primeiro, alternativo <FALLBACK>. Se o app GitHub do Netlify não conseguir ver o repositório, me diga como conceder acesso.

Nota: Claude Code frequentemente avança e faz construção, polimento e implantação de uma vez. Tudo bem; pule para a auditoria.

Fase 6: Auditoria após o envio

Quando o repositório ou URL ao vivo for compartilhado:

1. Clone o repositório e verifique: cópia corresponde ao BRIEF.md, nada inventado, sem travessões, sem nomes restritos, todos os links corretos, imagens WebP com texto alternativo e tamanhos, meta/OG/favicon presentes, arquivos internos bloqueados do site ao vivo.
2. Inspeção visual no site ao vivo no navegador em 1440 e 1366 (claro) e 375 (escuro): alinhamento de bordas, consistência de lacunas, herói acima da dobra, quebra de título, nada sobreposto.
3. Dê correções como um prompt colável para Claude Code, então verifique novamente após o envio. Se o repositório estiver vazio, diga isso claramente e peça para enviarem primeiro.

Pegadinhas conhecidas:

• Netlify adiciona um selo "Desenvolvido por Netlify" em projetos do plano Gratuito criados após 19 de agosto de 2026. Não está no código: desligue em Configuração do projeto > Geral > Selo Desenvolvido por Netlify, por projeto.
• Pontuações ao vivo do Lighthouse de conexões lentas variam; julgue com pagespeed.web.dev, não apenas execuções locais.

Fase 7: Sincronizar o resto da presença

Ofereça alinhar o README do perfil do GitHub (e outras bios) com o portfólio: mesma linha de posicionamento, mesmo e-mail de contato, links para as construções ao vivo e o portfólio, e remova projetos que o portfólio intencionalmente deixou de fora.