🚀 Workflows e Operação

Projeto com instructions de revisor técnico, knowledge com style guide e exemplos de PRs exemplares.

O caso mais alto valor pra time de engenharia. Implementação em 1h, ROI semana 1.

Style guide no knowledge, severidade nos findings, escopo restrito.

Newsletter, posts, anúncios. Instructions traz brand voice; knowledge traz exemplos do que pegou.

Mantém consistência sem depender de uma pessoa específica. Onboarding novo é rápido.

Brand voice persistente, exemplos curados, evita drift.

Knowledge com FAQ, política, troubleshooting. Instructions com tom de suporte e quando escalar.

Reduz tempo de resposta médio do tier 1, libera atendente pra casos complexos.

FAQ estruturado, política como regra, gatilhos de escalada.

Knowledge com papers, relatórios, transcrições. Instructions cobra citação em toda resposta.

Q&A em corpus institucional sem precisar de RAG custom. Setup em horas.

Citação forçada, fonte por trecho, auditabilidade.

Knowledge com histórico de KPIs e benchmarks. Cada mês você sobe o relatório novo, ele compara.

Análise consistente todo mês sem reinventar a análise toda vez.

Série histórica, benchmarks, formato de análise fixo.

Geração de doc técnica, briefings, ATAs. Instructions define formato, knowledge tem templates exemplares.

Doc fica consistente entre times, mesmo com autores diferentes.

Estrutura fixa, exemplos canônicos, consistência cross-team.

Workspace é o contêiner do time. Cada membro consome 1 seat. Admin gerencia billing e acessos.

Sem entender workspace, fica difícil organizar acesso e cobrança.

Workspace, seat, admin, billing centralizado.

Projetos visíveis pra todo o workspace ou pra subgrupo. Knowledge e instructions ficam comuns; chats podem ser privados.

Knowledge curado coletivamente tem qualidade superior. E reduz duplicação.

Shared, scope, knowledge comum, chats privados.

Admin gerencia tudo; Membro cria/edita projetos; Viewer só consome. Granularidade varia por plano.

Sem definição de papel, viewers viram editores acidentais e quebram instructions.

RBAC, princípio do menor privilégio.

Pessoa entra, é provisionada (manual ou SCIM), recebe acesso aos projetos relevantes. Doc interna acelera.

Em time grande, onboarding ruim deixa pessoas perdidas semanas.

Provisionamento, doc interna, project guide.

Pessoa sai: SCIM desprovisiona ou admin remove manualmente. Chats privados ficam (anonimizados) ou são exportados.

Ex-funcionário com acesso é risco. Processo claro de saída elimina.

SCIM offboarding, transferência de chats, política de retenção.

Padrão de nome de projeto, prefixo por área (eng, mkt), tag de status (ativo, deprecated).

Sem convenção, 50 projetos vira sopa. Com convenção, escala bem até 500.

Naming convention, prefixos, taxonomia.

Autoriza acesso a Drive específico; doc/sheet entra no knowledge sempre na versão atual.

Knowledge que vive em Drive não precisa de re-upload manual a cada mudança.

OAuth, sync vivo, escopo limitado.

Acesso a repos selecionados; pode trazer arquivos, issues, PRs como referência.

Conversa sobre código fica muito melhor quando o contexto vem do repo direto.

Repo access, escopo por org/repo, leitura.

Conectores adicionais cobrem stack típico. Cada um com escopo OAuth.

Stack do time tem 5-10 sistemas. Conectar 2-3 mais relevantes desbloqueia muito.

Stack do time, conectores certificados.

Protocolo aberto criado pela Anthropic. Qualquer serviço pode expor um servidor MCP e ser usado como conector.

É o ecossistema que está crescendo. Conector custom sai bem mais barato em MCP do que API one-off.

MCP servers, tools, resources, open standard.

Cada OAuth pede permissões. Sempre escolher o escopo mínimo necessário. Revoga acesso quando não usa mais.

Conector com escopo amplo é vetor de leak. Princípio do menor privilégio aplica.

Scope mínimo, revoke, audit de conexões.

Documento estável (manual, política): melhor upload manual. Sistema crítico de produção: revisão de segurança antes.

Conector é overhead operacional. Quando não há mudança frequente, upload simples vence.

Trade-off de manutenção, estabilidade do dado.

Bloco de instruções + recursos que o modelo invoca quando reconhece um padrão de pedido. Reutilizável entre projetos.

Skills evitam reescrever a mesma orientação em vários projetos. DRY do prompting.

Comportamento ativável, trigger, reutilização cross-project.

Nome curto, descrição clara do quando ativar, conteúdo com procedimento e exemplos.

Descrição ruim faz skill não disparar. Descrição certa faz o modelo achar e ativar sozinho.

Trigger por descrição, procedimento estruturado.

Comandos prefixados com / que invocam comportamento específico (/help, /summarize, etc).

Quando você sabe exatamente o que quer, slash é mais rápido que explicar em prosa.

Comando explícito, atalho, predictability.

Quando o caso precisa de execução autônoma multi-passo (ler/escrever arquivos, rodar comandos), passa de Cowork pra Code ou API.

Reconhecer cedo que o caso virou agentic evita gastar tempo forçando Cowork.

Autonomia, tool use, transição para Code.

Skill criada uma vez pode atender múltiplos projetos. Em Team/Enterprise, fica compartilhada.

Economia de manutenção: muda em um lugar, propaga.

Library de skills, manutenção centralizada.

Time cria 50 skills, modelo fica confuso na hora de escolher, performance cai.

Skills devem ser poucos, específicos, bem nomeados. Curadoria > acúmulo.

Curadoria, deprecate antigas, biblioteca enxuta.

Knowledge desatualiza, instructions acumula contradição, capacity satura. Resultado: respostas piores ao longo do tempo.

Sem manutenção, projeto bom vira projeto ruim em 3 meses sem ninguém perceber.

Drift, degradação silenciosa, entropia.

Quinzenal: capacity bar e arquivos antigos. Mensal: revisar instructions. Trimestral: revisão completa, baseline novo.

Cadência fixa transforma manutenção em hábito, não em emergência.

Cadence, hábito vs reação.

5-10 perguntas-prova com respostas esperadas. Rodar a cada mudança de instructions/knowledge.

Mudou? roda baseline. Piorou? rollback. Sem baseline, mudança é fé cega.

Regression test, mudança guiada por dado.

Google Doc/Notion onde mudanças de instructions e knowledge são registradas, com data, autor e motivo.

Cowork não tem versionamento. Sem changelog externo, ninguém lembra o que mudou nem por quê.

Audit trail manual, why captured.

Projeto que não foi usado em 60 dias: marca como deprecated. Não foi em 90 dias: arquiva. 180+: deleta.

Sem deprecação, workspace vira cemitério. Curadoria contínua mantém útil.

Lifecycle, deprecation, hygiene.

Cada projeto compartilhado tem um owner declarado. Pessoa responsável pela manutenção.

"Responsabilidade de todos" = responsabilidade de ninguém. Owner explícito mantém vivo.

DRI, accountability, sucessão.

Frequência de uso, número de conversas/semana, retenção de usuários no projeto, casos resolvidos.

Métrica diz se projeto vive ou morre. Sem dado, defendê-lo é fé.

Engagement, retenção, ROI.

Custo direto: seats × valor. Indireto: tempo de manutenção, deprecação de outras ferramentas, treinamento.

Só olhar mensalidade subestima TCO. Visão completa permite decisão informada.

TCO, custo de manutenção, savings.

Caso virou rotina, precisa de ação em arquivos, integra com CI, ou tem que rodar headless. Hora de Claude Code.

Insistir em Cowork pra caso agentic é desperdício. Reconhecer o momento é eficiência.

Sinais de migração, transição clara.

Caso virou um feature interno (usuários do produto interagem), volume alto, precisa de SLA. API é o destino.

Cowork não escala pra ser produto. API com prompt caching e batch é o caminho.

Anthropic API, prompt caching, batch.

Exportar instructions+knowledge, traduzir pra system prompt da API/Code, validar baseline, paralelo por 2 semanas, switch.

Migração afobada quebra o que estava bom. Plano gradual minimiza risco.

Paralelo, baseline, cutover.

Caso conversacional, recorrente, sem ação em disco, volume humano: Cowork é o destino, não a estação intermediária.

Migrar tudo pra API/Code é fetiche de engenheiro. Cowork brilha onde é o veículo certo.

Cowork como destino final, especialização.