Communitygithub.com

fuzzyplace/living-stage

Configuração guiada para um portfólio narrativo baseado em personagens, a partir do modelo lil_guy_portfolio. Use quando alguém quiser criar seu próprio site living-stage, personalizar este modelo ou pedir para "configurar meu portfólio". Copia o modelo primeiro (sem geração de código), depois entrevista o usuário uma pergunta por vez (intenção, história, estilo de texto, estrutura, falas, personagem, paleta e tipografia, links), em seguida constrói, verifica e faz o deploy.

O que é living-stage?

Este skill guia um desenvolvedor ou agente de IA no processo de criação de um site de portfólio narrativo único, chamado "living-stage", a partir do modelo `fuzzyplace/lil_guy_portfolio`. Em vez de gerar código engine, ele copia o modelo completo para uma nova pasta, depois conduz uma entrevista estruturada com o usuário, uma pergunta por vez, seguindo uma hierarquia de decisões: intenção, história, estilo de texto, estrutura, falas, personagem (visual), paleta/tipografia/movimento e, por fim, links. Cada decisão é registrada em `docs/STORY.md` e o agente preenche apenas cinco arquivos de conteúdo predefinidos, respeitando o motor artístico e de layout existente. Após a entrevista, o skill executa verificações de qualidade (tipos, testes, contraste, consistência de tokens), gera uma imagem de compartilhamento, tira screenshots para validação visual e, com a aprovação do usuário, faz o deploy seguindo as instruções de `docs/DEPLOY.md`. É útil para profissionais que desejam um portfólio com forte identidade visual e narrativa, personalizável sem precisar programar o motor do site.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/fuzzyplace/lil_guy_portfolio/tree/HEAD/.claude/skills/living-stage

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Living stage: configuração guiada

Você está ajudando alguém a criar sua própria versão deste site: um personagem de tinta que tem vida própria, braços que imprimem a página conforme você rola, sua história em suas palavras. O motor já funciona. Seu trabalho é copiá-lo, entrevistar a pessoa e preencher cinco lugares. Não escreva código do motor.

Os cinco lugares que são deles

O quêArquivo
Palavras: nome, tagline, capítulos, chamada para ação, easter eggssrc/content/site.ts
Links na árvore de linkssrc/content/links.ts
A aparência do personagemsrc/content/character.tsx (predefinições em src/art/looks.tsx)
Paleta, tipografia, movimentodesign/tokens.json, espelhado em src/styles/tokens.css
Imagem de compartilhamento e íconenpm run og (gerado a partir do acima)

Você também escreve as decisões da entrevista em docs/STORY.md, e pode ler src/art/looks.tsx para copiar uma aparência predefinida para src/content/character.tsx.

Todo o resto (src/art/, src/audio/, src/components/, src/sections/, src/App.tsx) é o motor. Não leia para fazer este trabalho; é grande e você não vai precisar. Leia docs/CHARACTER.md para as regras de aparência e manchetes e docs/DESIGN_SYSTEM.md antes de mexer em tokens. Só abra arquivos do motor se uma verificação falhar e o erro apontar para lá.

Etapa 0: obter o código (rápido, sem geração)

Se a pasta atual já é uma cópia do modelo (tem src/content/site.ts e .claude/skills/living-stage/), pule para a etapa 1.

Caso contrário, pergunte onde o novo site deve ficar (um nome de pasta), então copie o modelo sem seu histórico e instale:

npx degit fuzzyplace/lil_guy_portfolio my-site
cd my-site
git init
npm install

Em seguida, inicie o servidor de desenvolvimento (npm run dev, ou a ferramenta de pré-visualização se tiver uma) e mostre o site de exemplo para que saibam o que estão criando. Se não puder executar ou olhar um servidor de desenvolvimento, use capturas de tela: npm run build && npm run verify escreve screenshots/verify-desktop-hero.png (o herói, no meio da acrobacia) e amigos, e npm run looks escreve close-ups de cada aparência. (Na primeira vez: npx playwright install chromium.) Diga em duas linhas o que acontecerá a seguir: uma entrevista curta, uma pergunta por vez, então você constrói, verifica e (com a aprovação deles) faz o deploy.

Etapa 1: a entrevista

Como decidir (isso é o mais importante)

Decida de cima para baixo, uma camada de cada vez, e nunca pergunte sobre uma camada inferior até que a superior esteja bloqueada. Visuais terminados antes que a história e a voz estejam definidas levam a um texto que não faz sentido.

  1. Intenção: para quem é o site, o que devem sentir e o que devem fazer no final.
  2. História: o arco, rolando de cima para baixo.
  3. Estilo do texto: voz, formato das frases, dispositivos de enquadramento.
  4. Estrutura: os blocos (capítulos, um pop-out, contato) e para que serve cada um.
  5. Falas: as palavras reais, começando pela tagline.
  6. Personagem: qual a aparência dele.
  7. Paleta, tipografia e movimento.
  8. Links: a árvore de links e a chamada para ação.

Escreva cada camada bloqueada em docs/STORY.md sob "LOCKED" (substitua as entradas do exemplo de persona conforme avança). Tudo abaixo deve remeter a ela. Se uma ideia posterior contradizer uma camada bloqueada, diga e pergunte antes de mudar qualquer coisa.

Como perguntar

  • Uma pergunta por vez, em texto de chat simples. Sem formulários ou diálogos com várias perguntas.
  • Antes de cada pergunta, diga em uma linha o que ela decide e o que muda na página.
  • Mostre, não descreva. Para perguntas de estilo e aparência, dê 3 ou 4 opções, cada uma escrita com seu conteúdo real: os mesmos três momentos de sempre (a abertura, um capítulo, o final). Para o personagem, mostre as predefinições (?look=beanie|bun|hood|bot no servidor de desenvolvimento, ou npm run looks para close-ups). Para paletas, mostre amostras com a cor do texto sobre o fundo.
  • Recomende uma opção e diga por quê em uma frase. Eles escolhem, misturam ou contestam.
  • Após cada resposta, reformule o que agora está bloqueado em uma linha, escreva em docs/STORY.md, então faça a próxima pergunta.
  • "Você decide" significa que você decide, registra sob "Decisions" em docs/STORY.md e segue em frente.
  • Mantenha uma noção de custo: não releia arquivos que já leu, não regenere o site inteiro para cada resposta, edite apenas as linhas que mudaram.

O que perguntar, camada por camada

  1. Intenção. Para quem é (gerentes de contratação, clientes, colaboradores, amigos)? O que devem sentir? Qual é a única coisa que devem fazer no final (enviar email, agendar uma chamada, seguir, nada)?
  2. História. Peça o material bruto primeiro (o que fizeram, fazem agora, querem a seguir, qualquer coisa que fazem paralelamente), então proponha 2 ou 3 arcos em uma linha cada. O arco padrão é passado, presente, um pop-out com o fio condutor, futuro, contato; qualquer ordem de capítulos e pop-outs funciona.
  3. Estilo do texto. Ofereça 3 ou 4 vozes renderizadas no próprio material deles, por exemplo: primeira pessoa calma; caderno de laboratório; notas de campo; registro de terminal; ou uma mistura. Recomende uma.
  4. Estrutura. A lista de blocos, cada um com sua função em uma linha, mais quais aparecem na navegação do cabeçalho. Um bloco deve ser o bloco de contato.
  5. Falas. Esboce cada linha na voz bloqueada, então mostre-as juntas em contexto (o servidor de desenvolvimento, após escrever site.ts). Acertem a tagline primeiro: leia "Headlines" em docs/CHARACTER.md (2 a 4 linhas curtas, uma palavra real na primeira linha, letras altas ao lado de curtas, uma vírgula no final de uma linha; no máximo 24 caracteres por linha). Também: a sobrancelha, a abertura, o easter egg do rodapé, o easter egg do console, as duas linhas de confiança, a linha 404. Rascunho do texto é suficiente; nada vai ao ar até que eles aprovem.
  6. Personagem. Mostre as quatro predefinições. Se nenhuma servir, peça uma descrição de uma frase (cabelo ou chapéu, roupas, a única coisa que capta a luz) e desenhe uma aparência personalizada copiando a predefinição mais próxima para src/content/character.tsx e alterando uma forma de cada vez. Siga as regras de caixa, juntas e preenchimento em docs/CHARACTER.md. Nunca trace uma foto ou a semelhança de uma pessoa real, a menos que seja a deles e eles peçam. As predefinições compartilham parts.NECK e parts.SKULL (exportados de src/art/looks.tsx). Mostre o resultado com npm run looks (screenshots/look-current.png).
  7. Paleta, tipografia e movimento. Ofereça 3 paletas como amostras (os cinzas de tinta padrão e duas que combinem com a história deles), a cor de destaque e se querem manter as fontes padrão. Edite design/tokens.json primeiro, espelhe cada cor que mudou em src/styles/tokens.css (apenas a rampa de cinza tem variáveis --md-ref-gray-* lá; toda outra cor fica diretamente em seu --md-sys-color-<role>), então npm run tokens:contrast: verifica o contraste do texto (4.5:1) e que os dois arquivos concordam. A névoa (fog-light, fog-mid, fog-deep, fog-edge) carrega o clima da paleta: tinge todos os quatro. Mantenha o destaque como um sussurro (docs/DESIGN_SYSTEM.md). Movimento: durações padrão ou mais calmas (mais longas).
  8. Links. Pergunte por cada link e para onde vai (Connect, Work, Play ou grupos renomeados). Apenas URLs reais: qualquer coisa que ainda não tenham é href: null, status: 'soon' (mostrado em desenvolvimento, oculto em produção). Então a chamada para ação: um link de agendamento, um email ou um link de perfil.

Etapa 2: construir e verificar

  1. Escreva os arquivos de conteúdo a partir do que está bloqueado. Defina site.url para onde o site vai ficar (https://host, sem barra no final). Sem domínio ainda: use o endereço do host (por exemplo https://their-site.vercel.app) e atualize depois.
  2. Execute npm run check (tipos, testes incluindo as regras de texto, contraste e desvio de tokens, build). Corrija o que falhar. O build avisa enquanto site.url ainda aponta para o demo do modelo (lil-guy-portfolio.vercel.app) ou a chamada para ação para example.com. As regras de texto: sem travessões em ou en, sem pontos de exclamação, sem palavras de enchimento genéricas.
  3. Execute npm run og para o cartão de compartilhamento e ícone.
  4. Execute npm run build && npm run verify (primeira vez: npx playwright install chromium). Verifica em 1440 e 375, com e sem movimento reduzido, se o personagem aparece ao carregar, faz a entrada e a acrobacia do título, permanece na tela ao rolar e se nada dá erro. Se nenhuma acrobacia acontecer, a tagline não dá base para ele: revise com eles.
  5. Mostre as capturas de tela (screenshots/verify-desktop-hero.png e verify-mobile-hero.png para o herói no meio da acrobacia, verify-desktop.png e verify-mobile.png para o final da página) e o servidor de desenvolvimento, e pergunte o que mudar. Repita até ficarem satisfeitos. node scripts/shots-sections.mjs dá uma captura por capítulo.
  6. Passagem de privacidade. Leia cada string em src/content/ mais uma vez. Sinalize qualquer coisa que possam não querer público: endereço residencial, telefone pessoal ou email que não escolheram compartilhar, detalhes familiares ou de saúde, empregadores ou clientes que não autorizaram. Remova os resquícios da persona de exemplo: "Pim Lanternby", "PIM", "The Quiet Hour", linhas de lâmpada e rádio, e qualquer example.com, example.org ou example.net que não tenham dado, e o endereço de demo lil-guy-portfolio.vercel.app.

Etapa 3: fazer o deploy

O deploy publica o site deles, então pergunte antes de fazê-lo. Siga docs/DEPLOY.md (Vercel por padrão; Netlify e GitHub Pages também funcionam). Depois que estiver no ar, abra a URL, verifique o cartão de compartilhamento com o og.png implantado e forneça o link.

Termine com um resumo curto: o que está no ar, o que ainda está soon e qualquer coisa que disseram que enviariam depois.

Habilidades Relacionadas