Da descoberta do problema até o Demo Day — com a IA executando e você no comando. Este guia caminha com você em cada passo: como começar, o que perguntar, o que pedir à IA e o que fazer quando travar.
🚦 Nunca usei o Onion — começar do zeroAntes de qualquer comando, esta seção responde as quatro dúvidas que todo mundo tem no início: o que é o Onion, como abrir, onde ficam os arquivos e como nomear cada coisa. Sem isso, é fácil se perder. Com isso, você já sai andando.
O Onion é uma IA já preparada para te guiar no projeto, fase a fase. Você não programa e não instala nada complicado — você conversa com ela em português, e ela conduz o trabalho. Pense num mentor que já conhece o método de cor e está sempre disponível.
Há dois jeitos de usar o Onion. Escolha um com o seu squad no Kick-off — não precisa dos dois.
Não instala nada. Bom para quem está começando.
Uma IDE é o programa onde se escreve e edita código (como o Antigravity). Bom para quem quer a IA criando e salvando os arquivos sozinha.
ONION-MASTER-PROMPT.md e a pasta docs/.docs/ dentro dela.ONION-MASTER-PROMPT.md às regras da IDE — em .agents/rules/ (ou importe como regra global). É esse arquivo que "liga" o Onion.README.business-context.md de lugar nenhumMuita gente procura esse arquivo e não acha — porque ele ainda não existe. Quem cria é o próprio Onion, enquanto você avança:
business-context.md → nasce quando você roda o @product (Fase 1 · Descoberta).technical-context.md → nasce quando você roda o @engineer (Fase 2 · PoC).E onde eu guardo esses arquivos? Depende de como você abriu o Onion:
Resumindo: no navegador, você fica subindo e baixando os arquivos. Combine no squad uma pasta única no Drive.
commit de vez em quando para não perder o progresso.Nome canônico é o nome "oficial" e padronizado de um arquivo — aquele que todo mundo combina usar. Dê preferência a business-context.md e technical-context.md: assim qualquer pessoa do squad (e a própria IA) sabe na hora do que se trata. Pode ser um nome parecido se precisar, mas, se mudar, avise a IA no prompt — por exemplo: "salve isto como business-context.md". Padronizar evita que cada um chame o arquivo de um jeito e o squad se perca.
| Arquivo | O que é | De onde vem | Quando aparece |
|---|---|---|---|
| Onion Pulse (GPT) ou onion-portable | O próprio Onion — sua IA-guia | VOCÊ ABRE (links acima) | Antes de tudo |
ONION-MASTER-PROMPT.md · só na IDE | O arquivo que "liga" o Onion na IDE (vai em .agents/rules/) | VEM NO onion-portable | Antes de tudo |
business-context.md | Visão do produto, dores, requisitos, critérios de aceite | O ONION GERA | Fase 1 · Descoberta |
technical-context.md | Ferramentas escolhidas, plano técnico, arquitetura | O ONION GERA | Fase 2 · PoC |
business-context.md vai ser criado pelo Onion, não baixadoO projeto não anda por data no calendário — anda por marcos. Cada marco é um ponto de virada: você chega, valida o que fez e avança. Sempre que se sentir perdido, volte aqui e pergunte: "em qual marco eu estou?"
Leia o Comece aqui, a Mentalidade e o Método uma vez no começo. Ache o seu desafio. Depois trate cada fase como uma trilha: as perguntas abrem sua cabeça, os prompts (caixas escuras — clique para copiar) você usa direto com a IA, e as caixas "Se você travar" são seu paraquedas. Ninguém precisa decorar nada.
O mapa está aqui neste guia; o motor está no companheiro O Ciclo PLEA do seu projeto: Planificar → Executar → Avaliar, rodando dentro de cada fase (e de cada tarefa). Cada fase lá tem um checkpoint de abertura (3 perguntas por escrito antes do primeiro prompt) e um ritual de fechamento (avaliar e redesenhar antes de avançar o marco). Combine a regra de ouro com seu squad no dia 1 — é ela que separa "usar IA" de "aprender com IA".
Trabalhar com IA é menos sobre "saber programar" e mais sobre saber pedir. Estas quatro ideias mudam tudo — guarde-as no bolso para a jornada inteira.
Pense em você como o piloto e na IA como um copiloto incansável. Ela faz o trabalho braçal — escrever, pesquisar, montar — mas quem decide o rumo é você. Se você não dirige, ela inventa o caminho.
A IA só é tão boa quanto o contexto que você dá. "Faça um sistema" gera lixo. "O cliente é a Clear IT, a dor é X, o usuário faz Y" gera ouro. Quanto mais você descreve, melhor ela entrega.
Não existe pergunta boba. A IA é o par mais paciente do mundo — pergunte o que é uma API, peça para explicar como se você tivesse 12 anos, peça três exemplos. Curiosidade é a sua maior ferramenta aqui.
A IA "esquece" entre conversas. O que mantém o squad alinhado são os dois arquivos de contexto. Decidiu algo? Registre. Se não está escrito, no próximo ciclo a IA decide sozinha — e talvez diferente de você.
Quando uma resposta vier ruim, quase sempre o problema foi o pedido. Um bom prompt costuma ter três partes — não precisa ser nessa ordem exata, mas tente cobrir as três:
Quem é o cliente, qual a dor, o que já foi decidido. "Estamos no desafio da Clear IT sobre atendimento…"
O que você quer que aconteça. "Quero entender as 3 maiores dores" ou "preciso de um plano técnico".
Como quer a resposta. "Em lista", "explique simples", "máximo 5 itens", "salve como markdown".
Não recomece do zero — refine. Diga o que faltou: "Ficou genérico demais, traga exemplos concretos do nosso desafio" ou "Está complexo, simplifique para um squad iniciante". Conversar de volta é o normal — é assim que se chega num bom resultado.
O Onion Pulse é o método do seu squad durante todo o projeto. Quatro personas, dois arquivos de contexto e uma rotina de squad — é isso que mantém a IA alinhada com o que você realmente precisa.
Entende o problema, mapeia dores, escreve requisitos e história de usuário.
Planeja a solução técnica, testa viabilidade e constrói o produto.
Pesquisa ferramentas, APIs e integrações e cria um documento de referência.
Sincroniza tudo: lê o que foi feito e atualiza os documentos do projeto.
business-context.mdFrente @product. Visão do produto, dores do cliente, histórias de usuário, lista de tarefas e critérios de aceite. Gerado pelo Onion na Fase 1.
technical-context.mdFrente @engineer. Ferramentas escolhidas, plano de implementação, arquitetura. Gerado pelo Onion na Fase 2.
business-context.md (frente @product) e quem cuida do technical-context.md (frente @engineer). Todos contribuem, mas um dono de cada lado evita que o arquivo fique desatualizado.Cada squad trabalha um destes três desafios reais. Ache o seu, entenda a dor e use os prompts de exemplo como ponto de partida — adapte ao que o ponto focal contar no Kick-off. O foco é conteúdo, análise e automações com IA, não engenharia complexa.
A dor: feedbacks e 1:1 acontecem sem padrão. O líder não sabe estruturar uma conversa difícil nem registrar o PDI direito — e o RH fica sem visão do que é discutido. O sintoma virou queda no índice de Liderança e Confiança.
Um assistente que recebe o contexto do colaborador + o framework de competências da Clear IT e devolve roteiro, sugestões de abordagem e um PDI preenchido. Já entrega valor sem nenhuma integração.
"Como líder, quero preparar meu 1:1 com um roteiro guiado para conduzir conversas difíceis com segurança e registrar o PDI sem esforço extra."
Anonimize os dados do colaborador antes de colar no prompt. O RH só deve receber uma visão agregada, nunca registros que identifiquem alguém.
A dor: o analista de suporte L1 consulta várias fontes na mão (chamados, bases de conhecimento, portais de fabricante) para diagnosticar um incidente. É lento, varia de pessoa para pessoa e a curva para juniores é longa.
Um assistente que recebe o texto de um chamado colado + uma base de conhecimento fornecida pela Clear IT e devolve diagnóstico, casos similares e rascunho — sem precisar conectar a nenhum sistema. A integração com a API do FreshService é objeto de PoC.
"Como analista L1, quero um diagnóstico sugerido a partir do registro do chamado para reduzir o tempo de resolução e não consultar três fontes diferentes."
Mascare dados sensíveis (nomes de usuário, IPs internos, credenciais) antes de enviar o registro do chamado para a IA.
A dor: o roteiro de perguntas para a reunião de levantamento é feito de memória, cada um do seu jeito. Perguntas importantes se perdem, o resumo do levantamento chega incompleto ao time técnico e gera retrabalho.
Um agente que recebe a descrição da oportunidade + o portfólio da Clear IT como contexto e gera o roteiro completo de perguntas por categoria. É o desafio com o menor gap entre base viável e MVP — quase todo o valor está no próprio agente.
"Como pré-vendas, quero um roteiro de perguntas por categoria a partir da descrição da oportunidade para não esquecer pontos críticos e chegar ao cliente com um levantamento completo."
O agente não inventa capacidades. Se algo está fora do portfólio, ele deve sinalizar — nunca prometer o que a Clear IT não faz.
Entenda o problema antes de construir qualquer coisa.
business-context.md com visão do produto, dores mapeadas, história de usuário, critérios de aceite e ferramentas escolhidas. Status da feature: Pronto para Dev.
| Marco | O que acontece | Você sai com |
|---|---|---|
| Kick-off Abertura · presencial | Conhece o desafio, forma o squad, abre o Onion com o instrutor | business-context com cabeçalho preenchido + primeiras dores mapeadas |
| Workshop Design & IA Aprendizado | Aprende a mapear o problema e escrever requisitos com IA. Roda @product no seu desafio | Mapa do problema + lista de hipóteses para validar com a empresa |
| Sprint 1 · com a Clear IT Validação | Apresenta seu entendimento ao ponto focal. Ajusta o escopo conforme o feedback | Requisitos validados + escopo ajustado e registrado no arquivo |
Não pule essa etapa. Entender o contexto técnico do seu desafio agora evita retrabalho na PoC. Use o @meta para pesquisar qualquer coisa que a empresa apresentou e você não domina — perguntar é a postura certa, não a errada.
A IA salva cada pesquisa numa KB (ex.: kb-[tema].md). Use essas KBs para embasar as escolhas de ferramentas no technical-context.md.
Abra o Onion do jeito que escolheu no Comece aqui (GPT Onion Pulse no ChatGPT, ou onion-portable na IDE). Se já tiver começado antes, suba seus arquivos de contexto para a conversa. Depois diga:
A IA apresenta o estado do projeto e pergunta qual ciclo começar.
Diga à IA qual é o seu desafio. Ela vai perguntar até 3 coisas para entender o problema.
A IA roda Collect: valida a dor e faz até 3 perguntas de refinamento. Responda com tudo que a Clear IT apresentou no Kick-off — quanto mais contexto, melhor o requisito.
A IA vai gerar:
A IA gera o conteúdo do business-context.md e o status da feature muda para Pronto para Dev.
No ChatGPT: copie o que ele gerou e salve no arquivo (Drive/pasta do squad). Na IDE: o Onion já salva sozinho. Antes da Sprint 1, prepare uma frase-síntese: o que a empresa realmente espera que você resolva?
@product, com base em tudo que descrevi, escreva o problema em UMA frase, sem tecnologia.@meta antes de seguir. Avançar sem entender custa caro depois.Teste se a solução é viável antes de construir tudo.
technical-context.md. A Clear IT valida o que vai e o que não vai para o MVP na Sprint 2.
| Marco | O que acontece | Você sai com |
|---|---|---|
| Workshop MVP Aprendizado | Aprende a diferença entre PoC e MVP, como testar viabilidade e montar plano de contingência | Esqueleto da PoC + partes críticas testadas |
| Sprint 2 · com a Clear IT Validação | Demonstra a PoC ao ponto focal. Recebe feedback e prioriza o que vai para o MVP | PoC validada + escopo do MVP em 3 níveis: must / should / could |
A PoC não é o produto final — é uma investigação. Você quer saber o que funciona antes de investir tempo construindo tudo.
Antes de montar o fluxo completo, teste cada peça separada.
Quando os conceitos isolados funcionam, monte o fluxo mínimo completo — mesmo que com partes manuais.
Se uma parte não funcionar, não entre em pânico. Documente o que falhou, acione o plano B e siga. A PoC existe exatamente para isso.
Use essa KB para embasar o plano técnico.
A IA lê os dois contextos e apresenta um resumo do que entendeu e os pontos de atenção.
A IA vai gerar no technical-context.md:
Leia o plano com cuidado antes de aprovar. Consulte o consultor executivo se algo parecer fora do alcance.
[OK] ou [PROBLEMA ENCONTRADO]Se encontrar um problema:
@engineer, a parte X falhou. Quais 2 ou 3 alternativas mais simples?@engineer, simplifique este plano para caber em uma única semana de trabalho.Explique esse trecho em português simples, linha por linha.@engineer, gere 5 exemplos fictícios de [dado] para eu testar a PoC.Construa, refine e apresente a solução no Demo Day.
| Marco | O que acontece | Você sai com |
|---|---|---|
| Workshop Pitch Aprendizado | Aprende a transformar a solução em narrativa: problema, solução, demo, impacto | Rascunho do pitch + estrutura da demonstração ao vivo |
| Consultoria Final Refinamento | Revisão do MVP com o consultor + ensaio do pitch com banca simulada | MVP refinado + pitch ensaiado + checklist de entrega conferido |
| Demo Day Entrega · presencial | Pitch de 7 minutos para a banca e para a Clear IT + entrega formal do pacote | Solução entregue à Clear IT + celebração |
Nesta fase não há mais perguntas — é hora de entregar. Se surgir uma dúvida crítica que afeta a demo, acione o ponto focal antes do Demo Day. Não deixe para o dia.
O MVP não é o produto completo. É a menor coisa que ainda resolve a dor principal e pode ser demonstrada ao vivo.
Em dúvida se algo entra ou não — não entra. Uma demo limpa de 3 features vale mais do que uma demo instável de 8.
Implemente primeiro tudo que é must. Depois should, se houver tempo. Could fica para depois do Demo Day.
A IA lê o que foi construído e atualiza os dois arquivos de contexto. O resultado é o dossiê de entrega à Clear IT — solução + documentação fiel ao que foi feito.
Teste a demo ao vivo antes de subir. Tenha um plano B — printscreen ou vídeo curto caso algo não funcione na hora. Saber o que fazer se der erro é parte da entrega profissional.
@engineer, o que é o mínimo absoluto para a demo resolver a dor principal?Reescreva minha abertura de pitch em 2 frases que prendam a atenção.Os prompts mais úteis da jornada, reunidos por situação. Clique em qualquer caixa escura para copiar. Troque o que está [entre colchetes] pelo contexto do seu desafio — é aí que mora a mágica.
Fase 1 · quando você ainda está mapeando a dor
Qualquer fase · quando aparece um termo ou ferramenta nova
Fase 2 · do plano à prova de viabilidade
Fase 3 · da construção à finalização
Fase 3 · transformando a solução em história
Qualquer fase · seus prompts de resgate
As palavras que mais aparecem na jornada, em uma frase cada. Bateu uma dúvida? Volte aqui — e, se quiser ir mais fundo, é só perguntar ao @meta.
.agents/rules/). No ChatGPT não é preciso — o GPT já vem pronto.business-context.md / technical-context.md) onde fica registrado o que o squad decidiu. O Onion gera esses arquivos — você não baixa.As perguntas que quase todo mundo tem — e raramente faz em voz alta. Clique para abrir.
business-context.md. Onde ele está? ›Ele ainda não existe — e essa é a confusão mais comum. Você não baixa esse arquivo de lugar nenhum: o Onion cria ele para você quando você roda o @product na Fase 1. O technical-context.md nasce do mesmo jeito, quando você roda o @engineer na Fase 2. Veja o Comece aqui.
Dois jeitos: (1) abrir o GPT Onion Pulse no ChatGPT e começar uma conversa — mais simples, sem instalar nada; ou (2) baixar o onion-portable do GitHub e abrir numa IDE como o Antigravity, adicionando o ONION-MASTER-PROMPT.md às regras da IDE. Passo a passo completo no Comece aqui. Escolha um só, com o squad.
No ChatGPT: copie o conteúdo que ele mostra e salve num arquivo de texto no seu computador ou no Drive do squad — e suba de volta quando voltar a trabalhar. Na IDE: o Onion salva sozinho na pasta do projeto. Combine uma pasta única para o squad inteiro.
Sim — e é exatamente esse o ponto. Você não vai programar do zero: vai dirigir a IA. Seu trabalho é entender o problema, fazer boas perguntas e validar o que ela entrega. Quando aparecer código que você não entende, peça para ela explicar em português simples.
Normal — faz parte. Não recomece do zero: diga o que deu errado e peça correção. "Esse trecho deu o erro X" ou "isso não resolveu o que pedi, faltou Y". Se ela insistir no erro, abra uma conversa nova e dê o contexto de novo.
Respire e corte escopo. Pergunte à IA: "qual é o mínimo absoluto para resolver a dor principal?" Entregue só isso, bem feito. Uma demo simples que funciona vale muito mais que uma ambiciosa que quebra. E acione o consultor agora — pedir ajuda cedo é parte do processo.
Todos os comandos, os entregáveis por fase e os sinais de alerta — em um só lugar.
| Comando | Quando usar | O que acontece |
|---|---|---|
@onion iniciar projeto | Primeiro acesso, cada nova sessão | IA apresenta o estado do projeto e o próximo passo |
@product | Início da Descoberta | Ativa a persona de produto para mapear o problema |
@product spec | Após o Collect | Gera história de usuário, critérios de aceite e regras de negócio |
@product feature | Especificação aprovada | Gera o business-context.md como Pronto para Dev |
@meta | Precisar pesquisar ferramenta ou API | Pesquisa e cria uma KB de referência |
@engineer start | Início da PoC | IA lê os dois contextos e apresenta o que vai construir |
@engineer plan | Antes de qualquer código | Gera plano detalhado no technical-context.md para aprovação |
@engineer work | Plano aprovado | Executa o checklist e constrói a solução item a item |
@engineer finish | MVP pronto | Instruções de teste + feature marcada como Feito |
@docs sync | Antes do Demo Day | Sincroniza os arquivos — gera o dossiê de entrega |
| Fase | Entregável | Marco de fechamento |
|---|---|---|
| 1 — Descoberta | business-context.md com feature Pronto para Dev | Sprint 1 |
| 2 — PoC | PoC funcionando + plano de contingência no technical-context.md | Sprint 2 |
| 3 — MVP | MVP ao vivo + pitch 7 min + arquivos sincronizados via @docs sync | Demo Day |
@engineer plan parece complexo demais para o prazo — melhor simplificar agora do que na Fase 3Pedir ajuda cedo é parte do processo. O consultor existe para isso.