🎯 Escolha do caso
Pegue um workflow específico que você repete na semana. Não tente "projeto pra tudo" — é caminho garantido pro fracasso.
🔎 Pergunta-guia
"Qual tarefa eu fiz 3+ vezes nas últimas 2 semanas que sempre começa do zero?"
Se a resposta é "ah, várias coisas" — escolha a mais frequente. Se é "nenhuma específica" — talvez Cowork não seja o que você precisa ainda.
📝 Nome e descrição
Nome curto, descritivo, escaneável. Descrição em 1-2 frases que explicam o propósito do projeto e pra quem ele serve.
✓ Bons nomes
- ✓ "Revisão PR Backend"
- ✓ "Copy Newsletter Semanal"
- ✓ "Atendimento SaaS — Tier 1"
- ✓ "Análise Mensal Vendas"
✗ Nomes ruins
- ✗ "Meu projeto"
- ✗ "Trabalho"
- ✗ "Teste 1"
- ✗ "Untitled" (deixar default)
⚙️ Custom instructions inicial
Template enxuto de 5 partes. Refina depois. Começar com 3 páginas é receita de lixo que ninguém revisita.
PAPEL: Você é meu copiloto pra revisão de PR backend.
OBJETIVO: Identificar bugs, problemas de segurança e
melhorias claras. Não sugerir refator amplo.
TOM: Técnico, direto, sem rodeio. Vai ao ponto.
FORMATO: Lista de findings, cada um com severidade
(alta/média/baixa) e arquivo:linha.
EVITAR: "talvez", "considere". Seja afirmativo ou
se cale.5 linhas. Tudo concreto. Vai testar, vai ver onde falha, vai ajustar uma linha por vez.
📚 Knowledge inicial
Selecione 3-5 arquivos que cobrem 80% das perguntas. Resto entra sob demanda. Princípio: curadoria, não acúmulo.
Manual de estilo / conventions
As regras que o projeto segue. Pode ser style guide, ESLint config explicado, padrões de commit.
Exemplos de "bom"
2-3 PRs/copies/análises que você considerou exemplares. O modelo aprende padrão imitando bons exemplos.
Contexto do negócio
Glossário, lista de produtos/serviços, política aplicável. O suficiente pra ele entender vocabulário.
⚠️ Anti-padrão
Subir 50 PDFs "porque podem ser úteis". Satura contexto, degrada respostas, ninguém usa nenhum direito. Comece com 3. Adicione 1 quando perceber falta clara.
🧪 Primeiro teste
Faça a pergunta que motivou criar o projeto. Se vier melhor do que viria no Chat, projeto vale. Se vier igual ou pior, alguma coisa está errada (instructions vago, knowledge irrelevante).
🎯 Baseline Chat vs Cowork
- Abra um Chat normal, faça a mesma pergunta
- Abra o projeto, faça a mesma pergunta
- Compare: o Cowork respondeu com mais especificidade, mais alinhamento?
- Se sim, projeto provou valor
- Se não, instructions ou knowledge precisa ajuste
🔄 Iterar com base no erro
Cada resposta ruim aponta o que falta. Erro não é falha, é sinal. Projeto que evolui com uso é projeto que sobrevive ao trimestre.
💡 Loop de melhoria
- Resposta veio ruim em algum aspecto
- Identifica: é falta de regra (vai pra instructions) ou de fato (vai pro knowledge)?
- Atualiza só o que é necessário
- Re-testa a mesma pergunta
- Resposta melhorou? Marca como resolvido. Não melhorou? Ajusta de novo
✅ Resumo do Módulo
Próximo módulo:
1.6 — Segurança, privacidade e governança