🛠️ Fable 5 como Agente de Trabalho

Um modelo avançado como o Fable 5 é desperdiçado em resumir texto ou responder pergunta rápida — o valor real aparece em problemas difíceis: revisar arquitetura de projeto inteiro, avaliar risco de produto/tecnologia/negócio, transformar ideia em plano de execução, analisar documento longo, revisar código/segurança/UX/banco de dados.

Direcionar a ferramenta certa pra tarefa certa é o primeiro filtro pra usar o modelo como agente de trabalho, não como chat caro.

Tarefa de alto valor; desperdício de capacidade; diagnóstico vs pergunta rápida.

Um template de prompt que pede diagnóstico do problema central, decisões estratégicas, riscos, plano de execução em etapas, entregáveis concretos e o que fazer agora — em ordem.

É um prompt pronto pra copiar e adaptar, testado em tarefas reais de análise de projeto.

Prompt testado na prática (não citação oficial); agente sênior; entregável em etapas.

O modelo responde melhor quando entende a intenção por trás do pedido: objetivo maior, público, contexto e resultado esperado — não só a instrução seca.

"Crie uma trilha de IA" é fraco; contar pra quem é, com que objetivo e que resultado final se espera muda completamente a qualidade da resposta.

Contexto de intenção; público-alvo; resultado esperado declarado.

Um template que declara o objetivo ("profissionais que querem aplicar IA no trabalho, praticando todo dia") antes de pedir a trilha com diagnóstico inicial, prática diária, projeto semanal, apoio, critério de evolução e resultado final.

Comparar o prompt fraco com o forte lado a lado mostra concretamente o ganho de contextualizar antes de pedir.

Prompt fraco vs forte; estrutura com critério de evolução; resultado final esperado.

Na prática: antes de escrever qualquer prompt de análise pesada, primeiro confirme que a tarefa merece o modelo (dica 1), depois amarre o motivo real do pedido (dica 2) — as duas juntas viram um prompt de diagnóstico completo.

Usadas separadas, cada dica ajuda pouco; combinadas, mudam o tipo de resposta que você recebe.

Filtro de tarefa + contexto de intenção; prompt de diagnóstico completo.

Erros comuns: usar o modelo pra tarefa de resumo/legenda; pedir análise sem dizer pra quem é nem qual o resultado esperado; copiar prompt genérico sem adaptar ao projeto real.

Checklist rápido antes de disparar: a tarefa é difícil o suficiente? o motivo está explícito? o público e o resultado estão claros?

Checklist pré-prompt; adaptação ao projeto real; motivo explícito.

Baixa: resumo, legenda, ajuste de texto, ideia rápida. Média: planejamento simples, comparação, revisão de conteúdo. Alta: estratégia, arquitetura, auditoria, decisão de produto. Máxima: problema crítico, migração, segurança, análise de risco complexa.

Pedir raciocínio máximo pra tarefa trivial custa mais e demora mais sem ganho — e o contrário entrega superficial demais pra decisão séria.

Profundidade de análise; custo × complexidade; calibração por tipo de tarefa.

Um prompt curto que restringe onde aplicar profundidade: "use análise profunda apenas na parte estratégica. Não complique a solução. Não crie abstrações desnecessárias. Entregue a solução mais simples que resolve bem o problema."

Concentra o esforço caro onde importa e evita que o resto da resposta vire complexidade desnecessária.

Profundidade seletiva; solução mais simples; anti-abstração.

Modelos fortes podem tomar iniciativa demais — antes de análise técnica ou execução, é preciso deixar claro o que o agente pode ou não fazer sozinho.

Sem limite declarado, "avalie esse servidor" pode virar "reiniciei o serviço" — surpresa cara em ambiente de produção.

Limite explícito; iniciativa do agente; separação avaliação/execução.

"Primeiro apenas avalie. Não altere arquivos, não reinicie serviços, não crie branch, não edite configuração e não rode comandos destrutivos. Entregue um diagnóstico com evidências. Depois diga exatamente quais mudanças recomenda e por quê."

Separa em duas etapas explícitas — avaliar, depois recomendar — antes de qualquer ação real acontecer.

Avaliação sem ação; diagnóstico com evidência; recomendação separada da execução.

Numa auditoria de segurança real: peça profundidade alta só na análise de risco (dica 3), mas trave a execução com "apenas avalie, não altere nada" (dica 4) — o agente pensa fundo e ainda assim não toca em produção sem permissão.

Profundidade sem limite é risco; limite sem profundidade é análise rasa — as duas dicas se completam.

Profundidade contida por limite; auditoria segura; pensar fundo sem agir sozinho.

Erros comuns: pedir profundidade máxima em toda tarefa por hábito; deixar "avalie o sistema" sem dizer o que ele não pode tocar; confundir avaliação com autorização de execução.

Checklist rápido: a profundidade pedida bate com a complexidade real? os limites de ação estão explícitos antes de qualquer análise técnica?

Checklist pré-prompt; hábito de profundidade máxima; limite explícito antes da análise.

Nunca aceitar "pronto" sem evidência — em código, automação, banco de dados, deploy ou documento, o modelo precisa provar o que fez.

Sem exigir prova, é fácil receber um relatório de status bonito que não corresponde ao que de fato aconteceu.

Evidência real; teste executado; log/output verificável.

"Antes de dizer que algo está pronto, confirme com evidência real: teste executado, arquivo alterado, log, saída de comando ou resultado verificável. Se não foi verificado, diga claramente: 'não verificado'. Se falhou, mostre a falha. Se pulou uma etapa, diga que pulou."

Transforma "confio na resposta" em "confiro a evidência" — funciona em qualquer domínio, não só código.

"Não verificado" explícito; falha mostrada, não escondida; etapa pulada declarada.

Em vez de uma resposta única, analisar o mesmo problema por várias lentes especializadas — estratégia, produto, comunicação, tecnologia, e um cético que procura falhas.

Bom pra avaliar ideias, ofertas, produtos, projetos e campanhas — a consolidação final é mais robusta que uma análise de tiro único.

Estrutura de papéis; agente cético; consolidação com prioridades.

"Use uma estrutura de subagentes: Agente 1 analisa estratégia e posicionamento. Agente 2 analisa produto e jornada do usuário. Agente 3 analisa conteúdo e comunicação. Agente 4 analisa tecnologia e automação. Agente 5 atua como cético e procura falhas. Depois consolide tudo em uma recomendação única, com prioridades."

É o template pronto pra avaliar qualquer decisão complexa com múltiplas dimensões de uma vez.

5 papéis fixos; recomendação única consolidada; prioridade explícita.

O Agente 5 (cético) da estrutura de subagentes é, na prática, o mecanismo de verificação real aplicado a decisões — ele existe pra recusar "pronto" fácil demais e forçar evidência antes da recomendação final.

Verificação não é só pra código — o papel de cético dentro dos subagentes aplica o mesmo princípio a decisões de produto e estratégia.

Cético como verificador; evidência antes da recomendação; papel dedicado a contestar.

Erros comuns: aceitar "pronto" sem pedir evidência; usar só 1 lente pra decisão complexa; pular o agente cético achando que atrasa o resultado.

Checklist rápido: existe evidência concreta pro "pronto"? a decisão passou por mais de uma lente? o cético teve voz na consolidação final?

Checklist pré-aceite; múltiplas lentes; voz do cético na consolidação.

O uso mais forte do Fable 5 não é o prompt perfeito de uma vez — é a memória contínua do projeto: posicionamento, público-alvo, ofertas, tom de voz, erros a evitar, decisões confirmadas, prompts validados, cada um num arquivo.

Sem memória, cada sessão recomeça do zero e repete os mesmos erros já corrigidos antes.

Memória de projeto; estrutura de pastas por tema; decisão confirmada vs hipótese.

"Sempre que aprendermos algo importante sobre este projeto, registre em memória. Formato: decisão ou lição; por que importa; onde aplicar; o que evitar; data. Não duplique informação. Atualize a nota existente quando necessário."

Transforma memória em hábito automático da sessão, não numa tarefa manual esquecida.

Registro estruturado com data; anti-duplicação; atualização de nota existente.

Em tarefas longas, o modelo pode parar cedo ou terminar com promessa em vez de executar — é preciso deixar explícito que ele deve seguir quando já tem o que precisa.

Útil em código, documentação, planejamento e criação de conteúdo — qualquer tarefa longa onde parar no meio custa retrabalho.

Execução em vez de promessa; parar só quando necessário; ação destrutiva como exceção.

"Se você já tiver informação suficiente, execute. Não termine com promessa, plano ou pergunta genérica. Só pare se precisar de uma informação que apenas eu posso fornecer ou se a ação for destrutiva ou irreversível."

Fecha o loop de "vou fazer depois" que trava sessões longas sem necessidade real de pausa.

Critério de parada explícito; ação irreversível como única exceção; fim de "promessa vazia".

A memória de projeto é justamente a "informação suficiente" que libera o agente pra executar sem pausar — quanto mais completa a memória, menos motivo legítimo o agente tem pra parar cedo.

As duas dicas formam um ciclo: memória bem mantida reduz as paradas desnecessárias, e cada execução gera nova lição pra memória.

Memória como combustível de execução; ciclo memória-ação-lição.

Erros comuns: nunca registrar lição em memória; deixar o agente parar por hábito de pedir confirmação; duplicar nota em vez de atualizar a existente.

Checklist rápido: a lição desta sessão foi registrada? o agente executou ou só prometeu? a memória está sem duplicata?

Checklist de fechamento de sessão; registro vs esquecimento; duplicata de nota.

Avaliar clareza, conversão e impacto de telas, páginas, PDFs e peças visuais passando print ou imagem — não só pedir "deixe mais bonito".

A revisão visual estruturada aponta problema específico e acionável, em vez de opinião estética vaga.

Revisão visual estruturada; primeiro olhar; geração de dúvida vs desejo.

"Analise este print ou imagem. Compare com o objetivo: fazer uma pessoa entender rapidamente o valor da proposta. Diga: onde o olho para primeiro; o que está confuso; o que gera desejo; o que gera dúvida; o que cortar; o que mudar para aumentar conversão."

Cada pergunta força uma resposta concreta e testável, em vez de "está bom" genérico.

6 perguntas de revisão visual; corte vs adição; conversão como critério.

Em segurança, pedir revisão defensiva em vez de exploração/ataque evita resposta bloqueada e mantém o foco em proteção.

O enquadramento da pergunta muda se você recebe ajuda de verdade ou uma recusa — mesmo pedindo pela mesma vulnerabilidade.

Enquadramento defensivo; recusa evitável; foco em proteção.

"Analise meu código de servidor como revisão defensiva. Procure bugs, validações ausentes, problemas de autorização, exposição acidental de dados, falhas de configuração e riscos operacionais. Não crie exploit. Não mostre passo a passo de ataque. Apenas indique o risco, o arquivo afetado, a causa provável e a correção defensiva."

É literalmente a estratégia prática pra não disparar a recusa de categoria "cyber" durante uma revisão legítima de segurança.

Sem exploit; risco + causa + correção; recusa evitada por enquadramento.

Num lançamento de produto: use a revisão visual (dica 9) na landing/print antes de publicar, e a revisão defensiva (dica 10) no backend que sustenta o formulário — cobre a experiência e a segurança da mesma feature.

As duas dicas juntas cobrem "o que o usuário vê" e "o que protege o que ele não vê" — segurança nunca é só código, e UX nunca é só estética.

Revisão de experiência + revisão de risco; cobertura completa de uma feature.

Erros comuns: pedir "deixe mais bonito" sem critério de conversão; enquadrar revisão de segurança como pedido de exploit/ataque; revisar só a tela e esquecer o backend.

Checklist rápido: a revisão visual tem as 6 perguntas respondidas? a revisão de segurança está enquadrada como defensiva? cobriu tela e servidor?

Checklist pré-publicação; enquadramento correto; cobertura tela+servidor.

"Revise meu app todo dia" é um loop fraco — um loop bom precisa de foco (área pequena), critério (base em memória), teste e aprendizado registrado a cada ciclo.

Repetição sem critério gasta orçamento e não melhora nada de forma mensurável; loop com verificação melhora de fato, ciclo a ciclo.

Loop fraco vs forte; foco por ciclo; critério salvo em memória.

"A cada ciclo: 1) escolha uma área pequena do sistema; 2) analise com base nos critérios já salvos em memória; 3) proponha uma melhoria; 4) implemente somente se for segura e reversível; 5) rode teste; 6) peça ao verificador para tentar encontrar erro; 7) registre a lição aprendida."

Cada passo do loop tem um propósito específico — pular um deles (geralmente o 6 ou o 7) é o motivo mais comum de loop que não evolui.

7 passos do loop; mudança segura e reversível; verificador dedicado.

Não depender só do histórico do chat — criar arquivo, banco ou documentação de apoio que sobrevive ao fim da sessão.

Histórico de chat some ou fica longo demais pra ser útil; memória externa é o que permite trabalho de semanas, não só de uma sessão.

Memória externa; persistência além da sessão; documentação de apoio.

Público-alvo, tom de comunicação, ofertas, campanhas que funcionaram, regras técnicas, decisões estratégicas, erros recorrentes, processos de trabalho, prompts validados, padrões de qualidade.

É a lista de referência pra decidir o que vale a pena registrar — evita memória vazia ou memória com ruído demais.

Categorias de memória externa; padrão de qualidade registrado; erro recorrente documentado.

O passo 7 do loop ("registre a lição aprendida") é exatamente onde o loop alimenta a memória externa — sem memória externa, o loop reaprende a mesma coisa a cada ciclo.

As duas dicas fecham um ciclo virtuoso: o loop gera lição, a memória externa guarda, o próximo ciclo parte de critério mais forte.

Ciclo virtuoso loop-memória; critério que cresce ciclo a ciclo.

Erros comuns: loop sem foco definido ("revise tudo"); pular o passo do verificador; depender só do chat pra trabalho que dura semanas.

Checklist rápido: o ciclo tem foco pequeno e critério salvo? o verificador rodou? a lição foi pra memória externa, não só pro chat?

Checklist de ciclo; foco pequeno; lição fora do chat.

As 12 dicas resumidas: tarefa certa, motivo explícito, profundidade calibrada, limite antes de agir, verificação real, subagentes especializados, memória de projeto, continuar até concluir, visão pra interfaces, revisão defensiva, loop com verificação, memória externa.

Serve como referência rápida pra revisar antes de escrever qualquer prompt novo de trabalho.

Cheat sheet das 12 dicas; referência rápida pré-prompt.

O prompt genérico completo que combina contexto, objetivo, modo de trabalho (subagentes, evidência antes de afirmar, execução em vez de promessa, memória de projeto) e tarefa — pronto pra colar no início de qualquer projeto novo.

É o maior code box do módulo — a versão condensada de tudo que a trilha ensinou, pronta pra copiar e adaptar.

Prompt mestre; modo de trabalho declarado; primeiro próximo passo.

Trocar sempre: o parágrafo de contexto e a tarefa final, específicos do seu projeto. Manter sempre: os 7 itens do modo de trabalho — eles são a parte que faz o prompt funcionar como agente, não como chat.

Evita reescrever o prompt do zero a cada projeto — só a parte específica muda.

Parte variável vs parte fixa; reuso entre projetos.

"O valor do Fable 5 não está em responder melhor. Está em trabalhar melhor. A forma fraca de usar é pedir respostas. A forma forte é criar um sistema com contexto, memória, subagentes, verificação e execução contínua. Quem usar o modelo apenas como chat terá respostas melhores. Quem usar como sistema de trabalho terá vantagem real."

É a tese central da trilha 2 — todas as 12 dicas anteriores existem pra sair do chat e entrar no sistema de trabalho.

Chat vs sistema de trabalho; vantagem real; execução contínua.

Mapa rápido de cruzamento: 2.2→1.6 e 1.3 (esforço e fronteiras), 2.3→1.4 e 1.7 (verificação e subagents), 2.4→1.7 e 1.4 (memória e anti-overplanning), 2.5→1.6 (categoria cyber), 2.6→1.4 (verificação por subagent) — pra quem quer ir fundo no lado oficial/técnico de cada dica.

Mostra que a trilha 2 não é solta — cada dica prática tem uma raiz técnica/oficial na trilha 1 pra quem quer aprofundar.

Mapa de cruzamento trilha 1 × trilha 2; prático vs oficial/técnico.

Checklist combinando as técnicas oficiais da trilha 1 (contexto, negative prompting, fronteiras, prova de conclusão, concisão, effort levels, subagents/memória) com as 12 dicas práticas da trilha 2, num único cheat sheet do curso inteiro.

Fecha o curso com uma referência única — não precisa lembrar em qual trilha cada técnica estava.

Checklist único do curso; ~19 técnicas combinadas; referência de fechamento.