zairuilab/consulting-deck

Consulting Deck

Crie apresentações prontas para decisão, não resumos decorativos. Construa um argumento claro, rastreie cada afirmação material, selecione layouts pela função de comunicação e entregue um .pptx nativo cujo texto, gráficos, tabelas e diagramas simples permaneçam editáveis.

Trate isso como um sistema de apresentação independente criado por Peng · 智珠在睿. Não implique afiliação com McKinsey, BCG, Bain ou outra consultoria. Não copie seus logotipos, modelos proprietários ou ativos de marca protegidos, a menos que o usuário forneça ativos licenciados e solicite explicitamente seu uso.

Carregue a orientação correta

Carregue a orientação progressivamente:

1. Comece toda rota Criar ou Revisar com references/harness-system.md, references/workflow.md e references/presentation-modes.md.
2. Leia references/problem-solving-system.md para um tópico, pergunta de negócio em aberto, escolha estratégica ou solicitação de pesquisa do zero. Não force uma árvore de hipóteses em uma solicitação de resumo fiel de fontes.
3. Leia references/storyline-system.md ao construir o pensamento central e a sequência de slides.
4. Leia references/chart-system.md e references/charts-and-data.md apenas quando evidências quantitativas ou exposições materiais estiverem presentes.
5. Leia references/visual-system.md e references/layout-library.md ao planejar a amostra de método e o sistema completo de slides.
6. Leia references/quality-gates.md antes da validação e entrega.
7. Leia references/brand-system.md apenas quando uma marca, logotipo, fonte ou modelo PPTX for usado.
8. Leia references/runtime-adapters.md antes de selecionar a rota de produção PPTX.
9. Leia references/workspace-schema.md ao criar, retomar ou revisar um projeto de deck salvo.

Roteie a solicitação

Escolha exatamente uma rota principal:

• Criar — transforme material de origem ou um tópico em um novo deck editável.
• Revisar — modifique um projeto de deck salvo existente e regenere os slides afetados.
• Template — aplique uma marca fornecida pelo usuário ou um modelo nativo do PowerPoint.
• Auditar — inspecione um deck existente sem alterá-lo, a menos que o usuário solicite.

Não combine rotas silenciosamente. Uma solicitação de template pode refinar Criar ou Revisar, mas o projeto salvo subjacente permanece a fonte da verdade.

Estabeleça o contrato de produção

Antes de criar:

1. Identifique o público, a decisão, o contexto da apresentação, o idioma, a contagem de páginas, o modo de apresentação, o modo de densidade, a rota de análise e o limite das fontes.
2. Use a capacidade nativa atual do PowerPoint do host quando ela puder criar objetos editáveis e renderizar cada slide para inspeção.
3. Use PptxGenJS apenas como fallback quando já estiver disponível ou o usuário aprovar a instalação. Nunca substitua o PPTX solicitado por HTML.
4. Preserve um espaço de trabalho de projeto editável. Não torne o .pptx final a única fonte da verdade.
5. Mantenha a saída padrão neutra em relação à marca. Aplique assets/brands/peng.json apenas quando o usuário selecionar explicitamente o preset Peng.
6. Use o harness em estágios em references/harness-system.md. Não pule de um arquivo de origem diretamente para o código de renderização de slides.
7. Trate arquivos de gate legíveis por máquina como a fonte da verdade. Nunca afirme que um gate foi aprovado a menos que o JSON correspondente exista e contenha "passed": true.

Aplique o padrão de consultoria

Exija todos os seguintes:

• Lidere com um pensamento central e títulos de slides que respondam primeiro.
• Para uma rota de solução de problemas, defina o limite do problema, construa uma árvore de questões e mantenha hipóteses falseáveis antes de pesquisa ampla.
• Dê a cada slide um trabalho de comunicação e uma conclusão principal.
• Torne a lógica horizontal coerente entre os slides e a lógica vertical suficiente dentro de cada slide.
• Distinga fatos, cálculos, interpretações de fontes e hipóteses.
• Cite reivindicações e ativos externos em notas de rodapé visíveis ou notas do apresentador.
• Trate gráficos como a linguagem analítica principal, não uma camada de decoração secundária.
• Escreva um registro charts.json declarativo antes de renderizar cada exposição material.
• Use as famílias de gráficos baseadas em perguntas, o sistema de anotação e a hierarquia de renderização em references/chart-system.md.
• Use gráficos nativos para dados que os usuários possam precisar inspecionar ou editar. Use o vocabulário visual do Vizro e a rota de protótipo opcional para seleção e validação, não como permissão para achatar o PowerPoint final.
• No modo Analítico de Pesquisa, reconstrua as exposições materiais da fonte antes de criar resumos conceituais. Atenda aos limites de evidência e gráficos nativos em references/presentation-modes.md.
• Use um layout semântico de references/layout-library.md; não invente um layout apenas para preencher espaço.
• Use o dispositivo visual título-como-estrutura apenas em capas, divisores de seção e em um pequeno número de slides de insight decisivos.
• Renderize e inspecione cada slide em tamanho real antes da entrega.
• Mantenha verificações de máquina e revisão especializada separadas. Scripts de geometria não podem provar qualidade da evidência, veracidade do gráfico ou clareza executiva.
• Registre pré-requisitos reais entre slides em slides.json. Gere em ordem segura de dependências, depois monte na ordem de exibição voltada para o público.

Use dois modos de densidade

• Orientado ao apresentador — menos palavras, tipo maior, mais páginas, ritmo mais forte.
• Foco em leitura — mais evidências autossuficientes, anotações e notas de rodapé.

Escolha um modo a partir do contexto da apresentação. Não crie um modo intermediário vago. Quando o conteúdo não couber, divida o slide ou refine o argumento antes de reduzir o tamanho da fonte.

Modo de densidade não é modo de apresentação. Uma História Executiva com foco em leitura e um deck Analítico de Pesquisa com foco em leitura podem ter densidade de texto semelhante, mas diferentes proporções de exposições, notas de rodapé e páginas conceituais.

Visualize a direção visual

Quando o usuário não forneceu um modelo bloqueado ou referência visual explícita:

1. Crie três direções visuais compactas a partir de references/visual-system.md.
2. Mostre uma capa real, um slide analítico/de dados e um slide de framework/ação para cada direção.
3. Mantenha o conteúdo da prévia autêntico ao material do usuário; nunca mostre rótulos internos como "Opção A" dentro do próprio slide.
4. Peça ao usuário para escolher uma vez, depois aplique o sistema selecionado consistentemente.

Pule este gate apenas quando o usuário solicitar explicitamente prosseguir diretamente ou fornecer uma referência visual clara. Registre a direção escolhida no espaço de trabalho do projeto.

Preserve a editabilidade

• Mantenha texto como texto.
• Mantenha tabelas como tabelas.
• Mantenha gráficos como gráficos nativos sempre que prático.
• Mantenha dados de gráficos e intenção do gráfico separados do código de layout do slide.
• Mantenha matrizes simples, linhas do tempo, processos e árvores de questões como formas nativas.
• Use imagens para fotografias, arte texturizada ou ilustrações — não para slides inteiros com muito texto.
• Nunca entregue um deck cujas páginas sejam capturas de tela achatadas.

Itere a partir do projeto salvo

Para solicitações como "alterar o título do slide 3", edite a fonte do projeto e regenere a saída afetada. Preserve material de origem, IDs de evidência, dados de gráficos, IDs de slides e notas do apresentador. Reexecute todas as verificações de qualidade afetadas e a verificação final do deck.

Aprenda sem modificar o Skill instalado

Classifique cada correção material como única ou repetível. Registre lições repetíveis no espaço de trabalho do deck em qa/experience-log.md; não edite silenciosamente o Skill instalado durante a produção normal de decks. Promova uma lição repetida para este Skill apenas por meio de uma atualização revisada e versionada do Skill.

Entregue

Entregue o .pptx final mais um resumo conciso. Mantenha planos intermediários, prévias e arquivos de QA dentro do espaço de trabalho do projeto, a menos que o usuário os solicite. Declare explicitamente quaisquer alegações não verificadas, substituições de fonte, limitações de compatibilidade ou avisos restantes.