49 prompts de consultoria com IA e 3 arquivos MD prontos!

49 prompts de consultoria com IA e 3 arquivos MD prontos: a lista definitiva para quem trabalha com projetos

Existe um abismo entre usar IA para curiosidade e usar IA como ferramenta de trabalho real. O profissional que digita “me ajude com este e-mail” recebe um texto genérico que vai precisar de reescrita. O profissional que sabe exatamente como estruturar o contexto, o objetivo e o formato recebe um rascunho que vai direto para o cliente. A diferença não está no acesso à ferramenta — está em saber o que digitar. E esse “o que digitar” tem padrão, tem estrutura e pode ser copiado.

O custo de não ter essa estrutura é invisível mas constante: horas gastas refinando respostas genéricas, apresentações que precisam ser reescritas porque a IA não entendeu o público, análises de documentos que ficaram na superfície porque o prompt não especificou o que comparar, arquivos de gestão de projetos construídos do zero toda vez que um novo projeto começa. São 20, 30, 40 minutos por tarefa que somam semanas de trabalho por ano.

Este guia entrega duas coisas em um só artigo: 49 prompts de consultoria organizados em 7 séries — de e-mails a RFPs, de apresentações a código — prontos para usar no ChatGPT, no Gemini ou no Claude; e 3 arquivos MD completos de gestão de projetos (SAFe, Scrum e PMI), formatados para colar direto no seu sistema de gerenciamento e adaptar para qualquer projeto. É a lista que um consultor sênior usaria se tivesse que começar hoje.

Neste guia: 49 prompts em 7 séries para tarefas reais de consultoria + 3 arquivos MD completos (SAFe, Scrum e PMI) prontos para colar no seu sistema de projetos. Copie, cole e adapte.

Índice

• O método de 3 camadas — por que consultores seniores têm resultados melhores com IA
• O que você vai conseguir produzir com estes prompts
• Tabela 01: ChatGPT vs Gemini vs Claude — qual usar em cada tarefa
• Tabela 02: As 7 séries e o tipo de tarefa de cada uma
• Tabela 03: Anatomia do prompt de consultoria perfeito
• 49 prompts prontos para consultoria com IA
• 3 arquivos MD completos: SAFe, Scrum e PMI
• Amanda aconselha
• Comandos de atalho quando o resultado não saiu certo
• O que a IA não consegue fazer sozinha em consultoria
• SOS: a IA deu uma resposta completamente fora do contexto
• Erros fatais ao usar IA em trabalho profissional
• Prompt fraco vs prompt forte
• Glossário rápido
• FAQ

O método de 3 camadas — por que consultores seniores têm resultados melhores com IA

Camada 1: Contexto — a IA não sabe quem você é nem o que está em jogo

O erro mais comum de profissionais que usam IA no trabalho é assumir que a ferramenta tem contexto. Ela não tem. Quando você abre um chat novo e digita “melhore este e-mail”, a IA não sabe se é para um cliente difícil ou um parceiro de longa data, se é uma negociação delicada ou uma atualização de rotina, se o tom deve ser formal ou próximo. Ela vai preencher esse vazio com a média estatística de todos os e-mails profissionais que já processou — que é, por definição, genérica. A camada de contexto é a que mais impacta o resultado e a que mais profissionais ignoram. Os prompts desta lista abrem sempre com contexto: quem você é, quem é o destinatário, qual é o objetivo e o que está em jogo.

Camada 2: Instrução — o que fazer, como fazer e o que não fazer

A instrução é o que a maioria das pessoas coloca no prompt e acha que é o suficiente. “Resuma este documento.” “Compare estes dois arquivos.” “Melhore esta apresentação.” O problema é que “resumir”, “comparar” e “melhorar” são verbos com interpretações infinitas. Resumir para quê? Comparar em quais dimensões? Melhorar segundo qual critério? A camada de instrução eficaz especifica não só o verbo, mas o formato do resultado esperado, o nível de detalhe, o que deve ser preservado e — especialmente — o que não deve ser feito. “Resuma em 5 bullets executivos priorizando riscos e decisões pendentes. Não inclua detalhes operacionais.” é uma instrução. “Resuma isso.” não é.

Camada 3: Framework — dar à IA uma lente profissional para filtrar o resultado

A terceira camada é a que separa o uso amador do uso profissional: fornecer à IA um framework de avaliação explícito. Em vez de pedir “analise esta proposta”, você pede “analise esta proposta segundo os critérios de um RFP de serviços profissionais: aderência ao escopo, clareza de entregáveis, realismo de cronograma e completude de precificação”. Em vez de “melhore esta apresentação”, você pede “avalie esta apresentação do ponto de vista de um diretor financeiro que tem 7 minutos para decidir se aprova o orçamento”. O framework é a lente. E é exatamente isso que os 3 arquivos MD desta lista fornecem para gestão de projetos: um framework completo (SAFe, Scrum ou PMI) que você cola como contexto antes de qualquer pergunta sobre o projeto.

O que você vai conseguir produzir com estes prompts

Tabela 01: ChatGPT vs Gemini vs Claude — qual usar em cada tarefa de consultoria

Tabela 02: As 7 séries e o tipo de tarefa de cada uma

Tabela 03: Anatomia do prompt de consultoria perfeito

49 prompts prontos para consultoria com IA — copie e cole 📌

Substitua os campos entre [colchetes] pelo contexto real do seu projeto antes de enviar. Quanto mais específico o preenchimento, melhor o resultado. A ferramenta recomendada está indicada no cabeçalho de cada série — mas todos os prompts funcionam nas três plataformas.

Para tarefas que envolvem documentos (Séries C, D, F e G), cole o conteúdo do documento no chat antes do prompt, ou use a funcionalidade de upload de arquivo de cada plataforma.

✉️ Série A — Comunicação Profissional (prompts A-01 a A-07)

Recomendação: qualquer ferramenta | Claude para situações diplomaticamente delicadas

📧 Prompt A-01 — Ajustar tom de e-mail para contexto específico

Contexto: Sou [cargo] em [tipo de empresa/área]. O destinatário é [cargo do destinatário] em [empresa/contexto do destinatário]. Nossa relação é [nova/estabelecida/tensa/formal]. O objetivo deste e-mail é [objetivo específico].

Aqui está o e-mail atual:
[COLE O E-MAIL AQUI]

Tarefa: Reescreva este e-mail para que o tom seja [mais amigável | mais assertivo | mais formal | mais direto | mais diplomático]. Preserve todas as informações factuais. Ajuste apenas o tom, a estrutura e o nível de formalidade.

Formato de saída: E-mail completo, pronto para enviar, com assunto sugerido.

📧 Prompt A-02 — Resumo executivo de comunicação longa

Contexto: Preciso resumir o conteúdo abaixo para [CEO | comitê | cliente | equipe]. O leitor tem no máximo [X] minutos e precisa sair com clareza sobre [decisões pendentes | próximos passos | riscos | status].

Aqui está o conteúdo a resumir:
[COLE O DOCUMENTO, E-MAIL OU TRANSCRIÇÃO AQUI]

Tarefa: Crie um resumo executivo estruturado assim:
1. Situação atual (1–2 frases)
2. Decisões necessárias (bullets)
3. Próximos passos com responsável e prazo (tabela)
4. Riscos que precisam de atenção (bullets)

Não inclua detalhes operacionais. Linguagem direta, sem jargão desnecessário.

📧 Prompt A-03 — Follow-up de reunião com encaminhamentos

Contexto: Participei de uma reunião com [participantes e cargos] sobre [tema]. A reunião aconteceu em [data]. Preciso enviar o follow-up para [destinatários].

Aqui estão as notas da reunião:
[COLE AS NOTAS OU TRANSCRIÇÃO AQUI]

Tarefa: Crie um e-mail de follow-up profissional com:
- Parágrafo de abertura contextualizando a reunião (2 frases)
- Tabela de encaminhamentos: Ação | Responsável | Prazo
- Próxima reunião/checkpoint (se houver)
- Fechamento que mantenha o engajamento

Tom: [formal | próximo | neutro]. Assunto do e-mail incluído.

📧 Prompt A-04 — Recusa diplomática de pedido ou proposta

Contexto: Preciso recusar [pedido | proposta | convite | solicitação] de [quem]. O motivo real é [motivo real]. O que posso dizer publicamente é [motivo que pode ser compartilhado]. Quero preservar o relacionamento.

Tarefa: Escreva um e-mail de recusa que:
- Agradeça e reconheça o valor da iniciativa/pedido
- Decline claramente, sem ambiguidade
- Explique brevemente usando apenas o motivo compartilhável
- Deixe a porta aberta para colaboração futura (se for o caso: [sim | não])
- Não use frases clichê como "no momento não temos recursos" sem contexto

Tom: [formal | próximo]. Assunto incluído.

📧 Prompt A-05 — Atualização de status para stakeholder não-técnico

Contexto: Preciso atualizar [cargo do stakeholder] sobre o projeto [nome do projeto]. Ele não tem contexto técnico e se importa principalmente com [prazo | orçamento | risco | resultado de negócio]. Status atual: [breve descrição do status real].

Aqui estão os detalhes técnicos que preciso comunicar:
[LISTE OS PONTOS TÉCNICOS A COMUNICAR]

Tarefa: Reescreva estes pontos em linguagem executiva acessível, sem jargão técnico. Use analogias de negócio quando necessário. Estruture em:
- Verde/Amarelo/Vermelho: status geral em 1 linha
- O que está funcionando (2–3 bullets)
- O que precisa de atenção (1–2 bullets com impacto no negócio)
- O que precisamos do stakeholder (ação específica, se houver)

Formato: E-mail curto, máximo 200 palavras.

📧 Prompt A-06 — Escalada de problema para a liderança

Contexto: Preciso escalar um problema para [cargo da liderança]. O problema é [descrição do problema]. Impacto se não resolvido: [impacto]. Já tentei [o que já foi tentado]. Preciso de [decisão | recurso | autorização | visibilidade].

Tarefa: Escreva um e-mail de escalada que:
- Apresente o problema em 2 frases objetivas (sem drama, sem minimização)
- Mostre o que já foi feito para resolver
- Quantifique o impacto (prazo, custo, risco)
- Apresente 2–3 opções de resolução com prós e contras resumidos
- Faça um pedido claro e específico para a liderança

Tom: profissional, direto, orientado a solução — não a reclamação. Assunto incluído com indicação de urgência.

📧 Prompt A-07 — Mensagem para alinhar expectativas antes que virem problema

Contexto: Percebi que existe uma expectativa desalinhada entre [minha equipe | meu projeto] e [cliente | stakeholder | parceiro] sobre [o que está desalinhado]. Se não corrigirmos agora, o problema vai aparecer em [quando]. Quero corrigir o alinhamento sem soar como entrega de má notícia ou criação de alarme desnecessário.

Tarefa: Escreva uma mensagem que:
- Abra reconhecendo o progresso ou o contexto positivo do projeto
- Introduza o ponto de alinhamento de forma neutra ("quero garantir que estamos alinhados sobre...")
- Clarifique a expectativa correta sem atacar a percepção errada
- Proponha um checkpoint ou confirmação rápida
- Feche de forma colaborativa

Tom: construtivo, proativo, não-defensivo. Formato: e-mail curto ou mensagem para [Slack | Teams | WhatsApp profissional].

📊 Série B — Apresentações e Decks (prompts B-01 a B-07)

Recomendação: ChatGPT para criar estrutura | Gemini para exportar para Google Slides | Claude para revisão crítica

📊 Prompt B-01 — Diagnóstico crítico de apresentação existente

Contexto: Tenho uma apresentação sobre [tópico]. O público-alvo é [cargo/perfil do público]. O objetivo da apresentação é [objetivo: convencer | informar | aprovar | engajar]. O tempo disponível é [X minutos].

Aqui está o conteúdo atual da apresentação (slide por slide):
[COLE O CONTEÚDO DOS SLIDES — TÍTULO E BULLETS DE CADA SLIDE]

Tarefa: Analise esta apresentação do ponto de vista do público-alvo e me diga:
1. O que não está funcionando na abordagem atual (seja específico)
2. Quais slides podem ser eliminados sem perda de impacto
3. Qual informação crítica está faltando para o objetivo declarado
4. A ordem atual conta uma história lógica? Se não, sugira reordenação

Formato: Lista estruturada por problema, com sugestão de correção para cada um.

📊 Prompt B-02 — Estrutura de apresentação executiva do zero

Contexto: Preciso criar uma apresentação executiva sobre [tópico]. Público: [cargo/perfil]. Objetivo: [objetivo]. Tempo: [X minutos]. Contexto do projeto/empresa: [breve contexto].

Aqui estão os pontos principais que preciso cobrir:
[LISTE OS PONTOS — podem ser notas brutas, não precisa estar organizado]

Tarefa: Crie a estrutura completa da apresentação:
- Liste cada slide com: Número | Título | Mensagem principal (1 frase) | Conteúdo sugerido (bullets)
- A estrutura deve seguir o arco: Situação → Complicação → Solução → Impacto → Próximos passos
- Máximo [X] slides
- O slide de abertura deve capturar atenção com o problema, não com o título do projeto

Inclua: sugestão de qual dado ou visual vai em cada slide.

📊 Prompt B-03 — Reescrever slide de dados em narrativa executiva

Contexto: Tenho um slide com dados que precisa se tornar uma mensagem executiva clara. O público é [cargo]. O que quero que ele saia sabendo depois deste slide: [mensagem desejada].

Aqui estão os dados do slide atual:
[COLE OS DADOS, NÚMEROS E BULLETS DO SLIDE]

Tarefa:
1. Escreva o título do slide como uma afirmação (não como tema): ex. "Receita cresceu 23% mas margem caiu 8 pontos" — não "Resultados Financeiros"
2. Reduza o conteúdo a no máximo 3 bullets, cada um sendo uma conclusão — não um dado solto
3. Identifique o dado mais importante e sugira como torná-lo o elemento visual central
4. Escreva a frase de legenda/rodapé que ancora a mensagem principal

O objetivo é que o executivo entenda a mensagem mesmo sem o apresentador explicando.

📊 Prompt B-04 — Roteiro de apresentação oral (o que falar em cada slide)

Contexto: Tenho uma apresentação pronta e preciso do roteiro oral — o que falar em cada slide. O público é [cargo/perfil]. A duração total é [X minutos]. O tom deve ser [formal | conversacional | técnico].

Aqui está a estrutura dos slides (título + bullets de cada um):
[COLE A ESTRUTURA DOS SLIDES]

Tarefa: Para cada slide, escreva:
- Frase de transição do slide anterior (para os slides 2 em diante)
- O que falar: roteiro em linguagem oral, não de leitura
- Duração estimada em segundos
- Pergunta retórica ou dado de impacto para manter atenção (quando apropriado)

O roteiro deve soar como um profissional falando, não como um texto sendo lido.

📊 Prompt B-05 — Preparação para perguntas difíceis após apresentação

Contexto: Vou apresentar [tema] para [público: board | diretoria | comitê de investimento | cliente]. O ponto mais vulnerável da minha proposta é [vulnerabilidade]. Os céticos no público provavelmente vão questionar [o que você acha que será questionado].

Aqui está o resumo da minha proposta/apresentação:
[COLE O RESUMO OU OS SLIDES PRINCIPAIS]

Tarefa: Gere as 7 perguntas mais difíceis que esse público pode fazer — priorizando perguntas sobre [custo | viabilidade | risco | alternativas | precedentes]. Para cada pergunta, escreva:
- A pergunta exatamente como seria feita
- A resposta ideal em 3–5 frases
- O que NÃO dizer (armadilhas a evitar na resposta)

📊 Prompt B-06 — Converter relatório em deck de 10 slides

Contexto: Tenho um relatório/documento longo que precisa se tornar um deck executivo de máximo 10 slides para [público]. O objetivo é [aprovar | informar | engajar | convencer].

Aqui está o relatório/documento:
[COLE O DOCUMENTO]

Tarefa:
1. Identifique as 10 mensagens mais importantes para o objetivo e o público declarados
2. Para cada mensagem, crie um slide: Número | Título (afirmação) | Conteúdo em até 4 bullets | Dado/visual sugerido
3. O que ficou de fora: liste os tópicos do relatório que foram omitidos e por quê
4. Sugira qual material pode ir como apêndice para quem quiser aprofundar

Critério de seleção: priorize decisões, riscos e impacto de negócio sobre detalhes operacionais.

📊 Prompt B-07 — One-pager executivo de um projeto ou iniciativa

Contexto: Preciso criar um one-pager sobre [projeto/iniciativa] para [público]. Objetivo do documento: [aprovação de orçamento | alinhamento de stakeholders | recrutamento de patrocinador | comunicação de lançamento].

Aqui estão as informações disponíveis sobre o projeto:
[COLE AS INFORMAÇÕES — podem ser notas brutas]

Tarefa: Crie um one-pager estruturado com:
- Título e subtítulo de impacto (não o nome técnico do projeto)
- O problema que resolve (2–3 frases, linguagem de negócio)
- A solução proposta (o que, não como — 3–4 bullets)
- Impacto esperado com métricas (receita | custo | tempo | risco)
- O que precisamos: recursos, aprovação, decisão (específico)
- Próximo passo claro com data

Formato: Texto corrido organizado por seções, pronto para ser copiado num documento de 1 página.

📄 Série C — Análise de Documentos (prompts C-01 a C-07)

Recomendação: Claude (janela de 200k tokens, melhor retenção de detalhe em documentos longos)

📄 Prompt C-01 — Comparativo entre dois documentos com foco específico

Contexto: Preciso comparar dois documentos. O objetivo da comparação é [identificar diferenças | avaliar evolução | checar consistência | escolher entre opções]. Os critérios mais importantes para esta comparação são [liste os critérios: ex. escopo, prazo, custo, riscos, obrigações contratuais].

Documento 1 — [Nome/Descrição]:
[COLE O DOCUMENTO 1]

Documento 2 — [Nome/Descrição]:
[COLE O DOCUMENTO 2]

Tarefa: Compare os dois documentos especificamente nos critérios listados. Entregue:
1. Tabela comparativa: Critério | Doc 1 | Doc 2 | Diferença relevante
2. Pontos em que os documentos contradizem um ao outro
3. O que está em um e ausente no outro (gaps)
4. Recomendação: qual documento prevalece em cada critério e por quê

Seja específico — cite seção e trecho quando indicar diferença.

📄 Prompt C-02 — Extração de pontos de ação e decisão de documento longo

Contexto: Tenho um documento longo [relatório | ata | especificação | contrato] que preciso processar para extrair o que é acionável. O leitor é [cargo] e precisa saber o que fazer, não apenas o que está documentado.

Aqui está o documento:
[COLE O DOCUMENTO]

Tarefa: Leia o documento completo e extraia:
1. Decisões tomadas (com data e responsável, se mencionados)
2. Ações pendentes (o que precisa ser feito, por quem, até quando)
3. Dependências identificadas (o que X depende de Y)
4. Riscos ou alertas mencionados explicitamente ou implicitamente
5. Aprovações necessárias ainda não obtidas

Formato: Tabela para cada categoria. Cite o trecho original entre aspas para cada item extraído.

📄 Prompt C-03 — Análise de contrato com foco em obrigações e riscos

Contexto: Preciso revisar este contrato/acordo do ponto de vista de [parte que represento: contratante | contratado | parceiro]. Minha principal preocupação é [prazo | cláusulas de rescisão | multas | propriedade intelectual | SLA | limitação de responsabilidade].

Aqui está o contrato:
[COLE O CONTRATO]

Tarefa: Analise o contrato com foco em:
1. Obrigações da minha parte — liste cada uma com a cláusula de referência
2. Obrigações da outra parte — idem
3. Cláusulas de risco para minha posição (multas desproporcionais, prazo de notificação curto, termos vagos)
4. O que está ausente e deveria estar (lacunas que podem virar problema)
5. As 3 cláusulas que eu mais precisaria negociar se pudesse

Importante: não forneça aconselhamento jurídico. Aponte os pontos — a validação final é com o advogado.

📄 Prompt C-04 — Revisão de especificação técnica com checklist de qualidade

Contexto: Tenho uma especificação técnica [de sistema | de produto | de processo | de requisitos] que precisa ser revisada antes de [entrar em desenvolvimento | ser enviada ao fornecedor | ser aprovada pelo cliente].

Aqui está a especificação:
[COLE A ESPECIFICAÇÃO]

Tarefa: Revise a especificação verificando:
1. Requisitos ambíguos — onde "deve fazer X" não especifica como, quando ou o quanto
2. Requisitos conflitantes — onde dois requisitos se contradizem
3. Requisitos faltantes — que funcionalidade ou comportamento deveria estar aqui e não está
4. Critérios de aceite — cada requisito tem critério de aceite mensurável?
5. Dependências não documentadas — o que este sistema/produto assume que o ambiente vai fornecer?

Formato: Para cada problema encontrado: Tipo | Trecho problemático | Por que é problema | Sugestão de correção.

📄 Prompt C-05 — Síntese de múltiplas fontes em visão consolidada

Contexto: Tenho [número] documentos/fontes diferentes sobre [tema] e preciso de uma visão consolidada para [tomar decisão | criar relatório | apresentar para liderança | montar estratégia].

Fonte 1 — [Descrição]:
[COLE A FONTE 1]

Fonte 2 — [Descrição]:
[COLE A FONTE 2]

Fonte 3 — [Descrição]:
[COLE A FONTE 3]

Tarefa: Sintetize as fontes em:
1. Pontos de consenso (onde as fontes concordam)
2. Pontos de divergência (onde diferem — e qual é a diferença)
3. Visão consolidada: a narrativa única que emerge das fontes, ponderando a confiabilidade de cada uma
4. Lacunas: o que as fontes não cobrem e seria importante saber

Cite qual fonte suporta cada afirmação.

📄 Prompt C-06 — Auditoria de consistência entre documentos de projeto

Contexto: Tenho múltiplos documentos do mesmo projeto e preciso verificar se são consistentes entre si — se o que está no cronograma corresponde ao escopo, se o orçamento cobre o que está na proposta técnica, etc.

Documento de escopo/proposta:
[COLE O DOCUMENTO DE ESCOPO]

Cronograma:
[COLE O CRONOGRAMA]

Orçamento/WBS:
[COLE O ORÇAMENTO]

Tarefa: Faça uma auditoria de consistência verificando:
1. Entregáveis no escopo que não aparecem no cronograma (ou vice-versa)
2. Atividades no cronograma sem linha orçamentária correspondente
3. Premissas declaradas em um documento contraditas por outro
4. Prazos no cronograma incompatíveis com sequência lógica de atividades

Formato: Lista de inconsistências com referência aos documentos de origem.

📄 Prompt C-07 — Relatório de lições aprendidas a partir de documentos do projeto

Contexto: O projeto [nome] foi concluído/encerrado. Tenho os documentos do projeto e preciso extrair lições aprendidas para o relatório de encerramento e para uso em projetos futuros.

Documentos disponíveis:
[COLE ATAS, RELATÓRIOS DE STATUS, REGISTRO DE RISCOS, FEEDBACK DE CLIENTE]

Tarefa: Analise os documentos e gere o relatório de lições aprendidas com:
1. O que funcionou bem (práticas a repetir)
2. O que não funcionou (problemas recorrentes ou de alto impacto)
3. O que faríamos diferente (recomendações concretas, não genéricas)
4. Riscos que se materializaram e como foram tratados
5. Recomendações específicas para o próximo projeto similar

Formato: Seções separadas. Para cada lição: descrição do evento, impacto, e recomendação prática.

🎯 Série D — RFP e Propostas Comerciais (prompts D-01 a D-07)

Recomendação: Claude para análise de aderência | ChatGPT para redigir seções da proposta

🎯 Prompt D-01 — Checklist de aderência proposta × RFP

Contexto: Tenho um RFP (Request for Proposal) e nossa proposta de resposta. Preciso verificar se estamos cobrindo todos os requisitos antes de enviar.

Aqui está o RFP:
[COLE O RFP]

Aqui está nossa proposta:
[COLE A PROPOSTA]

Tarefa: Verifique se a proposta atende cada requisito do RFP. Entregue:
1. Tabela de aderência: Requisito do RFP | Está na proposta? (Sim/Parcial/Não) | Onde na proposta | Observação
2. Requisitos não atendidos ou atendidos apenas parcialmente — com prioridade (eliminatório | importante | desejável)
3. O que a proposta inclui que o RFP não pediu (pode ser diferencial ou ruído — avalie)
4. As 3 maiores lacunas que precisam ser corrigidas antes do envio

🎯 Prompt D-02 — Análise competitiva de proposta recebida de fornecedor

Contexto: Recebi [número] propostas de fornecedores para [tipo de serviço/produto]. Preciso avaliá-las objetivamente para recomendar ao [comitê | diretoria | cliente]. Os critérios de avaliação são [liste os critérios com pesos se houver].

Proposta A — [Fornecedor]:
[COLE A PROPOSTA A]

Proposta B — [Fornecedor]:
[COLE A PROPOSTA B]

Proposta C — [Fornecedor] (se houver):
[COLE A PROPOSTA C]

Tarefa: Compare as propostas nos critérios declarados. Entregue:
1. Scorecard: Critério | Peso | Fornecedor A | Fornecedor B | Fornecedor C | Pontuação
2. Pontos de diferenciação relevantes de cada proposta
3. Riscos específicos de cada proposta (o que pode dar errado com cada fornecedor)
4. Recomendação fundamentada com os 3 principais motivos

🎯 Prompt D-03 — Fortalecer seção fraca de proposta comercial

Contexto: Tenho uma proposta comercial para [tipo de serviço] para o cliente [tipo/setor de cliente]. A seção mais fraca é [nome da seção]. O que o cliente mais se importa nesta seção é [preocupação do cliente].

Aqui está a seção atual:
[COLE A SEÇÃO FRACA]

Aqui está o contexto do projeto que pode ser usado para fortalecer:
[COLE CONTEXTO ADICIONAL: cases, metodologia, diferenciais, dados]

Tarefa: Reescreva esta seção da proposta para que:
1. Abra com a preocupação do cliente (não com nossa empresa)
2. Responda diretamente ao que o cliente se importa
3. Use dados e evidências específicas (não afirmações genéricas)
4. Diferencie nossa abordagem da abordagem padrão do mercado
5. Feche com o próximo passo ou compromisso concreto

Tom: profissional, confiante, orientado ao cliente.

🎯 Prompt D-04 — Identificar objeções implícitas em RFP

Contexto: Preciso ler nas entrelinhas de um RFP para entender o que o cliente realmente quer — além do que está explicitamente escrito. Isso vai informar como posicionar nossa proposta.

Aqui está o RFP:
[COLE O RFP]

Tarefa: Analise o RFP e identifique:
1. Requisitos que sugerem uma experiência ruim anterior (o cliente está pedindo isso por que já se queimou)
2. O que o cliente valorizou mais — inferido pelo nível de detalhe que dedicou a cada seção
3. Critérios de seleção não declarados — o que o cliente vai avaliar mesmo não dizendo que vai
4. A dor real por trás do projeto (o problema de negócio que motivou o RFP)
5. Como posicionar nossa proposta para endereçar os medos não-declarados

Formato: Análise narrativa por seção do RFP, seguida de 5 recomendações de posicionamento.

🎯 Prompt D-05 — Redigir seção de metodologia para proposta técnica

Contexto: Preciso redigir a seção de metodologia de uma proposta para [tipo de projeto]. O cliente é [setor/perfil]. O diferencial que quero destacar é [nosso diferencial]. A abordagem que usaremos é [descreva brevemente a abordagem].

Aqui estão os detalhes da abordagem que tenho disponíveis:
[COLE NOTAS, PROCESSO, FRAMEWORK]

Tarefa: Redija a seção de metodologia da proposta com:
1. Visão geral da abordagem (parágrafo de abertura orientado ao resultado para o cliente)
2. Fases do projeto: Fase | Atividades principais | Entregáveis | Responsabilidade | Duração indicativa
3. O que nos diferencia nesta abordagem (específico, não genérico)
4. Premissas e dependências do cliente (o que precisamos que eles forneçam)
5. Como medimos o sucesso desta fase

Linguagem: profissional mas acessível; evite jargão técnico sem explicação.

🎯 Prompt D-06 — Resumo executivo de proposta (o primeiro que o decisor lê)

Contexto: Tenho uma proposta completa e preciso do resumo executivo — a seção que o decisor lê antes de decidir se continua lendo. O decisor é [cargo]. O que mais importa para ele é [ROI | risco | prazo | custo | credencial do fornecedor].

Aqui está a proposta completa:
[COLE A PROPOSTA]

Tarefa: Escreva um resumo executivo de máximo 400 palavras que:
1. Abre com o problema do cliente (não com nossa empresa)
2. Apresenta nossa solução em termos de resultado para o negócio
3. Destaca o diferencial específico desta proposta (por que nós, não qualquer concorrente)
4. Menciona prazo e investimento de forma objetiva
5. Fecha com a próxima ação e o porquê de agir agora

O resumo executivo deve convencer mesmo para quem não ler mais nada.

🎯 Prompt D-07 — Revisão final de proposta antes do envio

Contexto: Esta proposta vai ser enviada amanhã. Preciso de uma revisão crítica final antes do envio. O cliente é [perfil]. Os critérios de seleção declarados são [critérios].

Aqui está a proposta completa:
[COLE A PROPOSTA]

Tarefa: Faça a revisão pré-envio verificando:
1. Consistência interna — prazos, valores e escopos são os mesmos em todas as seções?
2. Referências ao cliente — usamos o nome correto, cargo correto e contexto correto?
3. Clareza da proposta de valor — em 1 frase, qual é o motivo para nos escolher? Se não conseguir extrair, a proposta está fraca
4. Afirmações sem suporte — onde fazemos promessas vagas sem evidência?
5. Erros de posicionamento — onde soamos arrogantes, defensivos ou genéricos demais?
6. O que um revisor externo acharia confuso ou não convincente

Formato: Lista de pontos críticos para corrigir antes do envio, ordenados por prioridade.

💻 Série E — Código e Sistemas (prompts E-01 a E-07)

Recomendação: ChatGPT ou Claude para debug e revisão | Gemini para notebooks Python no Google Colab

💻 Prompt E-01 — Debug de erro com contexto completo

Contexto: Estou trabalhando em [linguagem/framework/ambiente]. O problema que estou enfrentando é [descrição do comportamento esperado vs. comportamento atual]. O erro aparece quando [condição que dispara o erro].

Aqui está a mensagem de erro completa:
[COLE A MENSAGEM DE ERRO]

Aqui está o código relevante:
[COLE O CÓDIGO]

Contexto adicional (versões, dependências, dados de entrada):
[LISTE VERSÕES E DEPENDÊNCIAS RELEVANTES]

Tarefa:
1. Identifique a causa raiz do erro (não apenas o sintoma)
2. Explique por que este erro acontece em linguagem que eu possa entender
3. Mostre a correção exata com o código corrigido
4. Indique se há outros pontos do código com o mesmo problema potencial
5. O que eu deveria ter feito diferente para evitar este erro

💻 Prompt E-02 — Revisão de código com foco em qualidade e manutenibilidade

Contexto: Este código funciona mas precisa ser revisado antes de [ir para produção | ser entregue ao cliente | entrar no repositório principal]. Linguagem: [linguagem]. Padrões que precisamos seguir: [padrões ou convenções da equipe, se houver].

Aqui está o código:
[COLE O CÓDIGO]

Tarefa: Revise o código avaliando:
1. Legibilidade — onde o código é difícil de entender sem comentário?
2. Manutenibilidade — o que vai ser problemático quando alguém precisar alterar daqui a 6 meses?
3. Tratamento de erros — onde o código pode quebrar silenciosamente?
4. Performance — existem operações desnecessariamente custosas?
5. Segurança — há inputs não sanitizados, dados expostos ou vulnerabilidades óbvias?

Formato: Para cada problema: linha | tipo | descrição | sugestão de correção. Ao final, versão do código com as correções aplicadas.

💻 Prompt E-03 — Documentação de código existente

Contexto: Tenho código que funciona mas não está documentado. Preciso documentá-lo para [novo desenvolvedor onboarding | handoff para outro time | open source | auditoria]. Nível de detalhe esperado: [alto | médio | apenas funções públicas].

Aqui está o código:
[COLE O CÓDIGO]

Tarefa: Gere a documentação completa incluindo:
1. Docstring/comentário de cada função com: o que faz, parâmetros (tipo + descrição), retorno, exceções que pode lançar, exemplo de uso
2. Comentários inline nos trechos mais complexos explicando o porquê (não o o quê)
3. README de módulo: visão geral, dependências, como usar, limitações conhecidas
4. Glossário de termos de domínio usados no código (se relevante)

Formato: Código completo com documentação inserida + seção de README separada ao final.

💻 Prompt E-04 — Refatoração de código legado para padrão moderno

Contexto: Tenho código legado em [linguagem/versão antiga] que precisa ser refatorado para [versão/padrão moderno]. Restrições: [o que não pode mudar — interface pública, compatibilidade com X, etc.].

Aqui está o código atual:
[COLE O CÓDIGO LEGADO]

Tarefa:
1. Identifique os principais antipadrões e problemas do código atual
2. Proponha a estratégia de refatoração (o que refatorar primeiro e por quê)
3. Entregue o código refatorado com as mudanças aplicadas
4. Para cada mudança significativa, explique: o que mudou | por que é melhor | risco de regressão
5. Liste os testes que precisariam ser escritos/atualizados para validar a refatoração

O comportamento externo do código deve ser idêntico após a refatoração.

💻 Prompt E-05 — Geração de testes automatizados para função existente

Contexto: Preciso de testes para esta função/classe. Framework de teste: [pytest | jest | JUnit | etc.]. Cobertura desejada: [apenas casos de sucesso | casos de borda | casos de falha | cobertura completa].

Aqui está o código a ser testado:
[COLE O CÓDIGO]

Tarefa: Gere a suite de testes cobrindo:
1. Casos de sucesso — entradas válidas e resultado esperado
2. Casos de borda — valores nulos, vazios, extremos, tipos incorretos
3. Casos de falha — o que deve lançar exceção e qual exceção
4. Testes de integração se houver dependências externas (com mocks onde necessário)

Para cada teste: nome descritivo | arrange-act-assert | comentário explicando o que está sendo validado e por quê este caso importa.

💻 Prompt E-06 — Análise de arquitetura e identificação de débito técnico

Contexto: Tenho um sistema/aplicação em [tecnologia/stack] que está [crescendo em complexidade | com problemas de performance | difícil de manter | entrando em escala]. Quero entender o débito técnico acumulado e priorizar o que resolver.

Aqui está a descrição da arquitetura atual e os problemas percebidos:
[DESCREVA A ARQUITETURA E OS PROBLEMAS]

Aqui está o código das partes mais problemáticas (se disponível):
[COLE O CÓDIGO MAIS PROBLEMÁTICO]

Tarefa: Analise e entregue:
1. Mapa de débito técnico: Área | Problema | Impacto (Alto/Médio/Baixo) | Esforço de correção | Prioridade
2. Os 3 problemas que, se resolvidos, teriam maior impacto positivo
3. O que pode piorar se não for endereçado nos próximos [X] meses
4. Roadmap de refatoração: o que fazer primeiro, segundo e terceiro com justificativa técnica

💻 Prompt E-07 — Tradução de requisito de negócio em especificação técnica

Contexto: Tenho um requisito de negócio que precisa ser traduzido em especificação técnica para o time de desenvolvimento. Stack atual: [linguagem/framework/banco de dados]. O time tem nível [júnior | misto | sênior].

Requisito de negócio:
[DESCREVA O REQUISITO EM LINGUAGEM DE NEGÓCIO]

Tarefa: Traduza em especificação técnica incluindo:
1. User stories no formato: Como [perfil], quero [ação], para que [benefício]
2. Critérios de aceite mensuráveis para cada story
3. Diagrama de fluxo em texto (se a lógica for complexa)
4. Considerações técnicas: impacto em banco de dados, APIs afetadas, pontos de integração
5. Perguntas para o negócio antes de começar o desenvolvimento (ambiguidades que precisam de resposta)
6. Estimativa de complexidade (S/M/L/XL) com justificativa

📋 Série F — Início de Projetos (prompts F-01 a F-07)

Recomendação: Claude com MD de contexto — cole o arquivo MD da metodologia do projeto antes de usar estes prompts

📋 Prompt F-01 — Checklist de kickoff baseado no arquivo de projeto

[ANTES DESTE PROMPT: cole o arquivo MD da metodologia (SAFe, Scrum ou PMI) desta lista no início do chat]

Contexto: Estou iniciando um novo projeto. Aqui está o arquivo de projeto (ou o que temos até agora):
[COLE O ARQUIVO .MD DO PROJETO OU AS INFORMAÇÕES DISPONÍVEIS]

Tarefa: Com base na metodologia do contexto e nas informações do projeto, gere um checklist de kickoff organizado por:
1. O que precisa estar definido antes de começar (pré-requisitos)
2. O que precisa acontecer na primeira semana
3. Quem precisa ser envolvido e quando
4. Documentos que precisam ser criados
5. Riscos iniciais a monitorar desde o dia 1

Marque cada item com: Crítico | Importante | Recomendado. Inclua responsável sugerido (papel, não nome) para cada item crítico.

📋 Prompt F-02 — Identificação de riscos no início do projeto

Contexto: Estou começando o projeto [nome/descrição]. Tipo de projeto: [software | consultoria | construção | transformação organizacional | implantação]. Cliente/contexto: [descreva o ambiente].

Aqui está o que já sei sobre o projeto:
[COLE ESCOPO, OBJETIVOS, STAKEHOLDERS, CRONOGRAMA INICIAL]

Tarefa: Gere o registro inicial de riscos com os 10 riscos mais prováveis para este tipo de projeto e contexto. Para cada risco:
- Descrição do risco (o que pode acontecer)
- Probabilidade (Alta/Média/Baixa)
- Impacto (Alto/Médio/Baixo)
- Gatilho de alerta (como saber que o risco está se materializando)
- Plano de resposta inicial (mitigar | aceitar | transferir | evitar + ação concreta)
- Responsável pelo monitoramento (papel)

Inclua pelo menos 2 riscos que projetos similares geralmente ignoram no início.

📋 Prompt F-03 — Matriz de stakeholders e plano de engajamento

Contexto: Projeto: [nome/descrição]. Aqui estão os stakeholders que identificamos:
[LISTE OS STAKEHOLDERS COM CARGO E PAPEL NO PROJETO]

Tarefa: Crie a matriz de stakeholders e o plano de engajamento:
1. Mapa de poder × interesse: classifique cada stakeholder em: Alta influência/Alto interesse | Alta influência/Baixo interesse | Baixa influência/Alto interesse | Baixa influência/Baixo interesse
2. Para cada stakeholder de alta influência: postura atual (favorável | neutro | resistente | desconhecido) e estratégia de engajamento
3. Plano de comunicação: Stakeholder | Canal | Frequência | Conteúdo | Responsável
4. Stakeholders críticos que podem inviabilizar o projeto se não engajados corretamente — com alerta de como saber se estão saindo do alinhamento

📋 Prompt F-04 — Decomposição de escopo em WBS de primeiro nível

Contexto: Tenho o escopo macro do projeto [nome]. Preciso decompor em WBS (Work Breakdown Structure) até o segundo ou terceiro nível para estimar esforço e atribuir responsabilidades.

Aqui está o escopo:
[DESCREVA O ESCOPO DO PROJETO]

Tarefa:
1. Crie a WBS em formato hierárquico numerado (1.0 | 1.1 | 1.1.1)
2. Para cada entregável de último nível: responsável (papel) | duração estimada | dependências
3. Identifique os 3 entregáveis com maior risco de subestimação de esforço e explique por quê
4. Aponte entregáveis que geralmente são esquecidos em projetos similares e que deveriam estar aqui

Formato: estrutura indentada com tabela de estimativas ao final.

📋 Prompt F-05 — Definição de critérios de sucesso e métricas do projeto

Contexto: Projeto [nome/descrição]. Objetivo declarado pelo patrocinador: [objetivo]. O que o cliente disse que precisa: [necessidade declarada]. O que está implícito mas não foi dito: [sua percepção do que realmente importa].

Tarefa: Ajude a definir critérios de sucesso claros e mensuráveis:
1. Critérios de aceite do projeto — como saberemos que o projeto foi entregue com sucesso? (mensuráveis, verificáveis)
2. KPIs de acompanhamento durante o projeto — o que medir semanalmente/mensalmente
3. Critérios de sucesso de negócio — o que o cliente vai perceber como valor 6 meses depois da entrega
4. O que configuraria fracasso parcial vs. fracasso total
5. Como alinhar com o patrocinador antes de começar (perguntas para validar os critérios)

Formato: Tabela com critério | como medir | responsável | frequência.

📋 Prompt F-06 — Plano de comunicação do projeto

Contexto: Projeto [nome]. Duração: [X semanas/meses]. Stakeholders: [liste papéis]. Ferramentas disponíveis: [email | Teams | Slack | Jira | Confluence | outro].

Tarefa: Crie o plano de comunicação do projeto:
1. Tabela completa: Audiência | Tipo de comunicação | Conteúdo | Canal | Frequência | Responsável | Formato
2. Cadência de reuniões: quais reuniões existem, com quem, com qual objetivo e duração
3. Protocolo de escalada: como e quando escalar problemas (nível 1 | 2 | 3 com critérios)
4. Regras de comunicação da equipe (o que vai para e-mail vs. chat vs. reunião)
5. Como comunicar más notícias e mudanças de escopo (protocolo específico)

Inclua os templates de mensagem para as comunicações mais frequentes.

📋 Prompt F-07 — Geração de perguntas para descoberta de requisitos com cliente

Contexto: Tenho uma reunião de discovery com [cargo do interlocutor] do cliente [setor]. O projeto é sobre [tema]. O que já sei: [o que já foi levantado]. O que ainda preciso entender: [lacunas].

Tarefa: Gere o roteiro de perguntas para a reunião de discovery organizado em:
1. Perguntas de contexto (entender o problema real, não o sintoma)
2. Perguntas de impacto (entender o custo de não resolver)
3. Perguntas de solução atual (o que já tentaram, por que não funcionou)
4. Perguntas de critério de sucesso (como saberão que deu certo)
5. Perguntas de restrições (prazo, orçamento, limitações técnicas ou políticas)
6. Perguntas sobre stakeholders (quem mais será afetado, quem pode travar)

Para cada pergunta: por que esta pergunta importa | o que fazer com a resposta | pergunta de aprofundamento se a resposta for vaga.

📈 Série G — Gestão e Retrospectiva (prompts G-01 a G-07)

Recomendação: Claude com MD de contexto — cole o arquivo MD do projeto antes de usar estes prompts

📈 Prompt G-01 — Relatório de status semanal estruturado

[ANTES DESTE PROMPT: cole o arquivo MD do projeto no início do chat]

Contexto: Preciso do relatório de status da semana [número/data]. Aqui estão as notas da semana:
[COLE NOTAS, UPDATES DO JIRA/TRELLO, ANOTAÇÕES DE REUNIÃO]

Tarefa: Gere o relatório de status semanal no formato:
- Semáforo geral: 🟢 Verde | 🟡 Amarelo | 🔴 Vermelho + justificativa em 1 frase
- Resumo executivo: 3–4 frases do que aconteceu esta semana
- Conquistas da semana (bullets)
- Próxima semana: o que está planejado (bullets com responsável)
- Riscos e impedimentos ativos: descrição | impacto | ação em andamento
- Decisões necessárias: o que precisa de resposta de quem

Formato: pronto para copiar e enviar para stakeholders.

📈 Prompt G-02 — Facilitação de retrospectiva (análise antes da reunião)

Contexto: Estou facilitando uma retrospectiva de [sprint | fase | projeto]. A equipe tem [número] pessoas. Principais temas que surgiram no período: [liste os eventos significativos — positivos e negativos].

Dados do período:
[COLE MÉTRICAS: velocity, bugs, atrasos, feedbacks de cliente, o que tiver]

Tarefa: Ajude a preparar a retrospectiva:
1. Análise dos dados: o que os números sugerem sobre o que funcionou e o que não funcionou?
2. Hipóteses sobre causas raiz dos principais problemas (para explorar na retrospectiva, não afirmar)
3. 5 perguntas de reflexão para a equipe (formuladas para gerar conversa, não respostas sim/não)
4. Estrutura sugerida para a reunião: tempo | atividade | objetivo
5. Riscos de facilitação: o que pode travar a conversa e como prevenir

📈 Prompt G-03 — Análise de desvio de cronograma ou orçamento

Contexto: O projeto [nome] está com desvio de [X% no prazo | X% no orçamento | ambos]. O cronograma/orçamento original era [original]. O atual é [atual]. As causas aparentes são [o que a equipe está dizendo].

Aqui estão os dados de progresso:
[COLE DADOS DE PROGRESSO, TIMESHEETS, RELATÓRIOS DE STATUS ANTERIORES]

Tarefa: Analise o desvio e entregue:
1. Causa raiz vs. sintoma: o que está sendo dito vs. o que os dados sugerem
2. Projeção: se nada mudar, onde o projeto vai terminar (prazo e custo)
3. Opções de recuperação com trade-offs: Opção | Impacto no prazo | Impacto no custo | Impacto no escopo | Risco
4. Recomendação: qual opção e por quê
5. Como comunicar o desvio para o patrocinador de forma transparente e orientada a solução

📈 Prompt G-04 — Gestão de mudança de escopo (change request)

Contexto: O cliente está pedindo uma mudança de escopo. O pedido é: [descreva o pedido]. O escopo atual do projeto é: [escopo atual]. Impacto preliminar que identifico: [o que você já avaliou].

Tarefa: Ajude a estruturar a análise e resposta à mudança de escopo:
1. Análise de impacto: prazo (+ quantos dias), custo (+ quanto), riscos (quais novos riscos surgem), qualidade (algo sofre para acomodar?)
2. O que do escopo atual precisaria ser removido ou adiado para acomodar esta mudança sem impacto (se a resposta for "nada", documente isso)
3. Template de change request formal: Solicitante | Data | Descrição | Justificativa | Análise de impacto | Recomendação | Aprovação
4. Como comunicar ao cliente: aprovando com impacto | aprovando parcialmente | recusando com alternativa

📈 Prompt G-05 — Encerramento de projeto: relatório de fechamento

Contexto: O projeto [nome] está sendo encerrado. Preciso do relatório de encerramento para [arquivo | cliente | liderança | auditoria].

Aqui estão os dados do projeto:
[COLE: ESCOPO ORIGINAL vs. ENTREGUE, CRONOGRAMA ORIGINAL vs. REAL, ORÇAMENTO ORIGINAL vs. GASTO, FEEDBACKS, PROBLEMAS PRINCIPAIS]

Tarefa: Gere o relatório de encerramento do projeto com:
1. Sumário executivo: o que foi entregue, o que não foi, por quê
2. Performance do projeto: prazo | orçamento | escopo | qualidade — com variância e justificativa
3. Realizações principais (o que deve ser destacado)
4. Problemas e como foram resolvidos
5. Lições aprendidas (operacionais, de gestão, de relacionamento com cliente)
6. Recomendações para a organização (o que mudar nos próximos projetos)
7. Status de encerramento: documentação entregue | acessos revogados | contratos encerrados | aprovações obtidas

📈 Prompt G-06 — Análise de saúde do projeto em andamento

[ANTES DESTE PROMPT: cole o arquivo MD do projeto no início do chat]

Contexto: Preciso de uma análise honesta da saúde atual do projeto [nome]. Estamos na [fase | semana | sprint número]. Aqui estão os dados disponíveis:
[COLE DADOS: VELOCITY, BURN RATE, RISCOS ATIVOS, STATUS DAS ENTREGAS, FEEDBACKS]

Tarefa: Faça uma análise de saúde estruturada avaliando 6 dimensões:
1. Escopo — está claro, estável e gerenciável?
2. Cronograma — estamos no ritmo para entregar no prazo?
3. Orçamento — o burn rate está compatível com o progresso?
4. Equipe — a equipe tem capacidade, motivação e direção clara?
5. Stakeholders — os patrocinadores e cliente estão engajados e alinhados?
6. Riscos — os riscos mais críticos estão sendo monitorados e mitigados?

Para cada dimensão: 🟢🟡🔴 com justificativa e ação recomendada se não-verde.

📈 Prompt G-07 — Preparação de reunião de comitê de governança ou steering committee

Contexto: Tenho uma reunião de steering committee / comitê de governança do projeto [nome] em [data]. Os participantes são [liste cargos]. A duração é [X minutos]. Preciso de aprovações/decisões sobre [liste o que precisa ser decidido].

Aqui está o status atual do projeto:
[COLE STATUS ATUAL, RISCOS, DESVIOS, PEDIDOS DE MUDANÇA PENDENTES]

Tarefa: Prepare o material para a reunião:
1. Pauta estruturada com tempo por item
2. Pré-leitura: o que os participantes precisam saber antes de entrar na sala (máximo 1 página)
3. Os 3 pontos mais críticos que precisam de decisão — com contexto e opções claras para cada
4. Perguntas difíceis que provavelmente serão feitas — com respostas preparadas
5. O que você não vai falar na reunião mas precisa estar pronto para falar se perguntarem
6. Próximos passos que você vai propor ao final da reunião

3 arquivos MD completos para gestão de projetos: SAFe, Scrum e PMI

Cole qualquer um destes arquivos no início de um chat com Claude, ChatGPT ou Gemini antes de usar os prompts das Séries F e G. A IA vai usar o framework como referência para todas as perguntas sobre o projeto naquela sessão.

Para usar como arquivo de projeto real: substitua os campos entre [colchetes] pelas informações específicas do seu projeto, salve como .md e cole quando necessário.

📘 Arquivo MD 1: SAFe (Scaled Agile Framework) — Template de Projeto

# Projeto: [NOME DO PROJETO]
**Framework:** SAFe 6.0 (Scaled Agile Framework)
**ART (Agile Release Train):** [Nome da ART]
**Program Increment (PI):** PI [número] — [data início] a [data fim]
**Lean-Agile Lead:** [Nome]
**Data de criação:** [AAAA-MM-DD]
**Última atualização:** [AAAA-MM-DD]

---

## 1. Visão do Produto (Product Vision)

**Declaração de visão:**
> Para [cliente/usuário], que [problema ou necessidade], o [nome do produto/solução] é um [categoria do produto] que [principal benefício]. Diferente de [alternativa atual], nosso produto [diferencial principal].

**Métricas de resultado esperado:**
- [ ] [Métrica 1]: de [baseline] para [meta] até [data]
- [ ] [Métrica 2]: de [baseline] para [meta] até [data]
- [ ] [Métrica 3]: de [baseline] para [meta] até [data]

---

## 2. PI Objectives (Objetivos do Program Increment)

### Objetivos de Negócio (Business Objectives)
| # | Objetivo | Valor de Negócio (1-10) | Time Responsável | Committed/Uncommitted |
|---|----------|------------------------|------------------|----------------------|
| 1 | [Objetivo] | [valor] | [time] | Committed |
| 2 | [Objetivo] | [valor] | [time] | Committed |
| 3 | [Objetivo] | [valor] | [time] | Uncommitted |

**Stretch Objectives:**
- [ ] [Objetivo stretch 1]
- [ ] [Objetivo stretch 2]

---

## 3. ART Backlog (Epics e Features)

### Epics Ativos
| Epic ID | Título | Hipótese de negócio | Estado | Lead Time estimado |
|---------|--------|--------------------|---------|--------------------|
| E-001 | [Título] | [Hipótese] | Funnel/Analyzing/Implementing/Done | [prazo] |
| E-002 | [Título] | [Hipótese] | [estado] | [prazo] |

### Features do PI Atual
| Feature ID | Título | Epic | Story Points | Time | Estado |
|------------|--------|------|-------------|------|--------|
| F-001 | [Título] | E-001 | [pontos] | [time] | To Do/In Progress/Done |
| F-002 | [Título] | E-001 | [pontos] | [time] | [estado] |
| F-003 | [Título] | E-002 | [pontos] | [time] | [estado] |

---

## 4. Times e Papéis

### Papéis da ART
| Papel | Responsável | Contato |
|-------|-------------|---------|
| Release Train Engineer (RTE) | [nome] | [email/canal] |
| Product Management | [nome] | [email/canal] |
| System Architect | [nome] | [email/canal] |
| Business Owners | [nomes] | [email/canal] |

### Times Ágeis
| Time | Scrum Master | Product Owner | Integrantes | Capacidade (SP/Sprint) |
|------|-------------|---------------|-------------|----------------------|
| [Time 1] | [nome] | [nome] | [nomes] | [capacidade] |
| [Time 2] | [nome] | [nome] | [nomes] | [capacidade] |

---

## 5. Cadência SAFe

| Cerimônia | Frequência | Duração | Participantes | Data/Horário |
|-----------|------------|---------|---------------|-------------|
| Sprint Planning | Quinzenal | 4h | Time completo | [dia/hora] |
| Daily Standup | Diário | 15min | Time | [hora] |
| Sprint Review | Quinzenal | 2h | Time + stakeholders | [dia/hora] |
| Sprint Retrospective | Quinzenal | 1.5h | Time | [dia/hora] |
| PI Planning | A cada 10 semanas | 2 dias | ART completa | [data] |
| ART Sync | Semanal | 30min | RTE + SMs + POs | [dia/hora] |
| System Demo | Quinzenal | 1h | ART + stakeholders | [dia/hora] |
| Inspect & Adapt | Fim de PI | Meio dia | ART completa | [data] |

---

## 6. Riscos e Impedimentos (ROAM)

| ID | Risco/Impedimento | Tipo (Risk/Issue) | ROAM | Responsável | Status |
|----|-------------------|-------------------|------|-------------|--------|
| R-001 | [Descrição] | Risk | Resolved/Owned/Accepted/Mitigated | [nome] | [status] |
| R-002 | [Descrição] | Issue | [ROAM] | [nome] | [status] |

**Legenda ROAM:**
- **R**esolved: risco resolvido
- **O**wned: alguém se responsabilizou por resolver
- **A**ccepted: aceito, sem ação necessária
- **M**itigated: mitigado com plano de contingência

---

## 7. Program Board — Dependências entre Times

| Feature | Time Origem | Time Destino | Sprint de Necessidade | Status |
|---------|------------|-------------|----------------------|--------|
| [Feature] | [Time A] | [Time B] | Sprint [número] | On track/At risk/Blocked |

---

## 8. Métricas e KPIs do PI

| Métrica | Baseline | Meta do PI | Atual | Tendência |
|---------|----------|-----------|-------|-----------|
| Velocity média (SP/sprint) | [valor] | [meta] | [atual] | ↑↓→ |
| Predictability (% PI objectives) | [valor] | 80%+ | [atual] | ↑↓→ |
| Qualidade (% bugs em produção) | [valor] | [meta] | [atual] | ↑↓→ |
| Flow efficiency | [valor] | [meta] | [atual] | ↑↓→ |

---

## 9. Definition of Done (DoD)

### Feature Done
- [ ] Todas as histórias do épico aceitas pelo PO
- [ ] Testes de integração passando
- [ ] Documentação de usuário atualizada
- [ ] Demo realizada no System Demo
- [ ] Aprovação do Product Management

### Story Done
- [ ] Critérios de aceite verificados pelo PO
- [ ] Código revisado por pair/code review
- [ ] Testes unitários escritos e passando
- [ ] Integrado ao branch principal
- [ ] Sem bugs bloqueadores

---

## 10. Glossário SAFe do Projeto

| Termo | Definição no Contexto deste Projeto |
|-------|-------------------------------------|
| [Termo de domínio] | [Definição específica] |
| [Acrônimo] | [O que significa neste projeto] |

---

## 11. Links e Recursos

| Recurso | URL/Local |
|---------|-----------|
| Jira/Backlog | [link] |
| Confluence/Wiki | [link] |
| Repositório | [link] |
| Calendário de cerimônias | [link] |
| Contato do RTE | [email/canal] |

---
*Última atualização: [data] por [nome]*

🟧 Arquivo MD 2: Scrum — Template de Projeto

# Projeto: [NOME DO PROJETO]
**Framework:** Scrum (Scrum Guide 2020)
**Time:** [Nome do time]
**Sprint atual:** Sprint [número] — [data início] a [data fim]
**Product Owner:** [Nome]
**Scrum Master:** [Nome]
**Data de criação:** [AAAA-MM-DD]
**Última atualização:** [AAAA-MM-DD]

---

## 1. Objetivo do Produto (Product Goal)

> [Declaração do estado futuro do produto que serve como alvo de longo prazo para o Scrum Team. Deve ser alcançável, significativo e verificável.]

**Critério de conclusão do Product Goal:**
[Como saberemos que o Product Goal foi atingido?]

---

## 2. Product Backlog

### Epics
| Epic ID | Título | Prioridade (MoSCoW) | Estimativa | Estado |
|---------|--------|--------------------|-----------|---------| 
| EP-001 | [Título] | Must Have | [pontos] | To Do |
| EP-002 | [Título] | Should Have | [pontos] | In Progress |
| EP-003 | [Título] | Could Have | [pontos] | To Do |

### User Stories (top 15 priorizadas)
| ID | Como... | Quero... | Para que... | Story Points | Epic | Estado |
|----|---------|----------|-------------|-------------|------|--------|
| US-001 | [perfil] | [ação] | [benefício] | [pontos] | EP-001 | To Do |
| US-002 | [perfil] | [ação] | [benefício] | [pontos] | EP-001 | To Do |
| US-003 | [perfil] | [ação] | [benefício] | [pontos] | EP-002 | In Progress |

---

## 3. Sprint Backlog (Sprint Atual)

**Sprint Goal:**
> [O Sprint Goal é o único objetivo do Sprint. Cria coerência e foco, encorajando o Scrum Team a trabalhar junto em vez de em iniciativas separadas.]

| ID | User Story | Tasks | Responsável | Status | Story Points |
|----|-----------|-------|-------------|--------|-------------|
| US-003 | [título] | [ ] Task 1 / [ ] Task 2 | [dev] | In Progress | [pts] |
| US-007 | [título] | [ ] Task 1 / [ ] Task 2 | [dev] | To Do | [pts] |
| US-012 | [título] | [ ] Task 1 / [ ] Task 2 | [dev] | To Do | [pts] |

**Capacidade do time neste sprint:**
- Total de story points comprometidos: [total]
- Velocidade média dos últimos 3 sprints: [média]
- Desvio: [+/- X pontos]

---

## 4. Time Scrum

| Papel | Nome | Disponibilidade | Responsabilidades principais |
|-------|------|----------------|------------------------------|
| Product Owner | [nome] | [%] | Backlog, priorização, aceite |
| Scrum Master | [nome] | [%] | Facilitar, remover impedimentos, coaching |
| Developer | [nome] | [%] | [especialidade] |
| Developer | [nome] | [%] | [especialidade] |
| Developer | [nome] | [%] | [especialidade] |

---

## 5. Cerimônias Scrum

| Cerimônia | Quando | Duração máx. | Objetivo | Facilitador |
|-----------|--------|-------------|---------|-------------|
| Sprint Planning | Primeiro dia do sprint | [X]h | Definir Sprint Goal e Sprint Backlog | Scrum Master |
| Daily Scrum | Diário, mesmo horário | 15min | Inspeção do progresso, adaptação | Developers |
| Sprint Review | Penúltimo dia do sprint | [X]h | Inspecionar o Incremento, adaptar o Backlog | Product Owner |
| Sprint Retrospective | Último dia do sprint | [X]h | Melhorar qualidade e efetividade | Scrum Master |

**Horários fixos:**
- Daily: [hora] em [canal/sala]
- Sprint [início/fim]: todo [dia da semana]

---

## 6. Definition of Done (DoD)

O Incremento é considerado Done quando:
- [ ] Código escrito e revisado por pelo menos 1 desenvolvedor
- [ ] Testes unitários escritos com cobertura mínima de [X]%
- [ ] Testes de integração passando
- [ ] Sem bugs bloqueadores ou críticos não documentados
- [ ] Documentação técnica atualizada (se aplicável)
- [ ] Critérios de aceite da User Story verificados pelo PO
- [ ] Deploy em ambiente de [homologação/staging] realizado
- [ ] [Critério específico do projeto 1]
- [ ] [Critério específico do projeto 2]

---

## 7. Definition of Ready (DoR)

Uma User Story está pronta para entrar no Sprint quando:
- [ ] User Story escrita no formato "Como / Quero / Para que"
- [ ] Critérios de aceite definidos e mensuráveis
- [ ] Estimada em story points pelo time
- [ ] Dependências identificadas e resolvidas (ou com plano)
- [ ] Sem ambiguidades não resolvidas
- [ ] Aprovada pelo Product Owner

---

## 8. Impedimentos Ativos

| ID | Descrição | Impacto | Data de abertura | Responsável | Status |
|----|-----------|---------|-----------------|-------------|--------|
| IMP-001 | [Descrição] | [Alto/Médio/Baixo] | [data] | [Scrum Master] | Em andamento |

---

## 9. Métricas do Time

| Métrica | Sprint Atual | Média últimos 3 sprints | Meta |
|---------|-------------|------------------------|------|
| Velocity (SP entregues) | [atual] | [média] | [meta] |
| % Sprint Goal atingido | [%] | [%] | 100% |
| Bugs encontrados em produção | [nº] | [média] | 0 |
| Tempo médio de resolução de impedimento | [dias] | [média] | < 2 dias |

### Burndown do Sprint Atual
**Pontos restantes por dia:**
- Dia 1: [pontos] / Ideal: [pontos]
- Dia 2: [pontos] / Ideal: [pontos]
- [atualizar diariamente]

---

## 10. Retrospectiva — Histórico de Melhorias

| Sprint | O que funcionou | O que não funcionou | Ação de melhoria | Responsável | Status |
|--------|-----------------|---------------------|-----------------|-------------|--------|
| Sprint [n-1] | [bullet] | [bullet] | [ação] | [nome] | [feito/em andamento] |
| Sprint [n-2] | [bullet] | [bullet] | [ação] | [nome] | [feito/em andamento] |

---

## 11. Riscos Ativos

| ID | Risco | Probabilidade | Impacto | Resposta | Responsável |
|----|-------|--------------|---------|---------|-------------|
| R-001 | [Descrição] | Alta/Média/Baixa | Alto/Médio/Baixo | [Estratégia] | [nome] |

---

## 12. Links e Recursos

| Recurso | URL/Local |
|---------|-----------|
| Jira/Trello/Linear | [link] |
| Repositório | [link] |
| Documentação | [link] |
| Canal da equipe | [canal Slack/Teams] |
| Ambiente de homologação | [link] |

---
*Última atualização: [data] por [nome]*

🟪 Arquivo MD 3: PMI / PMBOK — Template de Projeto

# Projeto: [NOME DO PROJETO]
**Framework:** PMI / PMBOK 7ª Edição
**Gerente do Projeto:** [Nome]
**Patrocinador:** [Nome e cargo]
**Organização:** [Nome da organização]
**Data de início:** [AAAA-MM-DD]
**Data de término planejada:** [AAAA-MM-DD]
**Orçamento aprovado:** [R$/US$]
**Última atualização:** [AAAA-MM-DD]
**Versão do documento:** [1.0]

---

## 1. Termo de Abertura do Projeto (Project Charter)

### 1.1 Justificativa do Projeto
[Por que este projeto existe? Qual problema de negócio resolve ou qual oportunidade aproveita?]

### 1.2 Objetivo do Projeto
[Declaração SMART: Específico, Mensurável, Alcançável, Relevante, Temporal]

### 1.3 Descrição de Alto Nível
[O que o projeto vai entregar? Descrição em 3–5 frases.]

### 1.4 Benefícios Esperados
| Benefício | Tipo (Quantitativo/Qualitativo) | Métrica | Meta | Prazo para realização |
|-----------|--------------------------------|---------|------|-----------------------|
| [Benefício 1] | Quantitativo | [KPI] | [valor] | [prazo pós-entrega] |
| [Benefício 2] | Qualitativo | [indicador] | [descrição] | [prazo] |

### 1.5 Marcos de Alto Nível
| Marco | Entregável | Data planejada | Critério de aceite |
|-------|-----------|---------------|-------------------|
| Kickoff | Reunião realizada + ata | [data] | Participação de todos os stakeholders chave |
| [Marco 1] | [Entregável] | [data] | [critério] |
| [Marco 2] | [Entregável] | [data] | [critério] |
| Encerramento | Relatório final aceito | [data] | Assinatura do patrocinador |

### 1.6 Restrições e Premissas
**Restrições:**
- Prazo: [data final não pode ser alterada por:]
- Orçamento: [limite e motivo]
- Recursos: [limitações de recursos]
- Tecnologia: [restrições técnicas]

**Premissas:**
- [O que estamos assumindo como verdadeiro e que, se falso, impacta o projeto]
- [Premissa 2]

### 1.7 O que está fora do escopo (Out of Scope)
- [ ] [Item excluído explicitamente 1]
- [ ] [Item excluído explicitamente 2]

---

## 2. Registro de Stakeholders

| ID | Nome | Cargo | Organização | Interesse no Projeto | Influência (A/M/B) | Engajamento Atual | Estratégia |
|----|------|-------|-------------|---------------------|--------------------|-------------------|-----------|
| S-01 | [nome] | [cargo] | [org] | [interesse] | Alta | Favorável | Manter engajado |
| S-02 | [nome] | [cargo] | [org] | [interesse] | Alta | Neutro | Aumentar suporte |
| S-03 | [nome] | [cargo] | [org] | [interesse] | Média | Resistente | Gerenciar ativamente |

---

## 3. Escopo do Projeto

### 3.1 Estrutura Analítica do Projeto (EAP/WBS)

```
1.0 [NOME DO PROJETO]
  1.1 Gerenciamento do Projeto
    1.1.1 Termo de Abertura
    1.1.2 Plano do Projeto
    1.1.3 Reuniões de Status
    1.1.4 Relatório de Encerramento
  1.2 [Fase/Entregável Principal 1]
    1.2.1 [Sub-entregável]
    1.2.2 [Sub-entregável]
  1.3 [Fase/Entregável Principal 2]
    1.3.1 [Sub-entregável]
    1.3.2 [Sub-entregável]
  1.4 [Fase/Entregável Principal 3]
    1.4.1 [Sub-entregável]
    1.4.2 [Sub-entregável]
```

### 3.2 Dicionário da EAP (entregáveis detalhados)
| Código WBS | Entregável | Descrição | Critério de aceite | Responsável | Esforço estimado |
|-----------|-----------|-----------|-------------------|-------------|-----------------|
| 1.2.1 | [nome] | [descrição] | [como aceitar] | [papel] | [horas/dias] |

---

## 4. Cronograma

### 4.1 Linha do Tempo de Marcos
```
[data]  ──── Kickoff
[data]  ──── [Marco 1: Entregável]
[data]  ──── [Marco 2: Entregável]
[data]  ──── [Marco 3: Entregável]
[data]  ──── Encerramento
```

### 4.2 Caminho Crítico
**Atividades no caminho crítico (sem folga):**
- [Atividade 1] → [Atividade 2] → [Atividade 3]

**Atividades com folga:**
| Atividade | Folga total | Impacto se atrasada |
|-----------|------------|---------------------|
| [atividade] | [X dias] | [impacto] |

---

## 5. Orçamento

| Categoria | Orçamento aprovado | Comprometido | Gasto real | % Utilizado | Previsão de término |
|-----------|-------------------|-------------|------------|-------------|---------------------|
| Recursos humanos internos | [valor] | [valor] | [valor] | [%] | [previsão] |
| Fornecedores / terceiros | [valor] | [valor] | [valor] | [%] | [previsão] |
| Infraestrutura / licenças | [valor] | [valor] | [valor] | [%] | [previsão] |
| Reserva de contingência (10%) | [valor] | [valor] | [valor] | [%] | [previsão] |
| **TOTAL** | **[total]** | **[total]** | **[total]** | **[%]** | **[previsão]** |

**Variação de custo (CV):** [valor e interpretação]
**Índice de performance de custo (CPI):** [valor — >1 é positivo]

---

## 6. Registro de Riscos

| ID | Categoria | Descrição do Risco | Probabilidade | Impacto | Exposição (P×I) | Estratégia | Resposta | Responsável | Status |
|----|-----------|-------------------|--------------|---------|----------------|-----------|---------|-------------|--------|
| R-001 | Técnico | [descrição] | Alta(3)/Média(2)/Baixa(1) | Alto(3)/Médio(2)/Baixo(1) | [P×I] | Mitigar | [ação] | [nome] | Aberto |
| R-002 | Cronograma | [descrição] | [prob] | [impacto] | [P×I] | Aceitar | [ação] | [nome] | Aberto |
| R-003 | Stakeholder | [descrição] | [prob] | [impacto] | [P×I] | Transferir | [ação] | [nome] | Fechado |

**Estratégias de resposta:**
- **Mitigar:** Reduzir probabilidade ou impacto
- **Transferir:** Passar o risco para terceiro (seguro, contrato)
- **Evitar:** Eliminar a causa do risco
- **Aceitar:** Aceitar as consequências (ativa: com plano de contingência | passiva: sem ação)

---

## 7. Registro de Problemas (Issue Log)

| ID | Descrição | Prioridade | Data de abertura | Responsável | Prazo de resolução | Status |
|----|-----------|-----------|-----------------|-------------|-------------------|--------|
| I-001 | [descrição] | Alta/Média/Baixa | [data] | [nome] | [data] | Em andamento |

---

## 8. Controle de Mudanças

### 8.1 Processo de Change Request
1. Solicitante identifica necessidade de mudança e preenche o formulário abaixo
2. Gerente do projeto analisa impacto em escopo, prazo e custo
3. Comitê de mudanças aprova ou rejeita (membros: [liste])
4. Se aprovada: atualizar plano do projeto, comunicar stakeholders, implementar
5. Registrar no log abaixo

### 8.2 Log de Mudanças
| CR# | Solicitante | Data | Descrição | Impacto (prazo/custo/escopo) | Decisão | Data decisão |
|-----|------------|------|-----------|------------------------------|---------|-------------|
| CR-001 | [nome] | [data] | [descrição] | +[X] dias / +R$[X] | Aprovado/Rejeitado | [data] |

---

## 9. Plano de Comunicações

| Audiência | Informação | Canal | Frequência | Formato | Responsável |
|-----------|-----------|-------|-----------|---------|-------------|
| Patrocinador | Status executivo | E-mail | Semanal | Dashboard 1 página | GP |
| Comitê Diretivo | Status + decisões | Reunião | Mensal | Apresentação | GP |
| Equipe do projeto | Progresso + tarefas | Stand-up | Diário | Conversa oral | GP |
| Stakeholders amplos | Marcos atingidos | E-mail | Por marco | Comunicado | GP |
| [Outros] | [info] | [canal] | [frequência] | [formato] | [responsável] |

---

## 10. Plano de Qualidade

### 10.1 Padrões de Qualidade Aplicáveis
- [Norma/padrão 1 e como se aplica a este projeto]
- [Norma/padrão 2]

### 10.2 Critérios de Aceite dos Principais Entregáveis
| Entregável | Critério de aceite | Como verificar | Responsável pela verificação |
|-----------|-------------------|---------------|------------------------------|
| [Entregável 1] | [critério mensurável] | [como testar/verificar] | [papel] |
| [Entregável 2] | [critério] | [verificação] | [papel] |

### 10.3 Revisões de Qualidade Planejadas
| Revisão | Quando | Participantes | O que verificar |
|---------|--------|---------------|-----------------|
| [Revisão 1] | [data/marco] | [papéis] | [o que] |

---

## 11. Encerramento do Projeto

### 11.1 Checklist de Encerramento
- [ ] Todos os entregáveis aceitos formalmente pelo cliente/patrocinador
- [ ] Documentação técnica e de projeto arquivada
- [ ] Acessos de sistemas revogados para membros que saíram
- [ ] Contratos com fornecedores encerrados
- [ ] Lições aprendidas documentadas e arquivadas
- [ ] Relatório de encerramento aprovado pelo patrocinador
- [ ] Membros da equipe formalmente dispensados do projeto
- [ ] Recursos materiais devolvidos ou redistribuídos

### 11.2 Lições Aprendidas
| Categoria | Descrição | Impacto | Recomendação para projetos futuros |
|-----------|-----------|---------|-------------------------------------|
| [Técnico/Gestão/Stakeholder] | [o que aconteceu] | [impacto] | [recomendação] |

---

## 12. Glossário do Projeto

| Termo | Definição |
|-------|-----------|
| [Termo de negócio] | [Definição no contexto deste projeto] |
| [Acrônimo] | [Significado] |

---

## 13. Histórico de Revisões do Documento

| Versão | Data | Autor | Alterações |
|--------|------|-------|-----------|
| 1.0 | [data] | [nome] | Criação inicial |
| 1.1 | [data] | [nome] | [o que mudou] |

---
*Documento controlado — última aprovação: [nome] em [data]*

👉 Amanda aconselha:

Comandos de atalho: o que digitar quando o resultado não saiu certo

O que a IA não consegue fazer sozinha em trabalho de consultoria

A IA mais poderosa do mundo ainda precisa de você para fornecer o contexto que ninguém mais tem — o histórico do relacionamento, a dinâmica da equipe, o que o cliente disse mas não está no documento. Os prompts desta lista são as perguntas certas. Você é quem tem as informações certas. O resultado da combinação dos dois é o que nenhum dos dois consegue sozinho.

👀 Erros fatais ao usar IA em trabalho de consultoria (90% cometem o erro #1)

• Erro 1 — “Prompt sem contexto de audiência”: Enviar “melhore este e-mail” sem dizer para quem é o e-mail, qual é o objetivo e qual é o tom desejado. A IA vai melhorar para o destinatário médio estatístico — que não é o seu destinatário. Correção: Sempre inclua: “O destinatário é [cargo]. O objetivo é [objetivo]. O tom deve ser [tom].”
• Erro 2 — “Análise sem documento”: Pedir análise de um contrato/proposta/documento sem cole-lo no chat. A IA vai inventar um documento genérico da categoria. Correção: Cole o documento completo. Se for muito longo, divida em partes e peça análise por seção.
• Erro 3 — “Aceitar a primeira versão sem verificar”: Usar direto o resultado da IA sem checar se ele corresponde à realidade do projeto. A IA pode inventar dados, citar trechos de documentos que não existem ou fazer afirmações incorretas com muita confiança. Correção: Para análises críticas, peça que a IA cite os trechos exatos dos documentos. Cheque 2–3 afirmações críticas antes de usar.
• Erro 4 — “Um chat para tudo”: Usar o mesmo chat por semanas para projetos diferentes ou para múltiplos tópicos. A janela de contexto tem limite e a qualidade das respostas degrada com conversas longas. Correção: Um chat por tópico. Use os arquivos MD desta lista para transferir o contexto do projeto entre sessões.
• Erro 5 — “Não revelar informação sensível ao problema”: Omitir o contexto político, o histórico difícil ou a restrição real “para não poluir” o prompt. A IA vai dar a resposta ideal para o mundo sem esse contexto — que é um mundo que não existe. Correção: Inclua o contexto complicado. A IA é confidencial, não vai vazar. E a análise com contexto real é infinitamente mais útil do que a análise sem ele.

Prompt fraco vs prompt forte — a diferença que define a qualidade do resultado

A diferença não está na ferramenta. Está no contexto que você fornece e na especificidade do que você pede.

Exemplo 01 — E-mail para cliente difícil

Deixe este e-mail mais amigável.

Contexto: sou gerente de projetos. O destinatário é o diretor de TI do cliente, que está frustrado com atrasos. O objetivo é reconhecer o problema sem admitir responsabilidade total, manter o relacionamento e propor uma solução concreta. Tom: profissional e empático, não defensivo. Reescreva o e-mail abaixo neste tom: [e-mail]

Exemplo 02 — Análise de proposta

Analise esta proposta e diga o que está faltando.

Aqui está o RFP [cole RFP] e aqui está nossa proposta [cole proposta]. Verifique se a proposta atende cada requisito do RFP. Entregue uma tabela: Requisito do RFP | Coberto? | Onde | Lacuna. Destaque os 3 maiores gaps que precisam ser corrigidos antes do envio de amanhã.

Exemplo 03 — Debug de código

Estou com um erro no meu código Python. Onde está o erro?

Python 3.11, pandas 2.1, ambiente: local Windows. Erro: "KeyError: 'client_id'" ao rodar df.groupby('client_id'). O dataframe vem de um CSV. Código: [cole]. O que acontece: funciona com um arquivo mas falha com outro. O que espero: groupby executar sem erro.

Exemplo 04 — Início de projeto com checklist

Estou começando um novo projeto. Me dê uma lista de verificação.

[Cole o arquivo MD do Scrum desta lista] Aqui está o arquivo de projeto: [cole o MD do projeto preenchido]. Gere um checklist de kickoff baseado no Scrum Guide e no contexto do projeto. Marque cada item como Crítico/Importante/Recomendado. Inclua responsável (papel) para cada item crítico.

Exemplo 05 — Apresentação que não está funcionando

Eu preciso fazer uma apresentação sobre transformação digital. O que não está funcionando na abordagem atual?

Apresentação sobre transformação digital para o CFO e os 3 VPs financeiros. Objetivo: aprovação de R$2M de orçamento. Tempo: 20 min. Aqui está o conteúdo slide por slide: [cole]. O público se importa principalmente com ROI e risco. O que não está funcionando na abordagem atual para ESTE público e objetivo?

Além dos 3 modelos principais: quando usar cada ferramenta

Glossário rápido: termos técnicos deste guia

Conclusão: a IA não substitui o consultor — ela multiplica o que o consultor já é 🙌

Um profissional mediano com IA continua sendo mediano — só mais rápido. Um profissional de alto nível com IA consegue cobrir mais projetos, analisar mais documentos, preparar apresentações mais sólidas e iniciar projetos mais bem estruturados do que seria humanamente possível sem a ferramenta. A diferença não está em ter acesso à IA — 90% dos profissionais têm. Está em saber fornecer o contexto certo, fazer a pergunta certa e checar o resultado com o olho crítico que só vem da experiência real.

Os 49 prompts desta lista economizam entre 3 e 6 horas por semana para quem trabalha com análise de documentos, comunicação profissional e gestão de projetos. Os 3 arquivos MD eliminam o trabalho de criar estrutura de projeto do zero — que em organizações sem template padronizado pode levar dias. Juntos, representam o conjunto mínimo para trabalhar com IA de forma profissional, não experimental.

O próximo passo é simples: escolha um prompt desta lista para uma tarefa que você tem hoje. Cole o contexto real, substitua os campos, envie. Compare o resultado com o que você teria produzido sozinho na mesma tarefa. Faça isso por uma semana. Depois decida quais das ferramentas valem o investimento mensal para o seu perfil específico.

A diferença entre usar IA como curiosidade e usar IA como vantagem competitiva é basicamente esta: um profissional abre a ferramenta quando lembra, sem estrutura, sem contexto, e aceita o resultado médio que recebe. O outro mantém os arquivos de contexto atualizados, abre a ferramenta como parte do fluxo de trabalho, e usa os resultados como ponto de partida para o trabalho de alto valor que nenhuma IA vai fazer por ele tão cedo. Qual dos dois prompts desta lista você vai usar agora?