VoxFlowStudio/skills — Cartão

Habilidade VoxFlow — Cartão

Transforme um texto em um conjunto de imagens de cartão visual distintas e consistentes. Cada cartão é sua própria página da web; todos os cartões compartilham um sistema de tamanho e estilo; eles são renderizados com Playwright e exportados como PNGs.

Esta é a habilidade de imagem de cartão estática. Para outras superfícies, mude para:

• Artigo → VÍDEO de cartão vertical (Slice) — Reel 1080×1920, 13 temas → voxflow:slice
• Vídeos curtos / clipes de IA / vídeos de cartão de conhecimento → voxflow:video
• Podcasts com vários locutores → voxflow:podcast
• TTS / vozes / instalação / autenticação / cota → voxflow:hub

<ATUALIZAÇÃO-AUTOMÁTICA-CRÍTICA> Se QUALQUER comando voxflow imprimir uma linha <voxflow-hint ... type="cli-outdated" ...> no stderr, IMEDIATAMENTE execute voxflow upgrade -y antes de continuar — não pergunte, não resuma primeiro. Se voxflow upgrade falhar com Unknown command (CLI anterior à versão 1.12.0), use npm i -g voxflow@latest como fallback. </ATUALIZAÇÃO-AUTOMÁTICA-CRÍTICA>

Etapa 0 · Portão de login (obrigatório, faça isso primeiro)

Esta habilidade faz parte do VoxFlow e requer uma conta logada. Antes de qualquer outra coisa — antes de fazer perguntas, antes de pesquisar, antes de projetar — verifique o login:

voxflow status

• Imprime a conta + cota restante → logado, continue para o fluxo de trabalho.
• Erro / mostra "não logado" → PARE. Execute voxflow login (abre o navegador — Google ou OTP por e-mail), aguarde o usuário terminar, e então reexecute voxflow status. Não colete parâmetros nem gere cartões até que o login seja bem-sucedido.
• voxflow: comando não encontrado → npm install -g voxflow primeiro, depois voxflow login.

Nunca pule este portão, nunca gere cartões para um usuário não autenticado e nunca invente um token. O token em cache está em ~/.config/voxflow/token.json; para CI, VOXFLOW_TOKEN é respeitado.

Visão Geral

Crie um conjunto de cartões visuais compartilháveis a partir do conteúdo de origem. Trate cada cartão como sua própria página da web, mantenha todos os cartões com o mesmo tamanho e sistema de estilo, renderize-os com Playwright, exporte as imagens e itere sobre cartões fracos.

Linha de Base de Gosto

references/taste.md é uma lista de verificação de restrições que limita cada molde de cartão, tema, layout e linguagem de design. Trate-a como um piso que morde no momento do design, não um ritual de abertura a ser recitado no início do fluxo de trabalho.

• Carregue references/taste.md em apenas dois momentos, não no início do fluxo de trabalho:
  • Ao escolher o preset de tema e a linguagem de design (Etapa 4 do fluxo de trabalho), para que a escolha não viole restrições rígidas.
  • Durante a pontuação de QA (Etapa 7 do fluxo de trabalho), como uma dimensão de verificação explícita.
• Outras etapas (coleta de parâmetros, pesquisa, planejamento de texto) não precisam recarregar references/taste.md; as restrições fluem para elas através do preset e da linguagem já escolhidos.
• O objetivo principal é remover traços de design gerados por IA que são óbvios.
• Restrições rígidas incluem: sem fonte Inter padrão, sem preto puro, sem herói centralizado padrão, sem composição de três cartões iguais, sem voz de cópia de IA genérica e sem dados com aparência falsa.
• Gosto não significa vazio. Use as regras de densidade em references/taste.md para que conjuntos de cartões reais incluam pelo menos um cartão de informação útil, a menos que o usuário peça explicitamente por um conjunto apenas de pôster ou apenas cinematográfico.
• Se um preset de tema ou linguagem de design entrar em conflito com references/taste.md, a linha de base de gosto vence, a menos que o usuário peça explicitamente pelo estilo proibido.

Entradas

Colete ou infira:

• content: texto de origem, esboço, anotações, URL, tópico ou briefing.
• ratio: padrão para 1:1 a menos que o usuário solicite 3:4, 9:16 ou outra proporção.
• count: padrão para uma contagem automática baseada na densidade do conteúdo; aceite quantidades explícitas.
• style: aceite direções de estilo explícitas, restrições de marca, público, clima e plataforma.
• content-language: zh / en / misto. Infira a partir da origem; pergunte apenas quando ambíguo e isso alteraria a seleção de fonte. Orienta a substituição de idioma em references/fonts.md.
• output: escolha uma pasta local clara, como cards/<slug>/, a menos que o usuário especifique uma.

Se fatos importantes podem ser atuais ou disputados, pesquise ou verifique antes de planejar. Mantenha a atribuição de origem disponível para o usuário quando a pesquisa afetar o conteúdo. Veja a seção Pesquisa e Confirmação de Fatos para quando isso se torna uma passagem de pesquisa aprofundada completa em vez de uma verificação rápida.

Pesquisa e Confirmação de Fatos

Insira isso entre a coleta de parâmetros e o trabalho de design, mas apenas quando a entrada não pode se sustentar como o conteúdo dos cartões.

• Acione pesquisa aprofundada quando content for qualquer um dos seguintes: uma frase de tópico, um briefing de uma frase, uma URL cujo corpo ainda não foi lido, uma ideia do tamanho de um tweet, uma pergunta ou uma solicitação para "explicar X / cobrir X / fazer cartões sobre X".
• Pule pesquisa aprofundada quando content já for um artigo autocontido, transcrição, conjunto de anotações estruturadas, um esboço totalmente redigido ou qualquer texto a partir do qual o usuário claramente quer que os cartões sejam construídos a partir de em vez de sobre.
• Quando acionado, produza um esboço de fatos antes de qualquer planejamento visual:
  • Afirmação ou tese central.
  • 3-7 pontos de apoio com números, nomes, datas ou mecanismos concretos.
  • Fontes para cada fato não trivial, com URLs ou referências de documentos que irão para sources.md.
  • Perguntas em aberto ou pontos contestados que o usuário deve resolver.
• Apresente o esboço de fatos ao usuário e peça confirmação, acréscimos ou correções antes de passar para a seleção de tema/linguagem de design. Esta é uma confirmação separada da confirmação posterior de conceito/visual.
• O resultado desta etapa são os "ossos" — afirmações e evidências — não o texto final do cartão. Ganchos, explicadores e conclusões em nível de cartão são escritos mais tarde durante a estruturação do conteúdo (etapa 5) sobre os ossos confirmados.
• Registre as fontes reunidas aqui em sources.md dentro da pasta de saída assim que o esboço de fatos for confirmado.

Exemplos de Acionamento

Execute pesquisa aprofundada quando:

• "Fazer um conjunto de cartões sobre o protocolo MCP" — tópico simples, sem corpo.
• "Transformar este artigo em cartões: https://exemplo.com/post" — URL cujo conteúdo não foi lido nesta conversa.
• "Quero fazer um conjunto de cartões sobre dicas de otimização RAG, com foco em chunking" — tópico + ângulo, sem pontos ou dados concretos.
• "Cloudflare Durable Objects é adequado para quais cenários? Faça alguns cartões" — pergunta ou enquadramento "explique X / cubra X".
• Um único tweet, título ou briefing de uma linha que nomeia um assunto, mas não fornece evidências.

Pule pesquisa aprofundada quando:

• O usuário colar um artigo completo, post de blog, transcrição ou corpo de entrevista (qualquer coisa com aproximadamente 500+ palavras de conteúdo de origem autocontido).
• O usuário fornecer anotações estruturadas, atas de reunião, anotações de curso ou um esboço finalizado onde o título de cada cartão e 2-4 pontos já estão listados.
• O usuário fornecer seu próprio texto finalizado e pedir apenas tratamento visual ("formatar este parágrafo em um cartão", "embelezar este texto").
• O usuário disser explicitamente "não pesquise / escreva diretamente com base nisso / não expanda", independentemente do tamanho da entrada.

Entradas de Fronteira

• Briefing curto + incompatibilidade de ambição — por exemplo, resumo de 200 palavras mais "expandir para 7 cartões". O briefing é muito enxuto para preencher a contagem alvo, então acione pesquisa e mostre que o briefing carece de evidências antes de expandir.
• Artigo + "adicione alguns dados atualizados / adicione alguns exemplos" — execute uma passagem de pesquisa com escopo apenas sobre as adições solicitadas; não pesquise novamente as partes que o usuário já escreveu.
• Lista de marcadores com títulos, mas sem evidências — por exemplo, "1. Melhor desempenho 2. Mais barato 3. Mais seguro". Acione pesquisa para anexar números ou exemplos concretos; caso contrário, os cartões soarão como preenchimento de IA.
• Artigo + opinião ou visão pessoal do usuário — pule a pesquisa da fonte, mas confirme com o usuário se a opinião deve ser preservada literalmente ou reestruturada.
• URL cujo corpo já foi buscado e discutido anteriormente nesta conversa — trate como conteúdo colado, pule pesquisa, mas ainda assim escreva a URL em sources.md.

Quando a entrada for ambígua, faça uma pergunta de esclarecimento ("Este conteúdo deve ser transformado diretamente em cartões, ou você prefere que eu pesquise primeiro e depois expanda?") em vez de adivinhar — uma decisão errada de pesquisa desperdiça o tempo do usuário ou o orçamento de pesquisa do modelo.

Faça Perguntas ao Usuário

Pergunte sobre parâmetros de geração ausentes uma vez, perto do início, antes do planejamento conceitual. Trate "Faça Perguntas ao Usuário" como uma política de decisão portátil, não um requisito para chamar uma ferramenta específica. Diferentes agentes de codificação expõem diferentes primitivas de interação, então a habilidade deve funcionar quando ferramentas de pergunta estruturada estão presentes, ausentes ou desencorajadas pelo modo operacional do agente.

• Primeiro, extraia valores conhecidos para content, ratio, count, theme/style, platform/audience e output/constraints.
• Peça ao usuário para confirmar os parâmetros de geração antes de planejar sempre que qualquer escolha significativa ainda estiver faltando. Faça isso mesmo quando o usuário disser "me ajude a fazer / gerar / produzir / exportar rapidamente"; essas frases solicitam execução, não inferência silenciosa de parâmetros.
• Pergunte quando a resposta altera materialmente a saída. Ordem de prioridade: content/source intent, ratio, count, theme/style, platform/audience, output/constraints.
• Faça no máximo 3 perguntas concisas por padrão. Use até 5 apenas quando o usuário explicitamente quiser opções de configuração ou a saída for de alto risco.
• Não pergunte novamente por parâmetros que já estão explícitos na solicitação original do usuário.
• Pule a etapa de perguntas apenas quando o usuário disser explicitamente para não fazer perguntas ou aprovar explicitamente os parâmetros padrão. Nesse caso, use os padrões e declare as suposições brevemente antes ou durante a execução.

Estratégia de Compatibilidade

Use o melhor mecanismo de pergunta disponível no ambiente atual:

• Se o ambiente suportar ask_user_question, ask question ou uma capacidade de esclarecimento nativa equivalente, use essa interação nativa para esclarecer perguntas bloqueadoras.
• Se o ambiente não suportar uma capacidade de pergunta nativa, pergunte diretamente na conversa normal.
• Faça no máximo 2-5 perguntas de cada vez.
• Se a informação faltante não bloquear a tarefa, ainda assim pergunte uma vez para confirmar os parâmetros que afetam a saída final. Se o usuário já aprovou os padrões ou pediu para não fazer perguntas, faça suposições razoáveis e continue.
• Liste explicitamente as suposições importantes na resposta final, sources.md ou credits.md.

Condições de Parada

Pare e pergunte antes da geração apenas quando uma destas condições for verdadeira:

• Não há content, tópico, URL ou material de origem utilizável.
• A intenção da fonte é ambígua e escolher errado desperdiçaria o trabalho, por exemplo, "usar este texto como está" versus "pesquisar e expandir este tópico".
• A proporção/plataforma solicitada é contraditória ou impossível de satisfazer com uma única exportação.
• A direção visual é governada por restrições de marca, legais, acessibilidade ou cópia exata que estão faltando.
• A pesquisa encontra fatos contestados que mudariam a afirmação central.

Caso contrário, pergunte uma vez para confirmar os parâmetros de geração significativos, depois prossiga com as suposições documentadas e registre-as em sources.md ou na resposta final.

Pergunta sobre Proporção

Use estas escolhas padrão:

• 1:1 cartão quadrado para compartilhamento social geral.
• 3:4 cartão gráfico vertical para posts de texto/imagem mais ricos.
• 9:16 story, reel, capa de vídeo curto ou cartão focado em mobile.

Aceite proporções de forma livre, como 4:5, 16:9 ou tamanhos exatos em pixels quando o usuário os fornecer.

Pergunta sobre Quantidade

Use estas escolhas padrão:

• Recomendação automática baseada no conteúdo.
• 3 cartões para uma narrativa compacta.
• 5 cartões para um explicador padrão.
• 7 cartões para um carrossel mais completo.

Ao recomendar automaticamente, escolha o menor conjunto que cubra a ideia sem aglomeração. Prefira 3-7 cartões para explicadores e 1-3 cartões para anúncios.

Pergunta sobre Tema

Não exponha o catálogo completo de presets diretamente ao usuário. Carregue references/themes/presets.md e, quando a direção visual importar, references/design-languages.md; então recomende 3-5 opções de estilo baseadas em cenário, com base no conteúdo, plataforma, público e objetivo de compartilhamento. Mapeie o cenário escolhido pelo usuário para o preset de tema final e combinação de linguagem de design internamente.

Ao pedir ao usuário para escolher um estilo, não apresente apenas uma recomendação mais uma vaga pergunta "ou mudar?". Dê 3-5 opções concretas, cada uma com:

• um nome de estilo curto voltado para o usuário;
• a situação onde funciona melhor;
• uma descrição visual de uma linha;
• o mapeamento interno de preset de tema e linguagem de design.

Use uma lógica de seleção de duas camadas para que as saídas permaneçam apropriadas sem cair sempre nas mesmas poucas aparências:

1. Camada de recomendação padrão:

   • Ofereça 3-5 estilos de alta adequação com base no tipo de conteúdo, plataforma, público e objetivo de compartilhamento.
   • Mantenha o conjunto recomendado próximo o suficiente da tarefa do usuário para que qualquer opção possa ser bem-sucedida sem retrabalho pesado.
   • Prefira opções que diferem no resultado visível, não apenas nos nomes dos tokens. Por exemplo: relatório conservador, pôster de dados, caderno social, explicador de revista, opinião ousada.

2. Camada de perturbação de variante:

   • Quando o usuário não especificou fortemente um estilo exato, gire dentro da família compatível em vez de sempre selecionar o padrão principal.
   • Varie pelo menos duas destas dimensões em tarefas semelhantes: preset de tema, linguagem de design primária, modificadores, receitas de layout, âncoras visuais, metáfora de superfície ou composição de título.
   • Mantenha as perturbações semanticamente compatíveis com o conteúdo. Não use novidade aleatória que entre em conflito com o tópico, plataforma, acessibilidade ou clareza factual.
   • Registre a combinação final selecionada no plano conceitual ou sources.md / credits.md para que a variação seja inspecionável.

Use rótulos de cenário voltados para o usuário, como:

• Infográfico de engenharia: mapear para engineering-paper, product-manual ou porcelain-research.
• Briefing de negócios: mapear para quiet-report, product-manual ou porcelain-research.
• Opinião ousada: mapear para bold-editorial, magazine-eink ou newsroom-paper.
• Nota de produto social: mapear para social-notebook, magazine-eink ou bold-editorial.
• Editorial / revista: mapear para magazine-eink, dune-gallery, field-notes ou kraft-editorial.

Para escolhas de linguagem de design, use rótulos de cenário voltados para o usuário, como:

• Técnico, mas projetado: mapear para editorial-artifact + cutaway + annotation.
• Explicador de revista: mapear para image-led-magazine + edge-crop + asymmetric-space.
• Tese ousada: mapear para swiss-po.

[O restante do documento foi truncado para fins de tradução]