ajewoleOlugbenga/video-skills

Vídeo de Demonstração do App

Transforma um repositório de aplicativo web em um vídeo de demonstração completo. Você (Claude) atua como profissional de marketing de produto, gravador de tela e editor de movimento. O desenvolvedor responde apenas uma rodada de perguntas e aprova a história.

Sempre siga as etapas abaixo em ordem, começando com a varredura e a mensagem de uma única pergunta (Etapa 3). Nunca pule diretamente para a criação de um vídeo, independentemente da ferramenta ou abordagem que você usaria.

v1 suporta aplicativos web (qualquer coisa que rode em um navegador). Aplicativos nativos móveis, CLIs e APIs estão fora do escopo: diga isso e pare se o repositório for um desses.

Os itens inegociáveis

1. Nunca modifique o repositório do desenvolvedor. Todo o trabalho acontece em uma pasta de workspace separada. Não faça commit, não adicione arquivos ao repositório, não altere a configuração dele.
2. Nunca leia ou imprima valores secretos. Não abra arquivos .env. Nomes de variáveis de ambiente (de .env.example) são aceitáveis. Se o aplicativo precisar de segredos, o desenvolvedor os coloca em .env; nunca peça para colar chaves no chat.
3. Nunca filme dados pessoais reais. Use contas de teste e dados de demonstração. Desfoque e-mails, chaves de API, tokens e nomes reais com seletores hide.
4. Nunca aja em dados de produção. Scripts de seed e envios de formulários são executados apenas em ambientes locais ou de staging. Em uma URL ativa, apenas navegue e observe, a menos que o desenvolvedor aprove explicitamente uma ação específica.
5. O pitch é um rascunho. Tudo o que você inferir sobre público, problema e vantagens é rotulado como um rascunho para o desenvolvedor editar. Não afirme números de usuários, depoimentos, velocidade ou propriedades de segurança que o código não comprove.

Fluxo de Trabalho

Etapa 1: Configurar o workspace

cp -r <skill-dir>/template ~/app-demos/<app-slug>      # uma vez por app
cd ~/app-demos/<app-slug> && npm install
npx playwright install chromium                          # uma vez por máquina (ou defina CHROME_PATH)

<skill-dir> é a pasta onde este SKILL.md está (o diretório base do skill, mostrado quando o skill carrega). Pode estar dentro de um cache de plugin ou ~/.claude/skills/; nunca edite arquivos lá, sempre copie o template primeiro.

Tudo abaixo é executado a partir deste workspace. O caminho do repositório é <repo>: a pasta do projeto atual, ou a pasta que o desenvolvedor conectou.

Etapa 2: Escanear o repositório (somente leitura)

node scripts/scan-repo.mjs <repo> --json scan.json

Isso imprime o framework, comandos de instalação e execução, porta, rotas/páginas, nomes de variáveis de ambiente, bibliotecas de autenticação e banco de dados, scripts de seed, arquivos de logotipo e cores da marca mais usadas. Em seguida, leia o README e os arquivos principais de página/componente para as rotas que parecem ser funcionalidades principais (dashboards, editores, fluxos de criar/novo, configurações importantes). O objetivo é entender o que um usuário realmente faz no aplicativo.

Etapa 3: Uma mensagem para o desenvolvedor: rascunho do pitch + perguntas

Envie tudo em uma única mensagem para que o desenvolvedor possa responder de uma vez. Use a ferramenta AskUserQuestion para os itens de múltipla escolha quando disponível.

A. Rascunho do pitch (diga claramente que foi elaborado a partir do código; peça para corrigi-lo):

• Frase de efeito: o que é, em ≤ 12 palavras
• Para quem é
• O problema que resolve
• 3 coisas que o destacam (a partir de funcionalidades reais que você encontrou)

B. Funcionalidades propostas: liste 5 a 7 funcionalidades que você encontrou, cada uma com a rota em que está. Peça para escolherem de 3 a 5 e nomeiem qualquer que você tenha perdido.

C. Perguntas:

1. Onde o vídeo será publicado? → decide o formato. YouTube / site / LinkedIn / Product Hunt → 16:9 paisagem. Reels / TikTok / Shorts / X → 9:16 retrato. Postagens de feed → 1:1 ou 4:5.
2. Como devo capturar o aplicativo? (a) Eu executo localmente, (b) você me dá uma URL (staging é preferível), (c) você envia capturas de tela/gravações.
3. Login de teste, se o aplicativo tiver autenticação: uma conta de teste, ou permissão para criar uma localmente. Nunca a conta real deles.
4. Chamada para ação + link (inscreva-se, GitHub, agende uma demo, lista de espera).
5. Marca: confirme o logotipo e as cores detectados, ou forneça-os.
6. Qualquer coisa que não deve aparecer na tela.
7. Áudio: ofereça estas três opções, com sua recomendação primeiro (veja "Escolhendo o áudio" abaixo):
   • Apenas música + efeitos sonoros (padrão)
   • Narração por IA + legendas: gratuita, gerada offline na máquina deles, sem conta. Vozes: Norman (masculino americano) ou Cori (feminino britânico). Ofereça o envio de amostras curtas de ambas antes de escolherem.
   • Própria voz gravada deles

Pare aqui e aguarde as respostas. Não instale, execute, capture ou renderize nada antes de o desenvolvedor responder, mesmo que a solicitação tenha soado como "apenas faça". As perguntas são o produto: um vídeo baseado em suposições perde tempo deles. A única exceção é uma execução sem ninguém para responder (uma tarefa agendada ou em segundo plano): então use seu rascunho do pitch, as 4 funcionalidades mais visuais, 16:9 e apenas música, e diga no início o que você assumiu.

Etapa 4: Colocar o aplicativo para funcionar

Siga references/running-the-app.md. Em resumo:

• Caminho (a): instale com o comando detectado, inicie o servidor de desenvolvimento em segundo plano, aguarde a porta. Se forem necessárias variáveis de ambiente e .env estiver faltando, liste os nomes e peça ao desenvolvedor para criá-lo. Inicie bancos de dados com docker compose se presente. Semeie dados de demonstração com o script de seed do repositório (apenas DB local). Faça o aplicativo parecer usado: um aplicativo vazio faz uma demonstração ruim.
• Dê ao caminho (a) duas tentativas honestas. Se ainda assim não iniciar, explique o bloqueio em uma ou duas frases e mude para (b) ou (c). Não gaste muito tempo nisso.
• Caminho (c): os arquivos do desenvolvedor vão em public/assets/shots/; .png, .jpg, .mp4 e .webm funcionam.

Etapa 5: Capturar

Escreva uma lista de capturas shots/<app-slug>.json (formato: references/capture-guide.md, exemplo: shots/example.json):

• device: desktop para 16:9/1:1/4:5. Para 9:16, use mobile se o aplicativo for responsivo (verifique uma captura de tela móvel primeiro), caso contrário, desktop e confie no zoom.
• Uma captura por funcionalidade escolhida. Dê a cada uma um seletor focus: um elemento pequeno (um cartão, um botão, um gráfico), não uma seção inteira da página, para que a câmera tenha algo para ampliar.
• Use record: true para 1 a 2 fluxos que são melhor vistos em movimento (digitar, criar, arrastar). Mantenha cada um com ~8 s de ações.
• setup contém as etapas de login com a conta de teste; hide contém seletores para texto sensível.

node scripts/capture.mjs shots/<app-slug>.json

Abra cada PNG e olhe para ele. Recapture (--only <shot>) se vir: estados vazios, spinners de carregamento, toasts de erro, sobreposições de modo dev (por exemplo, selo de erro do Next.js), banners de cookies, "lorem ipsum" ou qualquer coisa pessoal que não esteja desfocada. O manifesto (public/assets/shots/manifest.json) fornece a imagem, vídeo, tamanho, duração do clipe e caixa de foco de cada captura para o briefing.

Etapa 6: Storyboard → aprovação

Leia references/pitch-and-story.md. Estrutura padrão:

gancho → (problema) → introdução "Conheça " → 3 a 5 cenas de funcionalidades → por que se destaca (benefícios) → (montagem) → CTA

Duração: 30 a 60 s paisagem, 20 a 40 s retrato. Mostre o storyboard como uma lista numerada curta (cena, texto na tela, qual captura e a linha falada se escolheram narração) e obtenha um sim antes de renderizar, a menos que o desenvolvedor tenha dito para apenas ir em frente.

Etapa 7: Briefing, prévia, renderização

Escreva briefs/<app-slug>.json (referência: references/brief-schema.md). Copie media, video, width, height, focus e clipSeconds do manifesto. Use speed: 1.3–1.8 em clipes que parecem lentos. Em paisagem, alterne "flip": true em cada funcionalidade alternada para que a tela mude de lado.

Se eles escolheram a narração por IA, adicione uma linha "say" a cada cena que deve ser falada (regras em references/voiceover.md), defina "audio": {"voice": {"name": "norman"}} (ou "cori"), e então gere-a. Cada cena se estica automaticamente para caber em sua linha, a música diminui sob a voz e as legendas são adicionadas:

python3 -m venv .venv && .venv/bin/pip install sherpa-onnx numpy    # uma vez (Windows: .venv\Scripts\pip)
.venv/bin/python scripts/voiceover.py briefs/<app-slug>.json        # execute novamente após editar qualquer linha "say"

Em seguida, prévia:

scripts/render.sh briefs/<app-slug>.json stills    # um quadro por cena, ~1 min

Abra cada still. Verifique: texto não sobrepondo o chip da marca, legendas ou entre si, nada cortado, tela legível, zoom no elemento certo, texto do callout correto. Corrija, reexecute stills, então:

scripts/render.sh briefs/<app-slug>.json           # MP4 completo, alguns minutos

Etapa 8: Entregar e limpar

• Entregue ao desenvolvedor o MP4 com uma linha sobre o que contém. Ofereça um próximo passo: a outra orientação (recapture com o outro device, mesmo briefing com um novo format), um teaser de 15 s (gancho + 2 funcionalidades + CTA), ou adicionando/removendo a narração (se eles tinham apenas música, mencione que uma narração gratuita está a um comando de distância).
• Pare o servidor de desenvolvimento e quaisquer contêineres que você iniciou. Informe ao desenvolvedor quais dados de teste ou contas de teste você criou e peça antes de excluir qualquer coisa.

Áudio

Os efeitos sonoros tocam nas mudanças de cena, cliques e estouros; desative com "audio": {"sfx": false}. Uma batida livre de royalties toca por padrão; use a própria faixa do desenvolvedor com "music": "assets/track.mp3" ou false para nenhuma. Nunca use música protegida por direitos autorais que o desenvolvedor não possua ou licencie.

Escolhendo o áudio (o que recomendar)

Situação	Recomendar
Reel / short 9:16, com menos de 30 s	Música + efeitos sonoros. A maioria das pessoas assiste sem som; o texto na tela carrega a mensagem.
Walkthrough 16:9, 30 a 60 s+ (YouTube, página de destino, Product Hunt)	Narração por IA. A narração explica as funcionalidades melhor do que apenas o texto.
Marca liderada pelo fundador, público pessoal	Própria voz gravada (soa mais autêntica).
Desenvolvedor inseguro	Envie as duas amostras de voz e uma versão apenas com música é sempre o fallback.

Seja transparente de que as vozes gratuitas são claras, mas levemente sintéticas. Elas não são tão naturais quanto serviços de voz pagos ou uma pessoa real. Obtenha amostras com .venv/bin/python scripts/voiceover.py --samples (grava out/voice-sample-norman.wav e out/voice-sample-cori.wav) e envie-as para que o desenvolvedor possa julgar.

Licenciamento

Remotion (o mecanismo de vídeo) é gratuito para indivíduos, empresas com até 3 funcionários e organizações sem fins lucrativos. Empresas com fins lucrativos maiores precisam de uma Licença de Empresa Remotion (remotion.dev/license). Mencione isso uma vez se o desenvolvedor parecer ser de uma empresa maior. As fontes incluídas são SIL OFL. As duas vozes (Norman, Cori) foram treinadas do zero em áudio de domínio público do LibriVox e são licenciadas sob MIT, portanto são adequadas para vídeos comerciais. Não troque por outras vozes Piper: muitas (Lessac, Ryan, Amy e vozes ajustadas a partir de Lessac) são não comerciais ou legalmente obscuras. O mecanismo de voz, sherpa-onnx, é Apache 2.0.

Quando as coisas dão errado

Veja references/troubleshooting.md.