MÓDULO 3.4 · CASES COMPLETOS · ~50 min

🎯 Cases de Co-work + Skills + Agendamento

3 cenários reais onde Claude opera na sua máquina. Cada caso com a tentativa que QUASE deu errado, regras de chão que destravaram, skill final em markdown copia-e-cola e métricas honestas.

⚠ Atenção redobrada no N3. Aqui Claude APAGA, MOVE, EDITA arquivos seus. Cada case mostra o quase-acidente real e a regra de chão que evitou. Pula isso = você vai aprender do jeito ruim.

CASE 1

📂 Organizando 3 anos de Downloads (e quase apagando um contrato)

Cenário

Letícia, contadora autônoma, 38, atende 22 clientes PJ. Pasta ~/Downloads tem 4.847 arquivos: contratos, notas fiscais, capturas de tela, .zip de fornecedores, prints aleatórios. Procura "contrato Cliente X 2024" leva 15 minutos. Sabe que dá pra automatizar mas tem medo de Claude apagar coisa importante.

Recursos: co-work ativado, pasta autorizada (só Downloads), modelos de nomenclatura preferidos.

❌ Primeira tentativa — o quase-desastre

Organiza minha pasta de Downloads. Põe arquivo igual em pasta com nome do tipo. Apaga duplicados.

O que aconteceu: Claude começou. Criou pastas /pdf, /docx, /xlsx, /img, /zip. Movendo arquivos. 15 minutos depois Letícia notou: um arquivo chamado "contrato.pdf" foi pra /pdf. Outro "contrato.pdf" (de cliente DIFERENTE, ano diferente) também foi pra /pdf — Claude considerou duplicado pelo nome e APAGOU um.

Letícia teve sorte: notou rápido. Recuperou pela Lixeira. Mas o susto foi real.

Por que QUASE foi catástrofe:

• Sem dry-run primeiro — Claude executou sem mostrar plano
• "Apaga duplicados" sem critério (nome? hash? tamanho?) — Claude defaultou pra nome
• Sem backup automático antes de operação destrutiva
• Sem log do que estava fazendo — só foi visível depois que ela abriu pra ver

✅ Skill final com 5 regras de chão

Letícia transformou a aprendizagem em skill reutilizável. Salva em ~/.claude/skills/organizar-downloads.md:

--- name: organizar-downloads description: Organiza ~/Downloads em pastas por categoria. SEMPRE com dry-run e backup. --- # Regras de chão NÃO-NEGOCIÁVEIS 1. **Nunca apagar.** Mover, sim. Apagar, jamais. Eu apago manualmente depois de revisar. 2. **Dry-run primeiro SEMPRE.** Antes de mover qualquer coisa, mostre plano em formato: - "Vou mover X arquivos pra /pasta-Y" - "Vou detectar Z prováveis duplicados (mas não vou apagar — vou mover pra /possiveis-duplicados pra eu revisar)" E espere meu OK explícito. 3. **Backup antes:** crie ~/Downloads/_backup_ANTES_organizacao_AAAA-MM-DD_HHMM/ e copie 100% do conteúdo atual pra lá ANTES de qualquer movimentação. Sim, mesmo que dobre o espaço temporariamente. 4. **Categorias baseadas em CONTEÚDO, não só extensão:** - "contrato*" + .pdf → /contratos/AAAA/ - "NF*" ou "nota_fiscal*" + .pdf → /notas_fiscais/AAAA-MM/ - Imagem .png/.jpg → /imagens/AAAA-MM/ - Outros .pdf → /pdf_revisar/ - .zip → /zips_revisar/ - .docx genérico → /documentos/AAAA-MM/ 5. **Log obrigatório:** ao final, gerar /Downloads/_log_organizacao_AAAA-MM-DD.md com: - Quantos arquivos foram movidos por categoria - Lista completa de "possíveis duplicados" (mesmo nome, locais diferentes) pra eu auditar - Erros encontrados (arquivo corrompido, sem permissão, etc.) - Tamanho antes/depois # Como invocar "Roda a skill organizar-downloads. Faça dry-run primeiro." # Se eu disser "aprova e executa" - Cria backup - Move conforme plano - Gera log - ME PERGUNTE antes de tocar em qualquer "possível duplicado"

📤 Como ficou a execução real

Dry-run output:

PLANO (sem executar ainda):

- Backup: 4.847 arquivos → ~/Downloads/_backup_ANTES_2026-05-13_2240/
- /contratos/2024/ → 287 arquivos
- /contratos/2025/ → 412 arquivos
- /contratos/2026/ → 156 arquivos
- /notas_fiscais/2024-* → 1.243 arquivos
- /notas_fiscais/2025-* → 1.876 arquivos
- /imagens/* → 423 arquivos
- /pdf_revisar/ → 187 arquivos
- /zips_revisar/ → 89 arquivos
- /documentos/* → 174 arquivos

⚠ 67 prováveis duplicados detectados (mesmo nome em locais diferentes). Vou MOVER pra /possiveis_duplicados/ — você revisa caso a caso.

⚠ 2 arquivos corrompidos (não consegui ler). Listados no log.

Aprova?

Letícia aprovou. 8 minutos depois Claude entregou o log. Nada foi apagado. Os 67 "duplicados" ela revisou em 20 min — 41 eram realmente duplicados (apagou), 26 eram homônimos de clientes diferentes (preservou).

🔀 Variações testadas

A — Pasta de fotos do celular: mesma estrutura, mas categoria por EXIF (data, GPS), não por nome. Detecta "selfies" vs "documentos fotografados" via padrão visual.

B — Pasta de projetos do trabalho: categoria por CLIENTE (lê texto do .pdf primeiras 200 palavras pra inferir). Dry-run mostra "97% confiança" antes de mover.

C — Pasta de assinaturas digitais (com certificado): NÃO MEXE. Skill detecta arquivos sensíveis (.p12, .key, .pem) e pula explicitamente.

D — Email attachments salvos: cruza com info do remetente (pega do nome do arquivo) e organiza por contato.

⚠ Erros comuns ao adaptar

• Pular o dry-run "por pressa" — esse passo evita 99% dos desastres. Pular = você vai aprender do jeito caro.
• Confiar em "apaga duplicados" — duplicado por nome ≠ duplicado real. Hash MD5 ou comparação byte-a-byte é mínimo.
• Não criar backup — "tenho Lixeira" não é backup. Lixeira esvazia, falha de FS acontece, "apagado por engano há 1 mês" não tem volta.
• Não gerar log estruturado — sem log você não consegue auditar nem reverter.

📊 Métricas reais

8 min

execução

~4h

economizados
(fazer manual)

arquivos perdidos

15min → 20s

tempo de busca

CASE 2

📊 Skill "Relatório Semanal de Cliente" — copiável e versionável

Cenário

Marcos toca uma micro-agência de marketing (3 funcionários, 11 clientes). Toda sexta-feira gasta 4 horas montando 11 relatórios semanais (1 por cliente). Cada um lê dados de Google Ads, Meta Ads, GA4 e Notion (onde marca os experimentos da semana). Junta tudo num PDF "esteticamente bonito" que cliente lê em 30 segundos.

Recursos: co-work, estrutura de pastas ~/agencia/clientes/[cliente]/ já organizada, exports semanais dos ads platforms.

❌ Primeira tentativa — sem template

Marcos pediu "gera relatório semanal do cliente X". Claude fez. Mas cada um saía diferente — uma semana tinha gráfico, outra não. Tom oscilava. Métricas iam mudando de ordem. Cliente comentou: "às vezes vem completo, às vezes parece resumido demais. Tá padronizado?"

Por que falhou: "Relatório semanal" como prompt solto produz output não-determinístico. Sem template fixo + sem fontes especificadas + sem critério de inclusão = cada execução é uma nova decisão.

✅ Skill final completa

Marcos escreveu skill em ~/agencia/.claude/skills/relatorio-semanal-cliente.md:

--- name: relatorio-semanal-cliente description: Gera relatório semanal padronizado pra cliente de marketing. Pega dados dos exports + Notion. Saída em PDF na pasta do cliente. --- # Como invocar "Roda skill relatorio-semanal-cliente. Cliente: [nome]. Semana: [DD/MM-DD/MM]." # Pré-requisitos - Pasta ~/agencia/clientes/[cliente]/ deve existir - Exports da semana em ~/agencia/clientes/[cliente]/exports/AAAA-WW/ - google-ads.csv - meta-ads.csv - ga4.csv - Notas de experimentos em ~/agencia/clientes/[cliente]/notion-sync/AAAA-WW.md # Passos da skill 1. **Validar inputs** - Se algum arquivo faltar, ABORTE e me liste o que falta. Não invente número. 2. **Calcular agregados da semana** - Investimento total (Google + Meta) - CPL ponderado por plataforma - ROAS por plataforma - Variação vs semana anterior (lê pasta /AAAA-WW-anterior/ se existir) 3. **Identificar destaque positivo e ponto de atenção** - Destaque: maior melhoria vs semana anterior (qualquer métrica) - Atenção: maior queda (mesmo critério). Se nenhum acima de 15% var, omita. 4. **Cruzar com experimentos do Notion** - Cada experimento ativo na semana: associar com métrica antes/depois quando possível - Se experimento sem dado conclusivo: marcar "[inconclusivo — continuar próxima semana]" 5. **Gerar PDF** usando ~/agencia/templates/relatorio-template.html como base - Estrutura fixa: * Header: logo + cliente + semana * KPIs em cards (3): investido, CPL, ROAS — com setinha de variação * Bloco "destaque da semana" (verde) * Bloco "ponto de atenção" (amarelo) — só se houver * Tabela de experimentos com status * Próximos passos (puxa do Notion seção "próxima semana") * Footer com data de geração e contato Marcos - Salvar em ~/agencia/clientes/[cliente]/relatorios/AAAA-WW.pdf 6. **Gerar texto pro WhatsApp pré-aprovado** - 3 bullets de resumo + 1 frase "PDF completo anexado" - Salvar em ~/agencia/clientes/[cliente]/relatorios/AAAA-WW-whatsapp.txt - NÃO envia. Eu copio e mando. 7. **Logar execução** - Em ~/agencia/_logs/skill-relatorio-AAAA-WW.md - Cliente, hora de execução, tempo gasto, alertas # Regras - NUNCA enviar nada sozinho (sem Slack/Email/WhatsApp via API) - Se algum dado parecer estranho (CPL 10x maior, ROAS negativo), MARQUE com 🚨 mas NÃO altere. Eu valido. - Linguagem do PDF: factual, sem hype. "Investimos R$ X, geramos Y leads, CPL caiu Z%." Sem "incrível", "extraordinário".

📤 Resultado

Marcos ainda sexta de manhã, em vez de 4h, gasta 25 minutos:

• 15 min — exportar dados das plataformas (manual, ainda)
• 5 min — rodar skill 11 vezes (em paralelo no terminal)
• 5 min — revisar os 11 PDFs (qualquer 🚨 chama atenção, ele valida)

PDFs vão pra clientes 10h. 3h35 sobrando. Cliente que reclamou de "não padronizado" parou de reclamar — o "destaque + atenção" virou o que ele lê primeiro.

🔀 Variações testadas

A — Cliente premium (relatório mensal denso): mesma skill, mas template muda pra "executive summary 1 página + apêndice técnico de 4". Roda 1x/mês.

B — Cliente self-service (relatório auto-leitura): versão mais educativa do texto, explicando o que é CPL e ROAS. Cliente entende sem ligação semanal.

C — Skill encadeada com /schedule: Marcos agenda "toda sexta 8h" — Claude roda automático SE os exports já estão na pasta. Se faltar, manda alerta.

D — Versão emergencial: "modo crise" pra quando cliente liga em pânico — relatório de 2 dias só, sem comparativo, foco no fogo atual.

⚠ Erros ao adaptar

• Skill sem "abort on missing data" — Claude inventa quando dado falta. Sempre incluir "se faltar X, ABORTE e me avise".
• Permitir envio automático no início — proibir comunicação externa até você confiar 100%. Depois você relaxa.
• Skill sem versionamento — quando você ajustar (e vai), versione no git. Skill é código.
• Pular o log de execução — sem log você não consegue auditar erros recorrentes nem refinar.

📊 Métricas reais

4h → 25min

tempo semanal

clientes/semana

reclamações de padronização

+2 clientes

atendidos com tempo poupado

CASE 3

⏰ Briefing matinal agendado — e o limite que ninguém te conta

Cenário

Renata, COO numa fintech B2B, começa o dia em reunião 8h. Antes da reunião quer briefing de 1 página: PRs do dev abertos ontem, tickets críticos do suporte, métricas-chave da operação overnight, agenda do dia. Hoje ela gasta 20 minutos abrindo 5 abas e juntando manual.

Recursos: co-work + /schedule. Conectores: GitHub, Slack, GA4, Calendar.

❌ Primeira tentativa — agendou e nada apareceu

Renata configurou: /schedule "gerar briefing matinal" todo dia útil 6h30. Confiante, foi dormir.

7h45, abriu o notebook: nada. Nenhum briefing. Skill não rodou.

A descoberta dolorida: /schedule do co-work REQUER máquina ligada E desktop aberto. Notebook fechou às 23h. Nenhuma execução possível. Esse é o limite que separa N3 do N5 (onde routines em nuvem rodam mesmo com máquina off).

✅ Adaptação realista no N3

Renata adaptou: roda manual ou automático MAS deixando notebook ligado + desktop aberto durante a noite. E criou skill com fallback.

Skill em ~/.claude/skills/briefing-matinal.md:

--- name: briefing-matinal description: Briefing matinal 1 página. Roda 6h30 dias úteis SE máquina ligada. Se eu rodar manual, executa imediatamente. --- # Pré-requisitos - Conectores ativos: GitHub (org X), Slack (canais #suporte, #ops), GA4 (propriedade Y), Calendar (pessoal) - Máquina ligada + desktop aberto se /schedule # Passos 1. **GitHub (últimas 12h)** - PRs abertos ontem após 18h - PRs com ≥2 dias sem review - Issues marcadas como [urgent] 2. **Slack (overnight, 18h ontem → agora)** - Mensagens em #suporte com tag :rotating_light: - Threads em #ops com mais de 5 respostas - Menções diretas pra @renata 3. **GA4 (últimas 24h)** - Sessões, conversões, erros 500+ (se aplicável) - Comparar com média dos últimos 7 dias - Flag automático se variação > 25% 4. **Calendar (hoje)** - Cada reunião com: hora, título, participantes, link 5. **Compor briefing** - Estrutura fixa (template em ~/templates/briefing-matinal.md): - 🔥 Atenção AGORA (até 3 itens, só se realmente urgente) - 📊 Métricas overnight (4 números + variação) - 📋 Decisões pendentes (PRs sem review, threads abertas) - 📅 Agenda do dia (5 reuniões max, ordenadas) - 🧘 "Hoje você pode focar em..." (1 frase com prioridade derivada) 6. **Entregar** - Salvar em ~/briefings/AAAA-MM-DD.md - Abrir automaticamente no editor (open command) - NÃO enviar Slack/email — Renata lê primeiro # Regras - Se algum conector falhar, gere briefing com o que conseguir + lista "fontes que falharam" - "Atenção AGORA" só com fato concreto. Sem "tudo parece bem" no vazio. - Máximo 1 página em A4. Se exceder, corta. # Fallback se /schedule não rodar (máquina off): "Renata, rode 'briefing-matinal AGORA' quando abrir o notebook."

📤 Output exemplo (briefing real de uma terça)

Briefing 13/05/2026 (terça) · gerado 6h31

🔥 Atenção AGORA
- Suporte tem ticket #4419 sem resposta há 14h — cliente Tier 1 (Banco Y). Atribuir alguém antes da call das 9h.

📊 Métricas overnight (vs média 7d)
- Sessões: 12.4k (-3%) | Conversões: 287 (+8%) | Erros 5xx: 14 (estável) | Pagamentos falhos: 2 (normal)

📋 Decisões pendentes
- PR #842 (refactor pricing) — 3 dias sem review. Tech lead viajou.
- Thread em #ops sobre limite de webhook chegou a 11 respostas — alguém precisa decidir.

📅 Hoje
- 9h00 — All-hands semanal
- 11h00 — 1:1 com CFO (rever orçamento Q3)
- 14h00 — Call cliente Banco Y (atenção: ticket #4419 pode pegar nessa)
- 15h30 — Entrevista pra vaga Dev Sr
- 17h00 — Review jurídico contrato fornecedor Z

🧘 Foque em: resolver o ticket #4419 antes das 9h. Resto pode esperar.

🔀 Variações testadas

A — Briefing pré-call de cliente: trigger por evento de Calendar 30min antes. Gera briefing focado no cliente específico (histórico, decisões, pendências).

B — Briefing semanal de domingo: em vez de diário, sumariza a semana toda. Renata roda manual antes da reunião de planejamento de segunda.

C — "Modo crise": roda na hora, ignora estrutura fixa, foca só no incidente atual com timeline.

D — Versão pro time: mesma estrutura, mas filtrada (sem detalhes sensíveis), gera versão pra postar no #ops todo dia 8h45.

⚠ Erros ao adaptar

• Esquecer que /schedule do N3 precisa máquina ligada — vai te pegar logo. Pra rotina sem máquina, espere o N5.
• Permitir envio automático no Slack/email logo de início — leia primeiro por 2 semanas antes de habilitar.
• Tentar puxar de 8 conectores ao mesmo tempo — comece com 2-3, expanda depois. Mais conectores = mais ruído.
• Briefing longo demais — se passa de 1 página, ninguém lê. Skill DEVE forçar corte.

📊 Métricas reais

20min → 0

tempo manual/dia

~7h

economizados/mês

incidentes detectados
antes de virarem crise

100%

manhãs com clareza
do que importa

★

🧠 O padrão N3 por trás dos 3 cases

Quando Claude opera na sua máquina, os ingredientes mudam. Não é mais "papel + contexto + formato". É:

1. Dry-run sempre antes da primeira execução — Claude descreve plano, espera OK explícito. Pulou isso uma vez? Aprendeu do jeito caro.
2. Backup automático antes de operação destrutiva — independente de Lixeira/Trash. Backup = snapshot que você controla.
3. Permissão pra abortar com fonte faltante — "se faltar X, ABORTE e me avise" mata 80% das alucinações em skills.
4. Log estruturado obrigatório — sem log você não consegue auditar nem refinar. Skill sem log = caixa-preta.
5. Proibir comunicação externa automática até confiar — Claude gera, você manda. Quando confiança madura (50+ execuções limpas), aí relaxe.

Os 5 ingredientes do N1 ("papel + contexto + formato + restrição + saída") continuam valendo. Esses 5 do N3 são ADIÇÕES, não substituições.

🎓 Resumo do Módulo

✓

Case 1 (Downloads): 5 regras de chão que evitam apagar contrato. Dry-run + backup + log + "nunca apagar, mover".

✓

Case 2 (Skill semanal): skill versionada com abort, regras anti-invenção e proibição de envio automático.

✓

Case 3 (Briefing agendado): /schedule precisa máquina ligada — limite do N3. Fallback pra rodar manual quando ela esquece.

✓

Padrão N3 — 5 ingredientes adicionais: dry-run, backup, abort com fonte faltante, log obrigatório, sem envio automático cedo.

✓

Métricas reais: 4h→25min/semana, 20min→0/dia, 0 arquivos perdidos. ROI honesto.

Próximo Módulo:

3.5 — Walkthrough completo: como Bruno saiu de freelancer cobrando hora pra vender automação por R$ 12k + manutenção mensal.

← Voltar para Trilha Próximo Módulo →