👨💻 Revisão de PR
O caso de maior valor por hora investida em time de engenharia. Setup em 1h, ROI já na semana 1.
INSTRUCTIONS:
Papel: Revisor técnico backend (Node.js / TypeScript).
Objetivo: Identificar bugs, falhas de segurança e melhorias claras
no PR colado. Não mudar arquitetura, não comentar estilo.
Formato: Lista [SEVERIDADE] arquivo:linha — descrição + sugestão.
Evitar: "talvez", "considere". Seja afirmativo ou se cale.
KNOWLEDGE:
- style-guide.md (regras de código do time)
- security-checklist.md
- 3 PRs exemplares (o que esperar)⚠️ Armadilhas
- • Não jogar todo o repo no knowledge — escopo se perde
- • Evitar comentário estilístico (linter resolve)
- • Não confundir com refator amplo
✍️ Copy recorrente
Newsletter, posts, anúncios, descrições de produto. Brand voice persistente; onboarding novo escritor fica rápido.
📦 Pacote típico
- • Brand voice doc (tom, palavras a usar/evitar)
- • 5-10 copies exemplares (do que pegou)
- • Política de copy (claims permitidos, disclaimers obrigatórios)
- • Guia visual (se aplicável)
🎧 Atendimento a clientes
Tier 1 de suporte. Reduz tempo médio de resposta, libera atendente humano pra casos complexos.
🔍 Pesquisa em base própria
Q&A em corpus institucional (papers, relatórios, transcrições) sem precisar montar RAG custom. Setup em horas, ganho imediato.
💡 Dica de instructions
Em toda resposta, cite arquivo + seção + trecho relevante (1-2 linhas). Se a info não estiver no knowledge, diga "não encontrei no corpus".
📊 Análise mensal de KPIs
Mesmo formato de análise todo mês, comparando com histórico. Sobe relatório novo, ele compara com 12 meses anteriores.
Série histórica no knowledge
12-18 meses de KPIs em Markdown enxuto. Não suba dashboards bagunçados.
Formato fixo no instructions
"Análise em 4 seções: headline, variações vs mês anterior, vs ano anterior, hipóteses".
Iteração mensal curta
Sobe relatório, pede análise, ajusta hipóteses. Em 30 min, deck pronto.
📚 Conteúdo padronizado
Doc técnica, briefings, ATAs, especificações. Estrutura fixa garante que tudo de tipo X tenha as mesmas seções, independentemente do autor.
✓ Bom uso
- ✓ Doc técnica de feature
- ✓ Briefing de campanha
- ✓ ATA estruturada
- ✓ Spec de API
✗ Mau uso
- ✗ Conteúdo criativo (engessa)
- ✗ Brainstorm aberto
- ✗ Texto que pede voz pessoal
- ✗ Quando padrão muda toda semana
✅ Resumo do Módulo
Próximo módulo:
3.2 — Trabalho em equipe