umarmsharif/construtor-de-decks-estrategicos

O que construtor-de-decks-estrategicos faz?

Uma skill para construir decks de nível de consultoria, com base no sistema de design v5 Bright White & Pine — um fundo branco quase brilhante (FCFCFA), um tom de acento verde-pinho escuro (12564A), texto em preto espresso (1A1A1A), uma fonte de exibição por deck (padrão Charter) combinada com o corpo Manrope, ênfase carregada por hairline e peso da fonte em vez de barras coloridas, entrega prioritária em pptx. O sistema foi criado para eliminar padrões agora amplamente lidos como sinais de design de IA — fundos creme quentes, uma única fonte em todos os lugares, barras de acento de um lado, pills de sobrancelha, numerais de seção superdimensionados. A postura anti-porcaria está no DNA: veja references/anti-slop.md (o catálogo de "porcaria" mapeado para relevância do deck) e as verificações estáticas em scripts/deck_qa.js.

A implementação de referência canônica é assets/reference-build.js — um exemplar pptxgenjs completo e testado em renderização. Abra-o para corresponder à intenção do slide, depois copie os blocos. A biblioteca de receitas completa, funções auxiliares e tabela de pegadinhas estão em references/build-helpers.md.

Quando acionar

Use esta skill proativamente para qualquer um dos seguintes:

• Decks de estratégia, decks de pitch, entregáveis de consultoria, respostas a estudos de caso
• Apresentações para o conselho, briefings de liderança, decks de roadmap, planos de transformação
• Análises de entrada no mercado, decks de diagnóstico, decks de recomendação, resumos executivos
• Qualquer coisa em que o usuário faça referência a "estilo consultoria", "estilo MBB", "estilo McKinsey", "estilo Bain", "BCG" ou nomeie uma empresa real
• Qualquer deck polido voltado para o cliente em que o usuário queira uma saída com qualidade de marca, com prosa nítida

O fluxo de trabalho

Siga estas etapas em ordem. Os portões anti-porcaria pré e pós-voo são inegociáveis.

Etapa 0 — OBRIGATÓRIO: verificação pré-voo anti-porcaria

Esta skill produz prosa que deve sobreviver a um leitor cético. Antes de redigir qualquer cópia de slide, notas do apresentador, linha de tese, linhas de contexto ou texto de briefing, leia references/anti-slop.md para que a linguagem seja calibrada contra os sinais de IA que fazem um deck parecer escrito por máquina.

Após a leitura, mantenha estas restrições ao redigir o texto:

• Sem travessões, a menos que um esteja fazendo um trabalho específico que você possa defender (máximo de um por página)
• Vocabulário zero de palavras-chave de enchimento (mergulhar, alavancar, robusto, sem costura, transformador, paradigma, de ponta, mudança de jogo e o resto do catálogo em anti-slop.md)
• Sem paralelismos negativos ("não é X, é Y"; "não apenas A, mas B")
• Frases com menos de 30 palavras; substantivos concretos e números específicos vencem abstrações
• Títulos de ação, não títulos de tópico (a regra mais importante — veja slide_patterns.md)

O ofício estrutural pode ser perfeito e o deck ainda é desconsiderado no momento em que a prosa parece consultoria-AI genérica. Este portão existe para impedir isso.

Etapa 1 — Briefing do deck

Use AskUserQuestion (ou pergunte inline onde a ferramenta não estiver disponível) com duas chamadas consecutivas antes de escrever um único slide ou linha de build.js:

Chamada 1 — Configuração do deck:

1. Público + objetivo — quem está lendo isso e que decisão ou ação você deseja deles?
2. Arquétipo do deck — diagnóstico / recomendação / roadmap / entrada no mercado / transformação / pitch / scqa / scr / bluf / indutivo / árvore de questões / dedutivo. O deck pode ser simples (um arquétipo em todo o deck) ou em camadas (um arquétipo espinha + substituições no nível da seção). Se for em camadas, decida qual arquétipo executa qual intervalo de slides e respeite-o; não o colapse de volta a uma forma.
3. Formato de saída — pptx / html / md / gamma / briefing (multisseleção; padrão: pptx)

Chamada 2 — Briefing de marca + visual:

1. Esquema de cores — pergunte por intenção (apenas acento; o fundo branco brilhante + neutros frios permanecem fixos). Ofereça: Pine 12564A (padrão; calmo, moderno, crescimento) / Slate blue 1F3A5F (corporativo, finanças, confiança) / Oxblood 6E1423 (formal, estabelecimento) / Hex do cliente (trabalho vinculado à marca). A escolha define ACCENT e deriva ACCENT_DK (~70% de luminância) + TINT (~8% sobre branco) + TINT_BORDER. O tom de Oxblood inclina-se ligeiramente para rosa — aqueça-o se escolhido. Os valores de esquema verificados estão em design_system.md §1.
2. Fonte do cabeçalho — pergunte por intenção (o corpo permanece Manrope; apenas a face do título muda). Ofereça: Charter (serifa editorial, padrão, renderiza limpo em todos os lugares) / Manrope Bold (moderno, todo sem serifa, sem serifa) / Palatino (serifa quente) / Baskerville (serifa formal; melhor no PowerPoint/Google Slides, mais fraco na pré-visualização do LibreOffice). A escolha define DISPLAY e DISPLAY_BOLD=true para a opção toda sem serifa. Qualquer face instalada com carácter é aceitável se estiver fora da lista de uso excessivo (Inter, Roboto, Fraunces, Geist, Plus Jakarta, Space Grotesk). Uma escolha toda sem serifa aceita conscientemente o conselho de família única — veja references/anti-slop.md.
3. Briefing de marca + conteúdo — nome do cliente/empresa, apresentador, data e uma ideia aproximada slide a slide (até notas de marcadores são boas; Claude estrutura).

O esquema está em assets/inputs.example.json. A contagem de slides NÃO é uma entrada obrigatória — deixe-a seguir da entrevista de conteúdo e do arquétipo. O padrão é 8–12 para decks executivos, 15–18 para análises mais profundas, 26+ para síntese de master-deck.

Escreva inputs.json a partir das respostas antes de tocar em qualquer script de construção. Manter as entradas separadas do script de construção significa que o mesmo script lida com todos os decks futuros.

Etapa 1.5 — OBRIGATÓRIO: ghost deck antes de qualquer redação de conteúdo

Antes de preencher corpos de slides, painéis, pontos, linhas de gantt ou qualquer prosa: emita uma versão ghost deck de inputs.json com apenas:

• title_slide preenchido
• slides[i].breadcrumb, slides[i].title, slides[i].context preenchidos (os títulos devem ser títulos de ação — veja Convenções Universais em slide_patterns.md)
• slides[i].layout escolhido (Claude decide decisivamente do pool filtrado por arquétipo)
• Todos os slides[i].content deixados vazios {} ou apenas com nomes de campos fictícios

Apresente o ghost deck como uma tabela com colunas: # | Seção / arquétipo | Breadcrumb | Título de ação | Layout | Linha de contexto (1 frase) | Visual principal / dados (teste de 5 segundos).

A coluna Seção / arquétipo torna a estrutura em camadas visível rapidamente. Para decks simples (um arquétipo em todo o deck), cada linha carrega o mesmo valor (por exemplo, — / diagnóstico). Para decks em camadas, a coluna nomeia a seção à qual o slide pertence e o arquétipo que essa seção executa — por exemplo, Construir caso / indutivo, Sequenciar jogo / roadmap, Fechar pedido / bluf. Os limites das seções tornam-se visualmente óbvios (linhas adjacentes compartilham um rótulo de seção; a mudança marca a quebra).

Em seguida, use AskUserQuestion (ou pergunte inline) com estas perguntas:

1. O arco narrativo se mantém entre as seções? (Aprovar tudo / Revisar slides específicos / Reestruturação importante)
2. Algum título que não afirma um "e daí"? (Liste os números dos slides para corrigir, ou "tudo bem")
3. Alguma escolha de layout que pareça errada para o trabalho do seu slide — incluindo um slide cujo layout luta contra o arquétipo de sua seção? (Liste os números dos slides, ou "tudo bem")
4. Alguma linha de contexto ou descrição visual faltando detalhes críticos? (Liste os números dos slides, ou "tudo bem")

Aguarde a aprovação explícita antes de redigir qualquer conteúdo do corpo. Se o usuário solicitar alterações, atualize a tabela do ghost deck e pergunte novamente — não prossiga para a Etapa 1.6 até que o usuário diga "tudo bem" ou equivalente.

Por que isso existe: é mais rápido descartar 10 títulos de slides do que 10 slides finalizados. A discussão da estruturação do Princípio da Pirâmide / SCQA acontece aqui, na versão barata. Pular esta etapa é a razão mais comum pela qual um deck finalizado precisa ser reconstruído, e também é como slides herói esparsos vazam onde pertencem padrões de trabalho densos.

Escolha de padrões dentro do ghost deck: Claude escolhe layouts decisivamente do pool filtrado por arquétipo (scripts/pattern_filter.js --archetype=<valor>). Use AskUserQuestion apenas para apresentar uma escolha quando dois padrões genuinamente empatarem em adequação de conteúdo ou quando o usuário tiver expressado preferência de gosto anteriormente. A escolha granular por slide produz 10–12 perguntas forçadas por deck sem ganho de qualidade proporcional; evite-a.

Guarda de monotonia (selecionador opcional): ao preencher a coluna Layout, verifique dois ou mais slides adjacentes que compartilhariam o mesmo idioma visual — na maioria das vezes barras horizontais (veja references/slide_patterns.md → "Varie o idioma da barra entre slides adjacentes"). Quando encontrar uma sequência, varie o tratamento você mesmo ou levante o selecionador de pré-visualização para o slide repetido: um AskUserQuestion com o layout recomendado primeiro (rotule-o (Recomendado)), depois 2 alternativas seguras de renderização, cada uma carregando um mini-mockup ASCII curto do layout no campo preview da opção para que o usuário escolha a partir de imagens, não de nomes de padrões. Isso permanece opcional — é acionado em uma repetição detectada, um empate genuíno ou um "quais são minhas opções" do usuário, não em todos os slides. É a contraparte barata do Modo de variação da Etapa 4.5: nada é construído até que o usuário escolha.

Pule a Etapa 1.5 apenas se o usuário já tiver fornecido um inputs.json completo ou tiver escrito explicitamente "pule o ghost deck". Caso contrário, é inegociável.

Etapa 1.6 — Disciplina de criação por slide (5 etapas)

Para cada slide, preencha o esquema nesta ordem. Não pule etapas.

1. Mensagem — escreva slides[i].title primeiro. Deve ser um título de ação (o "e daí"). Se você não consegue escrever o título, ainda não entende para que serve o slide.
2. Estrutura — escolha slides[i].layout do catálogo que suporta o título. O padrão são padrões de trabalho densos (diagnostic-three-panel, prioritisation-matrix, phased-roadmap-gantt, three-col-comparison, waterfall-baseline-to-target). Use condimentos esparsos (stat-row, big-numeral-findings) apenas como pontes de seção, nunca como a maior parte do deck.
3. Gráficos / visuais principais — preencha slides[i].content. O visual deve ser legível em 5 segundos. Para matrizes: onde os pontos estão? Para gantts: quais fluxos de trabalho se sobrepõem? Para cascatas: qual item de linha domina?
4. Suporte — preencha slides[i].context (moldura de uma frase antes dos dados chegarem) e slides[i].footer_note (fonte + ressalva). Ambos são inegociáveis em slides de dados.
5. Polimento — tratado por scripts/check_titles.js + Etapa 7 pós-voo anti-porcaria + Etapa 8 portão de entrega flight-check. Execute antes da entrega.

Escolher o layout antes da mensagem é como slides herói esparsos vazam. Escolher visuais antes do layout é como gráficos acabam não suportando seus títulos. Polir antes do conteúdo é trabalho desperdiçado. A ordem importa.

Referência completa: references/methodology/slide_creation_process.md.

Etapa 2 — Leia o sistema de design + padrões

Sempre leia (a cada construção), nesta ordem:

1. references/design_system.md — paleta/tipografia/anatomia bloqueadas. Não se desvie sem um motivo.
2. references/slide_patterns.md — o catálogo mestre de padrões + convenções universais (títulos de ação, cor seletiva, honestidade do gráfico, ordenação de barras/colunas, direto ao rótulo, círculos de área em escala, disciplina de rodapé, regras específicas de cascata).
3. references/build-helpers.md — constantes de paleta, os auxiliares header()/title()/footer(), todas as receitas de padrões (§2.x) e a tabela de pegadinhas. A referência de implementação para cada construção. assets/reference-build.js é o exemplo trabalhado que exercita estes.
4. references/methodology/content-interview.md — estrutura da entrevista de conteúdo (situação → problema → hipótese → evidência → argumento → resposta). Execute a Fase 1 antes de tocar em qualquer script de construção.

Leia sob demanda (apenas quando o gatilho se aplicar):

• references/chart-selection-guide.md + references/chart-library/ — quando um slide precisar de um gráfico. Orientado pela Etapa 2.5; não pré-carregue.
• references/slide-job-to-layout.md — ao escolher layouts nas Etapas 1.5 e 4.5, para tornar a seleção de padrões rastreável em vez de intuitiva.
• references/raci-guidance.md — ao construir um RACI ou qualquer slide de propriedade de função.

Se o usuário fornecer um deck de referência ou slide para corresponder, extraia suas miniaturas para layout e seu texto para estrutura de seção. Trate qualquer referência externa como apenas estrutura: estude como é construída, nunca copie suas palavras, números ou imagens.

Etapa 2.5 — Slides de gráfico: consulte a biblioteca de gráficos + guia de seleção de gráficos

Quando um slide precisar de um gráfico (barras, linhas, empilhado, painel duplo, barra/linha combinada, pequenos múltiplos, cascata, mekko), não improvise. Duas referências em sequência:

Primeiro, references/chart-selection-guide.md — a tabela de seleção rápida no topo mapeia a mensagem pretendida do slide para o tipo de gráfico. O princípio: o tipo de gráfico se ajusta à mensagem, não à forma dos dados. Aplique as dicas específicas do gráfico (sem 3D, linhas de rótulo diretas, ordem lógica da barra, etc.).