Usar só uma parte do BMAD

Você pode abrir o BMAD para uma única necessidade e encerrar o trabalho ali: sair com novas ideias, questionar uma proposta, pesquisar uma decisão, escrever um documento ou revisar uma entrega. A documentação da 6.12 afirma expressamente que as skills de pensar podem ser usadas sozinhas, sem pedir código, e que uma mudança pequena pode entrar diretamente pela construção.

Para um empresário, isso amplia bastante o uso. Uma sessão pode ajudar a pensar em formas de reduzir faltas nos agendamentos; outra pode esclarecer o benefício de um novo serviço; outra pode organizar o que pedir a um fornecedor. Esses são exemplos de aplicação propostos por esta aula, não casos de sucesso medidos nem garantias de que o BMAD conhece o seu mercado. Escolha a ferramenta pela tarefa que ela documenta e forneça o contexto do seu negócio.

Você não precisa percorrer as onze ramificações. Elas são alternativas. Nesta Aula, elas estão organizadas em Fases e Etapas para facilitar a navegação; nenhuma sequência é obrigatória. Os números servem para localizar cada uso no mapa. Se a pergunta de hoje é “como gerar ideias para uma campanha?”, terminar com ideias organizadas já pode cumprir o objetivo. Se amanhã você decidir transformá-las em um produto, poderá retomar o que ficou registrado e escolher outro caminho. A independência das ferramentas de planejamento está descrita em “Get to a Well-Defined Intent”.

Os blocos chamados Pedido de exemplo são textos para colar no chat do Claude Code, com o BMAD já instalado no projeto. O nome da skill identifica o recurso; o contexto e a solicitação em linguagem natural são exemplos desta Aula, que você deve adaptar. Quando houver opções formais, como --mode e --non-interactive na Etapa 05, elas serão identificadas e ligadas à fonte; mantenha sua grafia. A redação do exemplo não é uma sintaxe obrigatória nem uma promessa de que a sessão não fará perguntas. Comando continua sendo a linha destinada ao terminal; nenhum desses Pedidos deve ser colado no terminal. A instalação é tratada na Aula 04; a identificação das skills e sua chamada direta estão na referência oficial de skills e agentes.

No Claude Code, a chamada direta usa /nome-da-skill no campo da conversa. A pasta de skills do projeto é .claude/skills/; as instruções de cada uma ficam em seu SKILL.md. Nesta Aula, os blocos com barra inicial são Pedidos no chat, mesmo que a documentação da ferramenta use a palavra inglesa command para essa forma de chamada.

Como ler a organização. A Aula reúne o assunto; cada Fase agrupa necessidades semelhantes; cada Etapa apresenta uma opção de uso; e um Passo é uma ação dentro da opção escolhida. Pedido é o que você escreve à IA; Comando é uma instrução para executar no terminal. Essa é a convenção editorial do guia. As sete Fases desta página não são as fases oficiais do método nem uma lista que você precisa cumprir inteira.

Limite da conferência desta Aula: os comportamentos e os nomes de saída foram lidos no código instalado e comparados com as fontes oficiais indicadas junto do texto. Nenhuma dessas skills, nenhum Pedido de exemplo e nenhuma integração externa foi executada para produzir esta aula. “O que você recebe” significa a saída prevista pelas instruções, com as condições informadas; não representa arquivos gerados por uma demonstração. Os caminhos completos podem mudar com a configuração do projeto.

Como escolher por onde entrar. Complete a frase “hoje quero sair com…”. Se falta uma ideia ou uma informação para decidir, comece em Só pensar. Se já sabe o que discutir e precisa deixar isso escrito, use Só documentar. Se a mudança está definida e cabe numa sessão, veja Só construir. Se o material existe, vá a Só revisar. Se faltam regras para trabalhar num sistema já mantido, use Projeto que já existe. Para uma sessão criativa sobre experiência, estratégia, problemas ou narrativa, veja Criatividade. Essa organização é editorial; as condições e as fontes de cada escolha estão nas Etapas correspondentes.

Antes de copiar um Pedido, confira:

• A pasta aberta é a do trabalho que você quer examinar; o BMAD já está instalado ali.
• Você sabe qual problema quer resolver, o material de entrada e o resultado que espera receber.
• As situações, nomes de arquivo e preferências dos exemplos foram adaptados ao seu negócio.
• Você leu as condições de saída da Etapa escolhida; nem toda conversa produz um arquivo obrigatório.

Quatro Passos para aproveitar qualquer ramo. Esta é uma orientação de uso da Aula, apoiada na escolha da menor ferramenta necessária e na definição de intenção da documentação oficial.

1. 1

   Diga qual resultado quer levar.

   “Quero três alternativas de atendimento para discutir com a equipe” é diferente de “quero construir um novo sistema de agendamento”. No primeiro caso, ideias organizadas podem bastar; no segundo, ainda será necessário definir o que o sistema deve fazer.

2. 2

   Forneça a entrada e os limites.

   Informe o problema, quem ele afeta, o material que já existe e o que precisa ser preservado. Substitua os caminhos fictícios dos Pedidos pelos arquivos reais. Se não houver uma informação, declare a lacuna para não apresentar uma suposição como fato.

3. 3

   Use somente a Etapa que cobre a lacuna.

   Não refaça o brainstorm se a escolha já está clara; não peça a criação de um documento inteiro se precisa validar um documento existente. As Etapas mostram essas alternativas e as saídas que dependem de escolha.

4. 4

   Confira a entrega e decida se encerra.

   Leia as conclusões, veja quais evidências as sustentam e confira os arquivos efetivamente criados ou alterados. Guarde as decisões e as dúvidas que devam acompanhar o próximo trabalho. Se o objetivo foi atendido, terminar ali é um uso completo daquela parte do BMAD.

Comece pela sua necessidade e siga apenas o ramo correspondente. Quando uma ramificação apresenta várias skills, as explicações seguintes mostram qual delas cabe no seu objetivo; as setas não mandam executar todas. O último ramo depende do módulo adicional CIS, apresentado na Etapa 12 e aprofundado na Aula 07 — Brainstorm e criatividade: o módulo CIS. As fontes de cada associação entre necessidade e skill estão nas respectivas Etapas abaixo.

As quatro Etapas desta Fase são alternativas. Você pode gerar ideias, questionar uma proposta, pesquisar uma dúvida ou reunir perspectivas na ordem que fizer sentido — e encerrar depois de qualquer uma delas. A documentação oficial afirma que essas atividades não são estágios obrigatórios. Por exemplo: descobrir uma lacuna no Forge pode levar à pesquisa; uma pesquisa pode revelar que você precisa voltar ao brainstorm; uma decisão já clara pode seguir diretamente para ser documentada.

Quando serve no negócio. Você sabe onde está o incômodo, mas ainda quer abrir possibilidades: aumentar o movimento de terça-feira, reduzir faltas em agendamentos, criar uma oferta para antigos clientes ou descobrir usos para um espaço ocioso. Nesse momento, escolher logo a primeira solução pode encerrar a exploração cedo demais. A skill bmad-brainstorming conduz uma sessão para gerar opções e sair das respostas óbvias. Você pode terminar com ideias para uma reunião, uma campanha ou um teste operacional, sem transformar o resultado em software. A documentação permite usar o trabalho de ideias de forma independente; as situações de negócio deste parágrafo são exemplos didáticos.

Escolha sua participação. A mesma skill tem três posturas. Essa escolha muda quem fornece as ideias, e não apenas o tom da conversa:

Quando pular. Se já há uma direção escolhida e o que falta é registrá-la, vá à Etapa 06. Se você tem uma ideia específica, mas desconfia de uma suposição central, a Etapa 03 é mais direta. Se falta um dado sobre o mercado ou uma tecnologia, a Etapa 04 procura evidências. Brainstorm abre opções; não é uma exigência antes de todo documento ou mudança. Essa escolha decorre das situações de entrada que a documentação separa.

Você também pode querer só as técnicas. Na cópia conferida, o catálogo traz 108 técnicas em 13 categorias. A contagem é dos registros do arquivo instalado e de seu equivalente oficial; personalizações podem acrescentar ou substituir o catálogo. Há técnicas colaborativas, estruturadas, de investigação, de restrições, de cenários futuros e outras deliberadamente imaginativas. O objetivo é mudar o ângulo pelo qual você pensa, em vez de repetir “me dê mais ideias”.

Alguns exemplos mostram a variedade. A aplicação empresarial é nossa; o nome e o mecanismo de cada técnica vêm do catálogo:

A skill oferece uma página para compor a sessão e copiar a seleção de volta para o chat. Também dá para escolher pelo próprio chat: deixar o assistente propor um conjunto, navegar pelo catálogo, sortear técnicas de categorias escolhidas ou pedir técnicas inventadas para o tema. A referência sugere um conjunto de três ou quatro quando a escolha acontece pelo chat. A orientação da geração é ir além das primeiras respostas e mirar mais de cem ideias; isso é uma direção de trabalho, não uma promessa de quantidade ou qualidade para qualquer sessão.

Pedido — exemplo para colar no chat do Claude Code. O texto depois de /bmad-brainstorming é um exemplo de contexto e preferência, não uma sintaxe obrigatória:

/bmad-brainstorming Quero gerar ideias para aumentar o movimento de terça-feira na minha empresa de serviços, sem começar oferecendo desconto. Trabalhe como parceiro criativo. Vamos escolher as técnicas pelo chat. Quero experimentar SCAMPER Method, Reverse Brainstorming e Role Playing. Primeiro vamos abrir possibilidades; depois eu peço para priorizar. Ao encerrar, quero brainstorm.html e brainstorm-intent.md com as direções que eu escolher.

O que você recebe. A sessão registra ideias, decisões e mudanças de técnica em .memlog.md, que permite retomar o trabalho. No encerramento, brainstorm.html apresenta a sessão em uma página visual; brainstorm-intent.md reúne apenas as descobertas e direções escolhidas que interessam ao próximo trabalho. Condição dos arquivos citados no panorama da Aula 02, nas sessões interativas ensinadas aqui: em Facilitator e Creative Partner, os artefatos finais são produzidos somente quando você os escolhe; em Ideate for me, o HTML é automático, enquanto o documento de intenção continua opcional. Por isso o Pedido de exemplo solicita os dois. Pela configuração padrão da skill, eles ficam em {output_folder}/brainstorming/brainstorm-{topic_slug}-{date}/; as partes entre chaves são preenchidas conforme o projeto, o tema e a data.

Pausar, retomar ou terminar são escolhas diferentes. Se a sessão foi interrompida, informe que quer retomá-la e indique a pasta ou o .memlog.md. A skill procura registros ainda não concluídos; ao retomar, lê o registro inteiro para recuperar tema, objetivo, postura, ideias e técnica em uso. Se você encerra de fato, ela marca a sessão como concluída mesmo que não peça nenhum artefato final. Assim, não é preciso gerar um HTML só para conservar o que já ficou no registro.

Você também pode encontrar o termo headless, que significa execução sem uma pessoa interagindo durante a sessão. Não é uma quarta postura, nem se ativa só porque você escreveu “gere ideias para mim”: nesse caso, com você presente no chat, a postura é Ideate for me. A execução sem interação tem instruções próprias para automações e chamadas por outras skills; ela não foi testada nesta revisão.

Para onde ir depois. Você pode encerrar e levar as ideias para sua gestão. Se quiser escolher entre elas, peça para priorizar: a skill separa geração e convergência, podendo agrupar temas ou comparar impacto e esforço, por exemplo. No modo facilitador, ela estrutura a decisão e você julga; no modo parceiro, também contribui. Se uma direção precisar virar planejamento, o documento de intenção pode alimentar bmad-product-brief, bmad-prd ou, quando já tiver detalhamento suficiente, bmad-spec. Não existe obrigação de continuar.

Esse uso merece uma Aula própria: a Aula 07 — “Brainstorm e criatividade: o módulo CIS” aprofunda as posturas, a escolha das técnicas e o panorama do módulo de criatividade. Aqui, guarde a possibilidade prática: usar o BMAD somente como parceiro de brainstorm já pode ser o trabalho inteiro que você precisava realizar.

Quando serve no negócio. Você já tem uma proposta: lançar uma assinatura, oferecer atendimento em novo horário ou criar um recurso para reduzir cancelamentos. O problema agora é saber quais suposições sustentam a ideia e o que ainda não foi decidido. A skill bmad-forge-idea examina uma ideia em conversa, uma pergunta de cada vez. Ela serve para esclarecer, confrontar ou melhorar a proposta; o resultado pode ser continuar, descartar ou simplesmente entender melhor.

Pense na hipótese de oferecer uma assinatura mensal a clientes que hoje compram ocasionalmente. A análise pode expor perguntas diferentes: quem vê valor na recorrência, qual comportamento precisaria mudar, quais compromissos a empresa assumiria e qual parte da justificativa veio de conversas reais com clientes. Esses são exemplos de questões empresariais. A skill começa pelo objetivo da sessão e distingue uma ideia nova de uma mudança em projeto existente; no segundo caso, confere as afirmações nos materiais do projeto. Termos vagos, como tratar comprador, usuário e pagador como a mesma pessoa, devem ser esclarecidos.

Quando pular ou mudar de caminho. Sem uma ideia específica, o brainstorm da Etapa 02 costuma ser a entrada mais adequada. Se a pergunta é factual — por exemplo, “há demanda suficiente neste segmento?” —, a pesquisa da Etapa 04 fornece outro tipo de insumo. Se a proposta já está clara e escolhida, você pode ir ao documento da Etapa 06 ou 07. Para uma mudança em negócio ou produto existente, forneça os materiais que sustentam a situação atual: a instrução do Forge é examiná-los, sem aceitar um rótulo ou resumo como prova. Esses caminhos não dependem de o projeto ser pequeno ou grande; dependem do que ainda falta decidir.

Você pode pedir “attack this”, para procurar contradições e fragilidades; “defend this”, para defender a versão mais forte; ou “switch roles”, para mudar os papéis. A condução usa uma perspectiva do conjunto de agentes ou personas disponíveis e outra criada para o assunto, como comprador, concorrente ou responsável financeiro. Por padrão, essas vozes são interpretadas pelo próprio assistente; não significam pessoas reais consultadas nem, automaticamente, revisões independentes de outros agentes.

Essa composição de duas vozes é o funcionamento usual. Você também pode pedir uma conversa com uma única persona ou chamar um grupo salvo; se já havia um agente ativo quando o Forge começou, ele permanece como voz principal. A escolha serve para examinar a dúvida por uma perspectiva útil, e não para obrigar você a conhecer todos os personagens do BMAD.

Pedido — exemplo para colar no chat do Claude Code. Tudo depois do nome da skill é um exemplo de contexto, objetivo e limite:

/bmad-forge-idea Quero testar a ideia de uma assinatura mensal para os clientes que hoje compram meus serviços de forma avulsa. É uma ideia nova. Minha hipótese é que a recorrência aumenta a previsibilidade da receita, mas ainda não ouvi clientes sobre ela. Comece por attack this. Examine as suposições sobre adesão, frequência de uso e compromissos que eu assumiria. Quero decidir se vale fazer um teste pequeno com clientes; não quero iniciar a construção de um sistema.

O que você recebe. A configuração padrão cria a pasta {output_folder}/forge/{slug}/, com o identificador da ideia no lugar de {slug}. .memlog.md guarda o registro da conversa, incluindo decisões, suposições e fragilidades. No encerramento, a skill prevê forge-report.html em todos os três resultados. O arquivo forged-idea.md depende de haver uma ideia consolidada para passar adiante: deve conter, de forma curta, as decisões, opções rejeitadas e razões necessárias ao próximo trabalho.

Para onde ir depois. Pode bastar registrar por que você decidiu não seguir. Se a ideia resistir, mas depender de fatos que ninguém verificou, leve a pergunta a bmad-deep-recon. Se já houver intenção suficiente para planejar, forged-idea.md pode servir de entrada para bmad-spec, bmad-prd ou bmad-prfaq. A skill também oferece o arquivo a bmad-build quando disponível; isso só faz sentido se o trabalho couber no caminho de construção explicado na Etapa 08 desta Aula e na Aula 02. O próprio Forge orienta que a conversa não seja empurrada para “vamos construir?”.

Aqui, testar a ideia é examinar o raciocínio e as decisões. A conversa não substitui descobrir se clientes de fato comprariam, se uma operação suporta a oferta ou se os números se confirmam. No exemplo da assinatura, “a hipótese ficou mais clara” e “clientes aceitaram a oferta” são evidências diferentes. Essa é a distinção didática entre a atividade de questionamento descrita pelo Forge e a obtenção de evidências descrita no Deep Recon.

Quando serve no negócio. Você precisa de fatos para decidir: entrar em um segmento, comparar fornecedores, compreender reclamações sobre uma categoria de serviço ou avaliar uma tecnologia. A skill bmad-deep-recon organiza a pesquisa em torno de uma decisão. Ela não se limita a software. “Quero saber tudo sobre clínicas” é um tema; “quero decidir se vale oferecer meu serviço a clínicas pequenas desta região” dá uma finalidade à pesquisa e ajuda a escolher o que realmente precisa ser conhecido. O exemplo é didático; a orientação de partir da decisão está na documentação.

Na configuração conferida, há seis tipos de pesquisa. Você pode nomear um deles ou deixar a skill inferir o mais adequado; instalações personalizadas podem acrescentar outros. Além do tipo, há dois objetivos possíveis: Explore, para compreender e avaliar, e Select, para escolher entre candidatos. Comparar três fornecedores, portanto, é diferente de explorar um setor inteiro.

Se a decisão é escolher um fornecedor, explicite os critérios. No formato Select, a pesquisa começa separando condições obrigatórias de preferências com pesos. Em um exemplo fictício de ferramenta de agendamento, “precisa atender três unidades” pode ser uma condição obrigatória; “ser mais fácil de aprender” pode ser uma preferência. A skill deve acordar esses critérios antes de investigar candidatos, eliminar os que não atendem às condições e comparar os finalistas com fontes. Examina também custo total e custo de sair da solução, não apenas a mensalidade. A conclusão deve mostrar a pontuação, a alternativa que ficou em segundo lugar e em que situação ela seria melhor. Esses são passos previstos na referência de Select; os critérios de agendamento são apenas ilustração.

Escolha como obter a pesquisa. Os três modos resolvem situações diferentes. Essa distinção importa para você saber se está recebendo um Pedido pronto ou uma pesquisa concluída:

Quando pular uma pesquisa nova. Se já tem um relatório, entregue-o a Process em vez de pesquisar tudo novamente. Se um relatório do próprio Deep Recon está quase suficiente, use Deepen — aprofundar para investigar só a lacuna, ou Refresh — atualizar para conferir afirmações que envelheceram. Se não falta evidência e a decisão já está tomada, você pode seguir ao documento apropriado. Para uma dúvida pequena, Run prevê uma pesquisa focada, sem obrigar a divisão em muitas frentes; para uma decisão ampla, ele pode distribuir perguntas entre assistentes. O tamanho da empresa não determina sozinho o esforço: a extensão da pergunta e o que depende da resposta são mais úteis para fazer esse recorte.

Pedido — exemplo para colar no chat do Claude Code. O texto depois do nome da skill é um exemplo de decisão, recorte e preferência:

/bmad-deep-recon Quero uma pesquisa do tipo market, no modo Run, para decidir se vale testar uma oferta de gestão de agendamentos para pequenas empresas de serviços no Brasil. Investigue segmentos, problemas relatados e alternativas já usadas. Separe evidências de hipóteses, registre fontes e datas e admita o que não for possível verificar. Use esforço standard. Apresente o plano para minha aprovação antes de começar a pesquisa.

Se você já usa uma ferramenta externa de pesquisa, pode trocar a solicitação por este outro Pedido de exemplo:

/bmad-deep-recon Use Draft para preparar um Pedido de pesquisa sobre a mesma decisão: testar uma oferta de gestão de agendamentos para pequenas empresas de serviços no Brasil. Quero executá-lo em outra ferramenta. Inclua perguntas, fontes exigidas, datas e lacunas a investigar. Depois trarei o relatório para Process.

O modo Run separa esforço de verificação. Os níveis quick, standard e deep regulam a quantidade de trabalho da pesquisa; normal, high e max regulam o rigor de conferência. No padrão normal, há checagem das afirmações que sustentam a decisão, e não uma revisão exaustiva de toda frase. Escolher deep não equivale, por si só, a escolher max. A definição desses controles está nas instruções, mas não medimos consumo, duração ou qualidade em uma execução real.

O que você recebe. A configuração padrão organiza cada assunto em {planning_artifacts}/research/{research_type}-{topic_slug}-{date}/. Draft salva brief.md; uma pesquisa concluída ou processada entrega research.md, com síntese voltada à decisão, achados, fontes, recomendações e indicação do que envelhece e precisa ser revisto. A pasta também comporta o registro .memlog.md, materiais importados e notas extraídas, conforme o modo. Quando o formato está em auto, a conclusão de uma pesquisa interativa também apresenta research-briefing.html, a versão visual do mesmo relatório; execuções sem interação e chamadas por outra skill dispensam esse HTML por padrão. Outros ajustes de formato podem mudar essa condição.

Para onde ir depois. Você pode usar o relatório apenas para tomar a decisão e encerrar. Se o produto continuar adiante, research.md pode alimentar o briefing ou o PRD. Se a evidência for insuficiente, há caminhos para aprofundar uma área, atualizar afirmações que envelheceram ou pesquisar apenas a lacuna restante. Também é possível combinar Draft, pesquisa externa e Process, sem executar Run para todo o assunto.

O cuidado empresarial é ler também o que ficou sem resposta. A skill instrui o assistente a sustentar conclusões em evidências recuperadas ou importadas naquela pesquisa, a não tratar a memória do modelo como prova e a admitir dados fracos ou ausentes. Os documentos do seu projeto ajudam a definir a pergunta; não provam automaticamente a resposta. Um relatório com fontes continua precisando ser examinado, especialmente se a decisão depender de uma afirmação marcada como incerta.

Como conferir antes de usar a conclusão. Procure a decisão que o relatório pretende apoiar, os critérios usados, as fontes com datas e as perguntas que permaneceram abertas. As instruções distinguem afirmações verified — verificadas, disputed — contestadas por fontes divergentes, unverified — sem confirmação independente dentro do esforço disponível e overturned — contrariadas pelas evidências. “Não verificado” não significa automaticamente falso; significa que você não deve tratar aquela afirmação como confirmada. Quando fontes divergem, o relatório deve mostrar a divergência, com as fontes de cada lado, sem inventar uma média para apagar o problema. É especialmente útil conferir se a recomendação depende justamente de um ponto incerto.

Situação de negócio. Uma decisão envolve prioridades que não cabem em uma única resposta: facilitar a compra pode aumentar o trabalho do atendimento; acelerar o lançamento pode deixar pendências; automatizar tudo pode custar mais do que o problema justifica. bmad-party-mode reúne perspectivas em uma mesma conversa, com personagens que respondem uns aos outros, discordam e levantam consequências. Você conduz o assunto e pode chamar uma voz para aprofundar um ponto. A documentação indica esse uso para decisões com escolhas difíceis, geração de ideias, retrospectivas e exame de planos antes de assumir compromissos.

No módulo principal do BMAD, identificado na instalação como bmm, os cinco agentes com nome são estes. As perguntas da última coluna são exemplos didáticos de como suas especialidades podem ajudar o empresário; não são falas registradas em uma execução.

A composição da conversa depende dos módulos instalados; outros módulos podem acrescentar agentes. Os recursos criativos do CIS aparecem no panorama da Etapa 12 e na Aula 07.

Pedido de exemplo para colar no chat do Claude Code. O nome da skill é bmad-party-mode; o texto depois dele é um exemplo.

/bmad-party-mode Quero conversar com a analista de negócios (Mary), o gerente de produto (John), o arquiteto de sistemas (Winston), a engenheira de software sênior (Amelia) e a designer de experiência de uso (Sally) sobre permitir que o cliente remarque sozinho o horário de um serviço. Hoje a recepção faz tudo por telefone. O objetivo é diminuir esse trabalho sem gerar horários vazios ou reservas duplicadas. Debatam as escolhas, os riscos e as dúvidas que precisamos resolver. Quero ouvir os pontos de discordância e decidir a próxima ação; por enquanto, vamos ficar na discussão.

O que significa “vários especialistas”. Os nomes representam papéis e maneiras de examinar o problema. No modo padrão, chamado session, um único modelo de IA interpreta todas as personas na mesma conversa. Portanto, ver cinco nomes respondendo não demonstra que cinco execuções independentes analisaram o tema. Os outros modos mudam esse funcionamento: auto usa agentes separados quando isso é relevante para a rodada; subagent coloca um agente separado por persona nas rodadas de conteúdo; e agent-team mantém uma equipe persistente que conversa entre si, com suporte específico no Claude Code.

Separar agentes não exige usar modelos diferentes: a implementação permite configurar o modelo por membro ou escolher um modelo para a sessão inteira. A documentação também alerta para maior custo nas análises independentes e prevê retorno a modos mais simples quando o recurso pedido não estiver disponível. A disponibilidade desses modos no Claude Code não foi testada nesta revisão. Na documentação oficial do Claude Code consultada nesta revisão, as equipes de agentes são um recurso experimental e vêm desabilitadas por padrão.

Se quiser solicitar agentes separados, o Pedido de exemplo pode começar assim. --mode subagent é uma opção documentada; a frase seguinte continua sendo exemplo de negócio.

/bmad-party-mode --mode subagent Examine com a analista de negócios (Mary), o gerente de produto (John) e a designer de experiência de uso (Sally) as vantagens, perdas e hipóteses de permitir remarcação pelo próprio cliente. Quero que cada perspectiva faça sua primeira análise antes de discutir as demais.

O que você recebe. O resultado principal é a conversa. Por padrão, ela continua até você indicar que terminou; responder à pergunta de abertura não encerra a sessão. Ao encerrar, a skill retoma os melhores pontos e oferece um registro em HTML: um arquivo .html com data no nome, salvo por padrão em {output_folder}/party-mode/. O código não fixa um nome único para esse HTML, e a oferta pode ser recusada. Não há promessa de que a discussão gere automaticamente um PRD, uma spec ou uma decisão aprovada.

Se você quer uma única discussão com fim definido. A opção documentada --non-interactive manda atender ao objetivo informado e encerrar naturalmente, liberando os agentes separados que tenham sido usados. Ela é diferente de --mode: uma controla se haverá interação contínua; a outra controla como as personas raciocinam. Não é preciso escolher uma equipe persistente só para obter uma análise única. O exemplo a seguir foi conferido nas instruções e não foi executado.

Pedido — exemplo de discussão única:

/bmad-party-mode --mode session --non-interactive Discuta com a analista de negócios (Mary), o gerente de produto (John) e a designer de experiência de uso (Sally) a proposta de permitir remarcação pelo próprio cliente. Examine benefícios, riscos e fatos que ainda precisamos conhecer. Ao concluir, apresente os melhores pontos e as divergências que sobraram. Não trate a conversa como aprovação da proposta.

Há ainda uma memória opcional por grupo. Na configuração padrão, a conversa com os agentes instalados usa {output_folder}/party-mode/memories/installed/.memlog.md para guardar alguns acontecimentos e decisões úteis para sessões futuras. Isso não é a transcrição completa nem substitui o documento de decisão do negócio. Grupos nomeados seguem sua própria configuração; um elenco improvisado no Pedido não tem essa memória até ser salvo como grupo.

Um cuidado ao interpretar a mesa. O debate ajuda a examinar escolhas, mas concordância entre personagens não comprova uma hipótese. A própria documentação distingue o grupo Code Review Crew, voltado a debater código, de uma revisão que verifica e organiza os problemas encontrados. Para esse segundo objetivo, use as skills de revisão da Etapa 10. O mesmo cuidado vale para personagens que representem clientes: a conversa é uma simulação de perspectivas, e os clientes reais ainda precisam ser ouvidos quando a decisão depende deles. A recomendação sobre ouvir clientes reais é a aplicação desse limite ao exemplo de negócio.

Para onde ir depois. Você pode parar quando a discussão já ajudou a decidir. Também pode pedir uma síntese das escolhas para levar à equipe, transformar a direção em brief ou PRFAQ, ou escolher os documentos de planejamento da Etapa 07. Se só uma perspectiva continuar útil, converse diretamente com o agente correspondente; não é necessário manter a mesa inteira. A distinção entre chamar uma skill diretamente e trabalhar pela conversa com um agente está documentada em “Skills vs. Agent Menu Triggers”.

Quando pular. Se você já sabe qual resultado quer produzir, pode chamar a skill responsável diretamente. Para obter evidências, use a Etapa 04; para um documento de planejamento, a Etapa 06 ou 07; para problemas verificados em uma mudança, a Etapa 10. Reserve a mesa para situações em que confrontar prioridades ajude a decisão. Em uma pergunta bem delimitada, uma conversa com apenas o agente pertinente pode bastar. Essas são aplicações do critério oficial de usar Party Mode para discutir escolhas e das diferenças entre discussão, skill e revisão.

Situação de negócio. Você já consegue explicar a ideia, mas ela ainda vive em conversas, áudios e anotações. Um sócio entende que será um aplicativo; outro imagina um serviço de atendimento; a equipe ouviu que haverá automação, mas não sabe o que mudará para o cliente. Antes de discutir telas, orçamento de desenvolvimento ou fornecedores, você quer um documento que diga qual problema merece atenção, para quem e com qual resultado esperado. É possível encerrar o trabalho nessa visão escrita. A documentação apresenta o brief e o PRFAQ como duas entradas de planejamento, escolhidas pelo propósito e pelo grau de questionamento desejado.

Quando usar bmad-product-brief

O brief de produto é uma apresentação enxuta da visão: o problema, a solução proposta, quem será atendido, o que diferencia a proposta, como reconhecer o sucesso e o limite da primeira versão. A skill cria, atualiza ou valida um brief existente. A estrutura se adapta ao propósito; a orientação é chegar a cerca de uma ou duas páginas no documento principal, preservando em um complemento os detalhes que mereçam continuar disponíveis. Isso descreve o tamanho pretendido para o artefato da skill, não um limite para a profundidade desta Aula.

Imagine uma rede de assistência técnica que quer oferecer acompanhamento dos consertos pelo celular. O brief ajuda a registrar que o problema é a falta de informação durante o atendimento; que o público inicial são os clientes que já deixaram um aparelho; que o resultado esperado é permitir consultar o andamento; e que a primeira versão não inclui pagamento, venda de acessórios nem atendimento por vídeo. Essas escolhas são exemplos para esta Aula. O valor do documento, nesse caso, está em permitir que os sócios examinem a mesma proposta e discordem de pontos concretos.

A conversa tem dois caminhos. No Fast path, o caminho rápido, a skill reúne as lacunas em uma ou duas perguntas e escreve a primeira versão com marcações [ASSUMPTION] onde precisou inferir algo. No Coaching path, o caminho guiado, trabalha com você por partes e questiona respostas pouco claras. O caminho rápido ainda pede revisão; uma hipótese marcada não vira uma decisão comprovada porque apareceu em um arquivo.

O que levar para a conversa. Reúna a explicação do problema, quem o enfrenta, por que a proposta importa e para quem o documento será apresentado. Se já houver anotações de reunião, pesquisas, uma apresentação ou um brief anterior, informe os caminhos desses arquivos. A skill deve ler o contexto existente antes de perguntar pelo que falta. O rigor acompanha o propósito: uma proposta para conversar com o sócio pede um trabalho diferente de uma apresentação para captar investimento. No exemplo da assistência, os registros das ligações podem esclarecer a dificuldade do cliente; a frase “os clientes querem um aplicativo”, sozinha, ainda é uma hipótese a examinar. A aplicação à assistência é didática, não uma pesquisa realizada.

Se a visão já está escrita. Peça atualização quando uma decisão mudou, informando o documento e o motivo da mudança. Peça validação quando quiser apenas uma crítica ao brief existente. Na atualização, a skill deve considerar o brief, o complemento, o registro da conversa e as fontes originais, expondo conflitos antes de alterar. Se a mudança transformar a proposta inteira, ela pode sugerir criar outro brief. Na validação, deve apontar trechos específicos e dizer o que não consegue avaliar. Assim você pode usar só a revisão de uma proposta, sem refazer sua descoberta.

Pedido de exemplo para colar no chat do Claude Code. O nome da skill é bmad-product-brief; o texto depois dele é um exemplo adaptável ao seu negócio, não uma sintaxe obrigatória.

/bmad-product-brief Crie comigo a visão de um acompanhamento de consertos pelo celular para nossa assistência técnica. Hoje os clientes precisam ligar para saber o andamento. Na primeira versão, eles devem consultar a situação e saber quando podem retirar o aparelho. Pagamento e venda de acessórios ficam de fora. Quero usar o caminho guiado para preparar uma proposta aos sócios. Separe o que já decidimos do que ainda é hipótese e mantenha os detalhes úteis no complemento do brief.

O que você recebe. No modo de criação, o documento principal é brief.md. Com a configuração padrão da skill, ele fica em {planning_artifacts}/briefs/brief-{project_name}-{date}/. Na mesma pasta, .memlog.md registra decisões, mudanças e hipóteses ao longo da conversa. addendum.md é produzido quando há conteúdo relevante que não cabe no brief: por exemplo, alternativas descartadas, restrições técnicas ou detalhes para o planejamento seguinte. A documentação resumida lista esse complemento junto do brief; as instruções de execução o tratam como condicional. Por isso, não conte com um addendum.md vazio apenas para completar uma lista. Se o Pedido for só validar um brief, o retorno é na conversa, sem novo arquivo separado, a menos que você peça.

{planning_artifacts}, {project_name} e {date} são valores substituídos pela configuração e pela data da execução. Eles não são trechos para copiar literalmente como nome de pasta. O nome exato do caminho pode mudar por personalização.

Para onde ir depois. Você pode levar o brief à reunião dos sócios e parar aí. Se quiser desenvolver a proposta, bmad-prd pode usar o brief e seu complemento para detalhar o que o produto precisa fazer. Se a discussão mostrar que faltam dados importantes de mercado ou concorrência, cabe voltar à pesquisa. O brief não obriga a construir e também não é pré-requisito obrigatório para iniciar um PRD.

Quando usar bmad-prfaq

O PRFAQ junta um comunicado de lançamento e perguntas frequentes. A proposta é escrever como seria anunciar o produto pronto antes de construí-lo, pelo método Working Backwards: partir do resultado desejado para o cliente e examinar o que seria necessário para chegar lá. Depois, a skill confronta a proposta com as perguntas difíceis do cliente e da própria empresa. A abordagem é mais exigente do que simplesmente organizar uma ideia em um documento.

Na assistência técnica, o comunicado imaginário teria de explicar o benefício sem se apoiar em frases como “uma plataforma inovadora”. O cliente poderia perguntar por que deveria confiar no prazo mostrado. A empresa teria de responder quem atualiza a informação, o que acontece quando uma peça atrasa e qual trabalho adicional recai sobre os atendentes. Essas são perguntas didáticas desta Aula. Elas mostram a diferença entre escrever uma promessa atraente e examinar as condições necessárias para cumpri-la.

A skill percorre cinco momentos: entendimento do cliente, do problema, da importância e do conceito; comunicado; perguntas dos clientes; perguntas internas sobre viabilidade e escolhas; e veredito. As instruções exigem pesquisa para afirmações sobre mercado, concorrência e viabilidade, além de adaptar a linguagem quando a proposta é uma ferramenta interna, e não um produto à venda. A exigência de pesquisar é um comportamento prescrito; não foi testada nesta revisão da Aula.

Quando acelerar e quando retomar a descoberta. Se você já entregar cliente, problema concreto, importância e conceito de solução, a skill pode confirmar o entendimento e seguir à elaboração do comunicado sem prolongar a descoberta. Se, após algumas trocas, ainda não for possível dizer quem tem o problema ou qual é a dificuldade, as instruções mandam sugerir bmad-brainstorming ou bmad-forge-idea. Isso evita transformar uma ideia vaga em uma promessa bem escrita que continua sem fundamento. A rapidez depende da clareza de entrada; uma apresentação bonita não substitui as respostas.

Pedido de exemplo para colar no chat do Claude Code. O nome da skill é bmad-prfaq; o texto depois dele é um exemplo de contexto e direção.

/bmad-prfaq Quero testar a visão de um acompanhamento de consertos pelo celular antes de investir. O cliente é quem deixou um aparelho em nossa assistência e precisa se organizar para buscá-lo. Hoje ele liga várias vezes porque não sabe o andamento; isso interrompe o atendimento e ainda gera insegurança. A proposta é mostrar a situação do conserto e avisar quando a retirada estiver liberada. Conduza o desafio do comunicado de lançamento e das perguntas difíceis. Questione o valor para o cliente, o trabalho da equipe e as promessas que ainda não sabemos sustentar.

O que você recebe. Ao concluir, há dois arquivos na pasta de planejamento configurada: prfaq-{project_name}.md, com o comunicado, as perguntas e respostas e o veredito; e prfaq-{project_name}-distillate.md, com contexto condensado para o planejamento seguinte. O segundo preserva alternativas rejeitadas, sinais de requisitos, restrições, questões abertas e riscos que apareceram na conversa. Ele é previsto como saída obrigatória do momento final. O veredito distingue o que está bem sustentado, o que precisa amadurecer e o que apresenta riscos ou contradições. Um arquivo concluído não significa que a ideia recebeu aprovação automática.

O comunicado descreve um futuro pretendido. Use-o como documento de trabalho. No exemplo, dizer que o cliente receberia uma previsão confiável não demonstra que a empresa já consegue produzir essa previsão; essa capacidade ainda precisa ser verificada. Essa é uma distinção editorial desta Aula entre exercitar uma promessa e comprovar uma entrega.

Para onde ir depois. Você pode usar o resultado para decidir investir, investigar uma fragilidade ou abandonar a proposta. Se continuar, o PRFAQ e seu complemento podem alimentar bmad-prd; o resumo também pode alimentar diretamente bmad-spec quando não há necessidade de PRD. Nesse caminho, o PRFAQ pode ocupar o lugar do brief: não é necessário produzir os dois só para cumprir uma sequência.

As duas primeiras opções podem questionar a ideia. A diferença está na forma e na intensidade do trabalho: o brief organiza e desenvolve a visão; o PRFAQ a submete ao desafio do anúncio e das objeções.

Conferência antes de encerrar a Etapa. Esta é uma checagem editorial para usar os resultados descritos acima:

• O documento diz quem tem o problema e qual mudança se espera para essa pessoa.
• As hipóteses aparecem como hipóteses; promessas de resultado têm evidência ou uma investigação pendente.
• Você sabe quais arquivos guardar, o que foi decidido e o que precisa amadurecer antes de investir.

Quando serve no negócio. Você quer comparar propostas de fornecedores, discutir uma mudança com os sócios, alinhar atendimento e operação ou deixar uma iniciativa preparada para outro momento. O resultado desejado agora é um acordo escrito. A documentação oficial trata essas ferramentas como independentes: escolha as que resolvem as decisões que faltam, em qualquer ordem. Produzir os documentos não obriga você a iniciar a construção.

Imagine uma distribuidora que recebe pedidos por telefone e mensagens. Antes de contratar um portal, ela precisa combinar quem pode comprar, como o vendedor acompanha o pedido, quem autoriza uma exceção e quando o estoque fica reservado. Esse é um exemplo de aplicação empresarial do planejamento. A IA pode organizar o acordo; a empresa ainda precisa decidir se as regras representam sua operação.

As quatro skills abaixo respondem a perguntas diferentes. Não é preciso produzir os quatro documentos para demonstrar que você usou o método.

Requisitos: o que a entrega precisa permitir

Use bmad-prd quando várias pessoas precisam concordar sobre o produto. PRD significa Product Requirements Document, documento de requisitos do produto. Ele reúne capacidades e requisitos, com identificadores que permitem apontar a mesma regra nas próximas conversas. Define o que deve ser construído e por quê; a própria skill separa detalhes técnicos de implementação do texto principal. Ela pode criar um PRD, atualizar um existente ou apenas validá-lo.

No portal da distribuidora, a decisão de negócio pode ser: “O comprador acompanha se o pedido foi recebido, aprovado ou separado para entrega”. Escolher a tecnologia que armazenará esses estados é outra decisão. Um bom Pedido de requisitos explicita os públicos, as capacidades, os limites e o que ainda não foi decidido, sem preencher tudo com uma solução técnica prematura. Este é um exemplo editorial da separação que a fonte faz.

O documento distingue requisitos funcionais, o que o produto permite fazer, de requisitos não funcionais, condições que atravessam seu funcionamento. No exemplo, enviar um pedido é uma capacidade; as condições de desempenho, segurança ou disponibilidade que a empresa decidir exigir precisam ser registradas de forma verificável. Não invente números para preencher essas condições. A organização em capacidades, os identificadores estáveis e a seção separada de requisitos não funcionais estão nas instruções; os exemplos de negócio aqui são ilustrativos.

Escolha o trabalho, não apenas o arquivo. Para criar, forneça o contexto que já existe; brief e PRFAQ são entradas possíveis, sem serem obrigatórios. No caminho guiado, a skill oferece começar pela visão e pelas capacidades ou pelos percursos de pessoas concretas. Um sistema interno pode começar por “o vendedor confere as condições”; um serviço com vários públicos pode ser melhor compreendido narrando o caminho do comprador e suas interações com a equipe. Para atualizar, informe qual decisão mudou; a skill deve expor conflitos com decisões anteriores. Para validar, indique o PRD existente e peça a crítica sem alteração.

Pedido de exemplo — cole no chat do Claude Code. O texto depois do nome da skill é um exemplo adaptável.

/bmad-prd
Quero criar somente o documento de requisitos de um portal de pedidos para minha distribuidora. Hoje recebemos pedidos por telefone e mensagens. O comprador precisa enviar e acompanhar o pedido; o vendedor precisa conferir condições comerciais; a operação precisa enxergar o que foi aprovado. Separe as regras já decididas das questões em aberto, incluindo quando reservar o estoque. Vamos usar o documento para alinhar as áreas e comparar propostas. Não inicie a construção. Ao terminar, informe os arquivos produzidos e as decisões pendentes.

O que você recebe. Na criação ou atualização, o arquivo principal é prd.md; .memlog.md registra as decisões da sessão. addendum.md guarda detalhes de apoio quando houver conteúdo que pertença ali, como alternativas discutidas e restrições técnicas que não cabem nos requisitos. No uso de validação, os relatórios consolidados são validation-report.html e validation-report.md, sem alteração do PRD. As pastas podem variar com a configuração do projeto.

Para onde ir depois. Você pode encerrar com o documento e levá-lo à conversa com a equipe. Se continuar no BMAD, use bmad-ux para as decisões de uso, bmad-architecture para as decisões técnicas compartilhadas ou bmad-spec para delimitar um épico. O PRD não divide sozinho a execução em stories.

Experiência: como a pessoa usa e entende o produto

Use bmad-ux quando o percurso e a apresentação das telas precisam ser decididos antes da implementação. Na distribuidora, isso inclui como o comprador encontra um produto, percebe uma restrição de quantidade, corrige um pedido e entende se ele foi aprovado. A skill pode atuar antes do PRD, depois dele ou sozinha. Seu papel é levantar e registrar sua visão de experiência, sem tratar as preferências inventadas pelo assistente como decisões suas.

Pedido de exemplo — cole no chat do Claude Code. O texto depois do nome da skill é um exemplo adaptável.

/bmad-ux
Quero planejar somente a experiência de uso do portal da distribuidora. O comprador usa principalmente o celular e precisa encontrar produtos, montar um pedido, corrigir quantidades e acompanhar a aprovação. A identidade visual deve seguir a marca que vou fornecer. Registre o que acontece quando não há estoque, quando uma quantidade é inválida e quando o pedido aguarda análise. Quero os documentos para discutir com a equipe, sem implementar o portal. Informe os arquivos produzidos e as decisões pendentes.

O que você recebe. No caminho de criação dos documentos, DESIGN.md registra a aparência, como cores, tipografia e componentes; EXPERIENCE.md registra organização, comportamento, estados, acessibilidade e percursos de uso. .memlog.md guarda as decisões. Quando o trabalho inclui esboços ou telas de referência, os artefatos escolhidos podem ficar em wireframes/ ou mockups/; eles apoiam os documentos, e os dois documentos prevalecem se houver conflito. Uma tela ilustrativa não é um portal funcionando.

Há três maneiras de trabalhar: o caminho rápido redige os documentos com suposições marcadas; o orientado percorre as decisões com você; a preparação para outra ferramenta entrega um Pedido para produzir o design fora da sessão e incorporar o resultado depois. Portanto, não trate a escolha de encaminhar o trabalho a uma ferramenta externa como se os dois documentos completos já estivessem prontos. Essa integração externa não foi executada nesta aula.

Se já houver telas, marca ou documentos. Informe os arquivos que representam as decisões vigentes. A skill também tem modos de atualização e validação; não é preciso redesenhar tudo para revisar uma experiência. A atualização considera os documentos, as fontes e o registro da sessão, expondo conflitos. A validação examina o material sem alterá-lo. Na criação e na atualização, a revisão com vários subagentes é oferecida para você escolher se deseja executá-la e quais perspectivas usar; não é uma passagem obrigatória por todos os revisores. “Subagentes” aqui são sessões auxiliares de IA que analisam partes do trabalho.

Para onde ir depois. Você pode usar os documentos para avaliar propostas de design e discutir o atendimento. Se for construir, as decisões podem alimentar bmad-spec e o planejamento das partes. Quando a mudança apenas segue uma interface já estabelecida, talvez baste usar os padrões existentes, sem abrir uma nova sessão de UX.

Arquitetura: o que as partes precisam combinar entre si

Use bmad-architecture quando pessoas ou sessões diferentes poderiam tomar decisões incompatíveis. No exemplo, o portal, a equipe comercial e o controle de estoque precisam concordar sobre quem registra a aprovação e qual sistema é responsável pela quantidade disponível. Não é necessário escolher cada detalhe do código. A skill concentra o documento nas decisões compartilhadas que evitam divergência e pode partir de uma ideia, spec, documentação anterior ou código existente.

Pedido de exemplo — cole no chat do Claude Code. O texto depois do nome da skill é um exemplo adaptável.

/bmad-architecture
Quero somente as decisões de arquitetura necessárias para planejar o portal da distribuidora. Ele precisará conversar com o sistema de estoque existente. Ajude a definir quais decisões precisam ser comuns ao portal, ao comercial e ao estoque, especialmente a responsabilidade pelos dados e pela aprovação do pedido. Quero entender as alternativas e suas consequências para a operação antes de escolher. Não implemente integrações. Entregue o documento de arquitetura e indique as questões que ainda dependem de informação do fornecedor do estoque.

O que você recebe. O nome padrão é ARCHITECTURE-SPINE.md, acompanhado de .memlog.md. O documento registra decisões técnicas compartilhadas; o registro guarda o raciocínio e o histórico da sessão. Se você também precisar de uma explicação para sócios ou equipe, a skill pode preparar um material adicional adequado a esse público, mas isso é combinado na sessão e não tem um nome de arquivo universal.

Como ajustar o tamanho da arquitetura. Para uma mudança local que segue padrões existentes, normalmente não há motivo para abrir uma sessão separada. Para partes que serão feitas por pessoas ou sessões diferentes, registre as decisões que poderiam sair incompatíveis. O caminho guiado é o padrão: a skill apresenta alternativas importantes e suas consequências para você decidir. O caminho rápido redige com [ASSUMPTION] onde inferiu escolhas. Se já existir uma arquitetura geral e o trabalho cobrir só um épico, a arquitetura desse épico herda as decisões da geral e registra o que ela deixou aberto; uma contradição precisa ser exposta, não resolvida silenciosamente. “Épico” é um resultado maior dividido em várias entregas menores. No portal, isso permite discutir a integração do estoque sem reabrir todas as escolhas do restante da empresa. O portal é um exemplo didático.

Para onde ir depois. Você pode encerrar após alinhar as decisões. Ao continuar, a skill oferece chamar bmad-spec para incorporar a arquitetura como documento de apoio à especificação. Num projeto existente, as regras que outras sessões precisam seguir também podem alimentar bmad-project-context. A arquitetura deve acompanhar as mudanças relevantes do projeto; um documento antigo não deve substituir a investigação da realidade.

Especificação: qual é o acordo sobre uma entrega delimitada

Use bmad-spec quando a intenção já está definida e você quer registrá-la de forma utilizável por quem construirá depois. Ela concentra cinco respostas: por que fazer, quais capacidades existirão, quais restrições respeitar, o que fica fora e como reconhecer o sucesso. No portal, “receber pedidos para análise, sem cobrar pela internet” já delimita uma entrega mais claramente que “digitalizar o comercial”. A skill não substitui a descoberta do produto quando essas escolhas ainda não existem.

Pedido de exemplo — cole no chat do Claude Code. O texto depois do nome da skill é um exemplo adaptável.

/bmad-spec
Quero registrar a especificação da primeira entrega do portal: compradores cadastrados enviam pedidos para análise comercial e acompanham o estado do próprio pedido. O vendedor aprova ou devolve para correção. A separação para entrega continua no sistema atual. Pagamento on-line, cadastro aberto ao público e alteração automática de estoque ficam fora. Vou fornecer os documentos e as regras já aprovadas. Gere somente a especificação e os apoios necessários, sem construir. Se faltar uma decisão, registre a questão em aberto. Informe a pasta produzida e as pendências.

O que você recebe. SPEC.md, .memlog.md e os apoios necessários ficam, por padrão, em specs/spec-<slug>/ dentro da pasta de saída configurada. <slug> é um identificador curto do assunto, não um nome para copiar literalmente. Diagramas ficam sempre em arquivos de apoio; tabelas extensas e outros detalhes que não cabem nos cinco campos também vão para esses arquivos. Esses apoios são chamados de companions e fazem parte do acordo que a construção precisa ler. Documentos produzidos por outras skills podem continuar nas pastas de origem e ser referenciados, sem que bmad-spec passe a editá-los. stories.yaml só aparece se for feita a divisão em stories, disponível em conversa interativa; escrever a especificação não inicia uma construção.

Se a entrada ainda estiver incompleta. A skill separa falta de informação de falta de intenção. Com uma intenção aproveitável, mas incompleta, a conversa pode seguir pelo modo expresso, que registra lacunas como questões abertas, ou pelo guiado, que percorre os cinco campos com você. Quando a entrada é vaga demais para extrair um acordo, ela deve sugerir bmad-prd ou outra ferramenta de descoberta. No extremo oposto, entregar uma pilha de documentos sem selecionar o que importa também prejudica o trabalho: a orientação oficial pede condensar o material antes de levá-lo à spec. Dê os caminhos dos documentos de apoio que precisam continuar sendo lidos e um resumo das decisões, preservando as restrições importantes.

Se uma entrega não couber numa sessão. Peça a divisão em stories, partes pequenas que podem ser implementadas e conferidas separadamente. A conversa propõe uma ordem e pergunta quais partes exigem uma conferência humana antes ou depois da implementação. O resultado é stories.yaml, ao lado de SPEC.md. Se a spec mudar depois, a skill verifica se as descrições das stories continuam compatíveis e oferece refazer a divisão; atualizar SPEC.md não reescreve automaticamente essa lista. A divisão organiza um trabalho já definido. Ela não elimina decisões pendentes nem inicia cada construção por conta própria.

Para onde ir depois. Pare com o acordo escrito se esse era o objetivo. Se decidir executar, confira as suposições e as questões abertas; peça a divisão em stories quando a entrega exigir várias sessões e conduza a construção por partes. Se a intenção mudar, volte a bmad-spec: alterações manuais em SPEC.md podem ser sobrescritas quando a skill o derivar novamente do registro de decisões.

Projeto pequeno, várias entregas ou várias equipes

A quantidade de documentos acompanha as decisões que precisam ser compartilhadas. Uma equipe pequena que já concorda sobre o objetivo pode levar uma intenção bem definida diretamente à spec. Um projeto com vários épicos precisa manter as partes alinhadas ao mesmo produto; nesse caso, a orientação oficial combina documentos compartilhados, como PRD, UX e arquitetura conforme a necessidade, com uma spec por épico. O tamanho também depende do risco e das integrações, além da quantidade de arquivos.

No exemplo da distribuidora, uma mudança isolada no formulário pode precisar apenas de Build. Um portal com compras, análise comercial e integração de estoque pode exigir várias sessões, separadas sob uma spec. Se houver diferentes equipes entregando portal, faturamento e logística, elas precisam combinar as regras comuns antes que cada uma tome decisões incompatíveis. Esses são cenários ilustrativos; é a investigação do projeto que determina em qual caminho a mudança realmente cabe.

Se sua empresa já aprova documentos fora do BMAD. Leve o material existente como fonte e use criação, atualização ou validação conforme o objetivo. A documentação não exige substituir o processo da empresa. O ponto é manter claro qual documento governa cada decisão: mudança sobre o produto deve chegar ao PRD; mudança em decisão técnica compartilhada, à arquitetura; detalhe exclusivo de um épico, à spec dele. Depois, os documentos dependentes precisam ser atualizados. Use a Aula 06 quando quiser percorrer esse fluxo de ponta a ponta e a Aula 09 quando a preocupação principal for entrar num projeto existente.

Conferência antes de encerrar a Etapa. Esta checagem editorial ajuda a reconhecer um planejamento utilizável:

• Cada documento tem uma finalidade clara e responde às decisões que faltavam.
• As decisões compartilhadas não se contradizem entre requisitos, experiência, arquitetura e spec.
• As suposições e questões abertas estão visíveis; você sabe quais impedem o próximo trabalho.
• Se houver stories, a divisão e a ordem ainda correspondem à spec vigente.

Quando serve no negócio. Você já tem um sistema funcionando e quer uma mudança delimitada: acrescentar um campo ao formulário, corrigir uma mensagem enganosa ou consertar uma falha bem identificada. Use bmad-build diretamente, sem precisar passar antes por brainstorm, briefing, PRD ou uma sessão separada de especificação. A referência continua sendo um objetivo que caiba numa sessão, em poucos arquivos, considerando também o risco.

“Sem planejamento prévio” descreve sua entrada. A skill ainda investiga os arquivos e decide o caminho da execução. Se não houver lacunas importantes, ações irreversíveis ou uma mudança grande demais, ela escreve um registro mínimo e segue para implementar e revisar. Se encontrar algum desses pontos, prepara um plano mais completo, expõe as decisões abertas e espera a aprovação correspondente. Não prometa a alguém que basta pedir “sem planejamento” para pular essa análise.

Quando nem essa skill é necessária. Para uma correção óbvia e de baixo risco que você consiga conferir, como um erro de digitação em um texto, a documentação permite pedir a alteração diretamente ao assistente. Build passa a valer mais quando um defeito pode escapar à conferência e chegar à operação. “Pequeno” também não significa “sem risco”: um campo opcional pode alcançar armazenamento, integração e acesso a dados. O exemplo abaixo começa delimitado; a investigação confirma o alcance real.

Prepare a pasta e um objetivo. Antes de alterar, o fluxo confere se há mudanças ainda não registradas e se a branch, a linha de trabalho do Git, combina com o Pedido. Quando encontra alterações pendentes ou uma branch claramente incompatível, a instrução padrão manda parar e consultar a pessoa. Isso precisa ser resolvido com o histórico real do projeto; não apague trabalho para “limpar a pasta”. Se houver dois objetivos independentes, como ajustar o formulário e trocar o sistema de login, o fluxo também propõe separar ou pede uma decisão explícita sobre manter ambos. O campo e o caminho pelo qual seu valor é salvo, por outro lado, podem pertencer ao mesmo objetivo.

Pedido de exemplo — abra uma conversa nova no Claude Code e cole. O texto depois do nome da skill é um exemplo adaptável.

/bmad-build
No formulário de pedido de orçamento que já existe neste projeto, acrescente o campo opcional “Empresa”, seguindo o mesmo padrão dos demais campos. O valor precisa acompanhar o orçamento pelo caminho já usado pelos dados atuais. Não mude quem pode acessar os pedidos nem o funcionamento dos outros campos. Investigue o projeto para confirmar o alcance da mudança, implemente e confira o resultado. Se descobrir uma decisão de negócio pendente ou um impacto maior, apresente isso antes de prosseguir. Ao terminar, resuma o que mudou e o que foi verificado.

A condição “pelo caminho já usado” torna o exemplo concreto, mas não prova que o trabalho será pequeno. Se o formulário enviar dados para outro sistema que não aceita esse campo, a investigação pode revelar uma integração a combinar. O critério é o impacto encontrado no projeto, não o número de frases do Pedido.

Se aparecer um plano para aprovar. Leia o resultado proposto, o que ficará preservado e as questões abertas. No caminho completo, a skill deve resolver as questões que exigem decisão humana antes da aprovação. Então você pode aprovar e continuar, aprovar e parar ou pedir uma revisão do plano. “Aprovar e parar” deixa o registro em ready-for-dev, pronto para outra sessão de bmad-build retomar a implementação. Essa é uma saída útil quando a empresa quer fechar o plano agora e construir em outro momento. Se o caminho curto descobrir durante a implementação um impacto maior, uma decisão que falta ou uma ação irreversível, a instrução também manda interromper a implementação e voltar ao planejamento.

O que você recebe. Código alterado, o registro da implementação e o resultado das verificações realizadas. No uso avulso, o arquivo do registro segue o padrão spec-<slug>.md na pasta configurada de artefatos de implementação; se já existir um registro com esse nome, a skill retoma o que estiver em draft ou usa um sufixo nos demais casos. Esse registro da sessão não deve ser confundido com o SPEC.md de uma iniciativa maior. Questões adiadas podem gerar entradas em deferred-work.md. Quando há Git disponível e alterações para registrar, o fluxo cria um commit local; isso não publica o site nem envia automaticamente o trabalho ao repositório remoto.

A revisão faz parte do caminho padrão, inclusive do caminho curto. Ela confere os achados e separa problemas da mudança de trabalho a adiar. Isso depende das capacidades do ambiente: no caminho curto, se uma camada de revisão exigir subagentes e não for possível iniciá-los, o fluxo deve preparar os Pedidos completos dos revisores e pedir que sejam executados em sessões separadas. Portanto, não interprete uma sessão interrompida como “código já revisado”. Esse caminho alternativo foi conferido nas instruções, mas não executado nesta revisão da Aula.

Para onde ir depois. Confira se o formulário atende ao Pedido. Use bmad-walkthrough para percorrer a mudança e bmad-qa-generate-e2e-tests se precisar acrescentar testes dos fluxos já implementados. Se surgir outra alteração independente, abra uma nova sessão de construção. Se a mudança crescer, volte ao planejamento proporcional ao problema. A entrega do código não substitui a sua conferência da operação real.

Conferência antes de encerrar a Etapa. Para o exemplo, use estes critérios editoriais de aceite:

• O orçamento continua funcionando sem preencher “Empresa”, pois o campo foi pedido como opcional.
• Quando preenchido, o valor aparece onde a equipe realmente consulta os demais dados do orçamento.
• A resposta final informa quais verificações foram realizadas e quais limites ou pendências restaram.
• Você sabe se houve commit local e se ficou algum trabalho em deferred-work.md; não presume que a mudança já esteja publicada.

Situação de negócio. Você já tem uma proposta comercial, um plano de lançamento, uma política de atendimento ou um trecho de planejamento. O texto parece convincente, mas você quer descobrir o que ficou escondido: uma hipótese fraca, uma consequência indesejada ou uma pergunta que ninguém fez. bmad-advanced-elicitation oferece uma segunda passagem estruturada por esse material, usando métodos de análise escolhidos por você. O alvo padrão é a resposta mais recente da conversa; para criticar outro conteúdo, indique-o explicitamente.

Por exemplo, a empresa pretende lançar uma assinatura de manutenção com atendimento prioritário. O plano diz que “todos os assinantes terão prioridade”, mas não explica como agir quando todos pedirem atendimento na mesma semana. Uma crítica útil examina essa promessa, as regras que a sustentam e o que precisa mudar antes de ela ser apresentada aos clientes. Você não precisa iniciar um projeto de software para fazer essa revisão.

A variedade está no tipo de pergunta aplicado ao material. No catálogo instalado, Pre-mortem Analysis, ou análise prévia de fracasso, imagina que o plano deu errado e procura as causas; Assumption Audit, ou auditoria de hipóteses, enumera as suposições e examina confiança e impacto; Second-Order Thinking, ou consequências de segunda ordem, procura os efeitos que surgem depois do resultado imediato; Stakeholder Lens Rotation, ou rotação de perspectivas das partes interessadas, mostra como pessoas diferentes seriam afetadas. São exemplos de métodos presentes no catálogo, não quatro Etapas obrigatórias.

Pedido de exemplo para colar no chat do Claude Code. O nome da skill é bmad-advanced-elicitation; o texto depois dele é um exemplo. Neste exemplo, plano-assinatura.md é um arquivo de entrada fictício: substitua pelo arquivo real ou apresente o texto na conversa.

/bmad-advanced-elicitation Examine o arquivo plano-assinatura.md, com nossa proposta de manutenção por assinatura. Quero criticar as hipóteses de capacidade da equipe, a promessa de atendimento prioritário e os efeitos sobre clientes que não assinarem. Ofereça métodos adequados a esse risco, incluindo uma análise prévia de fracasso. Mostre o que cada método revelou e as alterações propostas para eu aceitar ou rejeitar.

O que acontece na conversa. A skill oferece cinco métodos adequados ao alvo. Você escolhe um ou mais, pede outras opções, consulta o catálogo completo ou decide prosseguir sem nova análise. Quando aplica um método, ela apresenta o que encontrou e as mudanças propostas, e espera você aceitar ou rejeitar. As melhorias aceitas passam a compor a versão usada na rodada seguinte. Ao terminar, a versão aprimorada volta ao trabalho que estava em andamento. O controle de aceitar ou rejeitar é parte explícita da skill, não uma aprovação adicional inventada por este guia.

O que você recebe. Descobertas, propostas de alteração e a versão aprimorada do conteúdo na conversa. Essas instruções não definem um nome ou caminho obrigatório de arquivo de saída. Se você precisar guardar a versão aceita, peça que ela seja salva no documento correto; não pressuponha que a crítica criou um relatório permanente. Quando a análise acontece dentro de outra skill, ela devolve o conteúdo a essa skill para que o trabalho continue do ponto em que parou.

Ajuste a profundidade ao material. Você não precisa transformar uma frase de proposta comercial numa longa auditoria. A instrução pede uma passagem leve para um parágrafo e um tratamento mais completo para uma decisão de arquitetura. No exemplo da assinatura, comece pelo trecho que promete prioridade; se o problema atingir preço, capacidade e regras de atendimento, amplie o alvo para o plano completo. Escolher vários métodos faz com que sejam aplicados em sequência sobre a versão já aprimorada, não produz revisões independentes do original. Para conferir o resultado, separe o que foi apenas sugerido, o que você rejeitou e o que efetivamente aceitou na nova versão.

Para onde ir depois. Você pode encerrar com o plano revisado, encaminhá-lo a uma reunião ou continuar a skill que o produziu. Se a crítica expuser uma dúvida que depende de fatos, use a pesquisa da Etapa 04. Se revelar opiniões conflitantes que mereçam debate, use a Etapa 05. A discussão também pode concluir que faltam dados do próprio negócio: a IA levantar a possibilidade de sobrecarga não mede, por si só, a capacidade real da equipe. Esse é um limite de interpretação do exemplo, não um resultado de teste.

Você recebeu uma alteração do fornecedor, quer conferir um sistema antigo ou precisa melhorar um plano que alguém já escreveu. Nada disso exige refazer o caminho desde o brainstorm. O ponto de entrada pode ser o material pronto. Mas “revisar” reúne trabalhos diferentes: procurar defeitos na mudança, criticar um documento, entender uma entrega com orientação e criar testes para voltar a conferi-la depois. O BMAD separa essas tarefas.

Procurar problemas numa mudança: bmad-code-review

Os termos do histórico. Um commit registra um estado no histórico do Git; uma branch é uma linha de desenvolvimento. No GitHub, uma pull request propõe incorporar alterações e permite discuti-las e revisá-las antes disso. A Aula 05 explica o uso de Git e GitHub; aqui, esses termos servem para identificar precisamente o trabalho que será revisado.

Situação de negócio. Uma empresa contratou uma melhoria no portal do cliente. O fornecedor entregou a alteração e informou que resolveu o cancelamento de pedidos. Antes de aceitar, você quer uma revisão concentrada no que mudou: um pedido já enviado ainda pode ser cancelado? A mudança permite cancelar pedidos de outra pessoa? O sistema mantém o estoque coerente? São exemplos de preocupações que justificam examinar o código e a intenção da entrega, sem criar um projeto novo.

A skill pode receber uma mudança identificada por arquivos, uma versão registrada no Git, uma linha de trabalho — chamada branch — ou uma solicitação de revisão no GitHub, chamada pull request ou PR. Ela identifica o alvo, prepara a comparação das alterações, confirma o contexto e aplica camadas de revisão. Os achados passam por uma conferência: a consequência apontada realmente pode acontecer naquele trecho? O que foi refutado também deve ter seu motivo registrado. Se houver especificação ou requisitos, forneça-os: sem a intenção, a revisão tem menos elementos para dizer se foi construído o que o negócio precisava.

Delimite a revisão antes de interpretar os achados. Uma lista de arquivos identifica a mudança a examinar; não significa automaticamente auditar todo o conteúdo histórico desses arquivos. Se não houver alterações para comparar, a skill pede outro recorte ou pergunta se deve ler os arquivos inteiros. Uma spec também não identifica sozinha a mudança quando não informa sua versão de partida. Em mudanças muito grandes — a referência usa aproximadamente três mil linhas de comparação como sinal — a skill oferece dividir o trabalho por grupos de arquivos. A primeira apresentação informa o tamanho da mudança, se há spec e quais documentos foram carregados; confira isso antes de seguir. Para uma entrega pequena, um alvo bem definido pode bastar. Para uma alteração grande que mistura cobrança, estoque e atendimento, dividir por responsabilidades facilita avaliar cada consequência.

Pedido — exemplo para colar no chat do Claude Code. Todo o texto depois do nome da skill é um exemplo, adaptável ao seu projeto:

/bmad-code-review Revise as alterações ainda não registradas no Git sobre cancelamento de pedidos. Estou pedindo a revisão sem uma spec. Considere como intenção que somente o dono do pedido possa cancelá-lo e que pedidos já enviados não possam ser cancelados. Mostre os achados antes de aplicar correções.

O que você recebe. Um resumo dos achados depois da conferência. patch indica uma correção de código clara; defer, uma questão separada para outro trabalho. No caminho com especificação, também pode haver decision-needed, uma escolha que depende de você. Sem uma spec, o relatório fica no chat; a skill não promete um arquivo de relatório com nome fixo. Quando o arquivo de story informado tem a seção de tarefas esperada, os achados entram em Review Findings; os itens adiados podem ser registrados em deferred-work.md, na pasta de artefatos de implementação. Essa persistência depende do contexto recebido, portanto não espere todos esses arquivos em toda revisão.

Para onde ir depois. Você pode decidir sobre as correções oferecidas, pedir nova revisão após corrigir ou usar bmad-walkthrough para entender pessoalmente a entrega. Também pode encerrar com os achados e entregá-los a quem mantém o sistema. Se o resultado mostrar que faltava uma regra do negócio, resolva a regra antes de pedir sucessivas correções. São escolhas de uso, não uma obrigação de percorrer todas as skills.

Revisar também pode atualizar registros. Quando recebe uma story, a skill pode atualizar seu estado para done ou in-progress e sincronizar sprint-status.yaml, quando esse acompanhamento existe e a story é identificada. As correções de código são apresentadas para você escolher como tratá-las. Portanto, o uso avulso da revisão não significa que todos os arquivos permanecerão intocados; o contexto de entrada determina quais registros serão escritos. O Pedido acima usa o caminho sem spec e pede que os achados sejam mostrados antes das correções.

Criticar um documento ou outro material: bmad-review

Situação de negócio. Você já tem uma proposta comercial, um procedimento interno ou o plano de implantação de um sistema. Quer localizar contradições, partes difíceis de entender ou exceções esquecidas. Nesse uso, o documento existente é o ponto de partida. A skill aceita documentos e código; as lentes aplicáveis dependem do material e das escolhas feitas na instalação. Na configuração padrão conferida, há lentes de crítica adversarial, casos de exceção, lacunas de verificação, estrutura e redação.

Para um texto, as lentes editoriais de estrutura e redação examinam como a informação está organizada e expressa. Para um plano que define comportamento, a lente de casos de exceção pode examinar caminhos esquecidos: o que acontece se o cliente cancelar, se faltar estoque ou se uma aprovação não chegar? Pedir explicitamente as lentes permite concentrar a análise no que você precisa. As lentes editoriais propõem mudanças; não recebem autorização para mudar o conteúdo do documento por conta própria.

Pedido — exemplo para colar no chat do Claude Code. Todo o texto depois do nome da skill, inclusive o caminho do arquivo, é um exemplo:

/bmad-review Faça a revisão de documentos/plano-de-atendimento.md com as lentes de estrutura, redação e casos de exceção. O público é a equipe de atendimento. Quero localizar instruções ambíguas e caminhos esquecidos, especialmente quando o cliente pede cancelamento. Apresente propostas antes de qualquer alteração.

O que você recebe. Achados agrupados por lente, explicando onde está o problema, em que condição aparece, que ajuste foi sugerido e qual consequência pode ocorrer. Lentes editoriais podem usar tabelas próprias. O formato pode ser Markdown, JSON — uma estrutura de dados legível por programas — ou ambos. Na configuração padrão conferida, a entrega fica no chat e não há nome obrigatório de arquivo; um relatório só é salvo no caminho configurado em report_path.

Para onde ir depois. Você pode aceitar algumas propostas, ajustar o material com a equipe e parar. Se o problema for a própria premissa do plano, cabe voltar a uma conversa de aprofundamento. A diferença prática em relação a bmad-advanced-elicitation é o ponto de apoio: a elicitação reaplica um método de raciocínio para melhorar uma resposta; bmad-review organiza uma revisão do material em achados por lentes. Um uso não obriga o outro.

Entender antes de aceitar: bmad-walkthrough

Situação de negócio. A equipe diz que terminou a regra de cancelamento, mas você quer saber o que de fato mudou antes de aprovar. Ler os arquivos em ordem alfabética não ajuda a entender o caminho do cliente. A skill organiza a explicação pela intenção e pelo funcionamento: por que a mudança existe, quais decisões a sustentam, onde um erro teria mais impacto e como você pode observar o resultado. É uma revisão conduzida com a pessoa, não um parecer que decide por ela.

O que fornecer. Indique uma branch, um commit ou um PR que represente a entrega e, se houver, a spec que explica sua intenção. A orientação procura esses alvos e usa a versão de partida da spec, a comparação da branch com a principal ou, como alternativa informada, o último commit. A referência desta versão não documenta o mesmo seletor de alterações ainda não registradas que existe em bmad-code-review; por isso, o Pedido abaixo usa uma branch identificada. Confira na abertura qual mudança entrou no percurso, especialmente se a branch tiver outras entregas.

Pedido — exemplo para colar no chat do Claude Code. melhoria-cancelamento é uma branch fictícia; substitua pelo alvo real. Todo o texto depois do nome da skill é um exemplo:

/bmad-walkthrough Guie minha revisão da branch melhoria-cancelamento, que contém a entrega sobre cancelamento de pedidos. Explique primeiro o que muda para o cliente e para a equipe. Mostre os pontos de maior impacto e como conferir manualmente os comportamentos esperados.

O que você recebe. Uma conversa guiada em cinco Passos: orientação, percurso da mudança, atenção aos detalhes, observações de teste e decisão final. Há referências a arquivos e linhas para quem quiser aprofundar. O Passo de testes mira de duas a cinco observações manuais numa mudança típica, com ações e resultados esperados; essa faixa é uma orientação, não uma quantidade garantida. Quando não há comportamento observável, a instrução é dizer isso e não inventar uma demonstração. Não é a execução de uma bateria de testes, e as instruções padrão não estabelecem um arquivo final obrigatório. A conclusão pede seu julgamento: aceitar, retrabalhar ou discutir mais.

Com ou sem um percurso preparado. Se a spec já trouxer Suggested Review Order — uma ordem sugerida de revisão —, ela serve de orientação. Caso contrário, a skill tenta montar um percurso a partir da mudança e do contexto. Você não precisa produzir outra spec apenas para obter essa explicação; sem spec, porém, a intenção pode precisar ser inferida, e a instrução manda sinalizar essa inferência. Esse é um bom momento para corrigir a compreensão do assistente antes de avaliar detalhes.

Para onde ir depois. Leve dúvidas de funcionamento à equipe, peça correções, solicite uma revisão de código ou aceite o resultado quando tiver elementos para isso. Para o empresário, o ganho é tornar a decisão concreta: “eu conferi como cancela e como libera o estoque” é diferente de “o assistente disse que terminou”. Este é o propósito didático do exemplo, não a afirmação de que esses comportamentos foram testados nesta aula.

Criar testes para o funcionamento pronto: bmad-qa-generate-e2e-tests

Situação de negócio. O agendamento já funciona. Agora você quer reduzir o risco de uma mudança futura quebrar a reserva ou o cancelamento sem ninguém perceber. Um teste de ponta a ponta percorre um caminho de uso e confere seu resultado. Um teste de API verifica a comunicação com um serviço do sistema. A skill gera esses testes a partir de funcionalidades implementadas; usa os recursos de teste que o projeto já possui e, se não houver nenhum, sugere uma ferramenta adequada.

Escolha a entrada e confira o alcance. A documentação recomenda começar uma conversa nova. Você pode indicar uma funcionalidade, uma pasta ou pedir que a skill descubra o que ainda está sem testes. Testes de API entram quando há serviços aplicáveis; testes de ponta a ponta entram quando há uma interface para percorrer. Um sistema que só oferece API não precisa receber uma tela fictícia para justificar testes de interface. No exemplo, confira se os casos descritos no Pedido já existem e qual regra define uma reserva válida: o teste precisa verificar uma decisão conhecida do negócio.

Pedido — exemplo para colar no chat do Claude Code. Todo o texto depois do nome da skill é um exemplo:

/bmad-qa-generate-e2e-tests Crie testes para os fluxos já implementados de reservar e cancelar um horário. Cubra a reserva válida, a tentativa de reservar um horário ocupado e o cancelamento permitido. Use o padrão de testes existente e informe o que ficou sem cobertura.

O que você recebe. Arquivos de teste no diretório tests/ do projeto e o resumo tests/test-summary.md dentro da pasta configurada para artefatos de implementação. Os nomes específicos dos arquivos de teste dependem da funcionalidade e da ferramenta existente; não são nomes universais do BMAD. A instrução da skill inclui executar os testes e corrigir falhas, mas isso precisa ser confirmado na sessão real. O escopo padrão é simples: o caminho esperado e alguns erros importantes. Gerar esses testes não constitui uma revisão completa do código nem prova que todas as situações foram cobertas.

Para onde ir depois. A equipe pode incorporar os testes à verificação automática do projeto, acrescentar os casos que ficaram faltando e revisitar o risco quando o funcionamento mudar. Você também pode usar só essa geração inicial de testes. Não é necessário adotar todo o acompanhamento de projetos do BMAD para começar por uma funcionalidade pronta.

Quando o projeto pede mais. O caminho incorporado ao BMM serve à cobertura simples de uma funcionalidade pronta. Se o trabalho exigir uma estratégia de testes por risco, preparação mais complexa dos dados ou avaliação abrangente da cobertura, a documentação encaminha para o módulo opcional Test Architect, o TEA. Isso é uma decisão de necessidade; não é requisito para rodar os primeiros testes. A Aula 11 — “Módulos avançados: Builder, Test Architect e Loop” trata desse aprofundamento. Antes de encerrar esta Etapa, confira quais testes foram criados, quais realmente rodaram e o que o resumo declara como não coberto.

Situação de negócio. Sua empresa já tem um sistema. Uma nova pessoa, um fornecedor ou um assistente de IA começa a trabalhar nele e repete erros que a equipe conhece: altera uma pasta que não deve ser tocada, usa o procedimento errado de teste ou ignora uma regra importante de integração. O problema não é falta de ideias para o produto; é a necessidade de transmitir as regras que orientam o trabalho naquele projeto.

bmad-project-context examina as instruções existentes e o repositório, verifica o que consegue nos arquivos e pede à pessoa o que uma leitura do código não revela: áreas congeladas, exigências da empresa, motivos de uma restrição e erros observados. Seu objetivo é um conjunto pequeno de instruções úteis aos agentes. A documentação recomenda usá-la quando essas instruções faltam, ficaram antigas ou precisam de avaliação; se a equipe já mantém instruções adequadas, é possível começar a mudança sem passar por essa skill.

Pedido — exemplo para colar no chat do Claude Code. Todo o texto depois do nome da skill é um exemplo:

/bmad-project-context Quero preparar este sistema de pedidos para trabalho com IA. Examine as instruções já existentes, preserve as regras da equipe e verifique o que o repositório já informa. A integração de emissão de notas está congelada. Mostre a proposta completa de instruções antes de gravá-la.

O que você recebe. A saída principal da versão conferida é um bloco no arquivo AGENTS.md, na raiz do projeto, entre os marcadores <!-- bmad:context --> e <!-- /bmad:context -->. O bloco inclui a data e a versão do código contra a qual foi verificado. A skill mostra a proposta antes da escrita e, quando está adotando instruções existentes, também mostra o destino e o motivo de cada mudança proposta. Para o Claude Code, pode propor e conferir a referência @AGENTS.md dentro de CLAUDE.md. Ela não faz um commit — o registro definitivo das alterações no Git — por conta própria.

Atenção ao nome do arquivo. Nesta versão, bmad-project-context não significa “gerar obrigatoriamente project-context.md”. Esse arquivo pertence a caminhos anteriores; se já existir, a skill pode propor aproveitar seu conteúdo. A saída atual de referência é o bloco em AGENTS.md. O valor também não está em repetir uma descrição extensa do sistema: a documentação pede as regras que a IA precisa receber e que não consegue simplesmente deduzir lendo os arquivos.

A referência @AGENTS.md citada acima usa o mecanismo de importar outro arquivo em CLAUDE.md, documentado pelo Claude Code. Ela é uma possibilidade prevista nas instruções do BMAD 6.12.4; a skill deve conferir como a ferramenta carrega as instruções no projeto real. Não se trata de uma afirmação de que todas as versões do Claude Code exigem essa referência.

Você pode voltar à mesma skill em momentos diferentes. Preparar serve quando não há instruções úteis; adotar, quando já existem instruções a preservar e melhorar; atualizar, quando o projeto mudou; registrar, quando apareceu um erro observado que vale transformar em orientação; auditar, quando as instruções parecem desatualizadas ou excessivas. Esses usos correspondem a setup, adopt, refresh, record e audit, mas o Pedido pode explicar a necessidade em linguagem comum.

Preservar também faz parte da entrega. Ao adotar instruções existentes, a skill mantém um registro do que cada uma se tornou: permaneceu, foi reescrita, mudou de lugar, será automatizada ou teve remoção proposta, sempre com justificativa. Uma regra que ficou em outro arquivo precisa continuar sendo encontrada pela ferramenta; mudar de lugar e deixar de ser lida não é preservação. O código permite propor uma correção fora dos marcadores do bloco quando ela é mostrada e resolvida nesse registro; portanto, não interprete os marcadores como garantia de que nenhum outro arquivo poderá aparecer na proposta. Para conferir, procure especialmente as restrições que a equipe já mantinha e as referências necessárias para carregá-las.

Projeto pequeno e projeto com várias partes. Num sistema pequeno, as regras podem caber no arquivo da raiz. Num repositório que reúne componentes separados, a skill primeiro delimita quais serão cobertos. Um componente só recebe seu próprio arquivo quando tem regras exclusivas e substanciais, essa separação reduz o bloco principal e foi verificado que as ferramentas realmente carregam as instruções naquele local. Regras que precisam valer antes de entrar numa pasta continuam na raiz. Essa escolha evita tanto um documento gigante quanto vários arquivos que ninguém lê. São condições da própria skill, não uma exigência para dividir todo projeto grande.

Manter não é acumular avisos. Registre um erro observado com sua correção e evidência; o código diferencia uma ocorrência isolada de uma falha recorrente ou custosa. Se uma verificação automática puder impedir o erro, a skill propõe essa verificação. Ao auditar, ela também não deve apagar uma regra apenas porque faz tempo que ninguém a descumpre: a condição que a justificava pode continuar existindo. Para o exemplo da emissão de notas, o fim da restrição precisa ser confirmado; ausência recente de problemas não descongela a integração.

Para onde ir depois. Você pode parar com as instruções preparadas e continuar o trabalho com sua equipe. Para uma mudança pequena, o próximo uso possível é bmad-build. Para uma alteração que exige várias sessões, pode preparar uma bmad-spec. Se surgir uma decisão importante sobre como partes do sistema devem funcionar juntas, cabe bmad-architecture. A preparação do contexto ajuda a respeitar o sistema existente; não exige reconstruí-lo nem iniciar todo o planejamento do zero.

A Aula 09 — “BMAD em um projeto que já existe” continua esse assunto. Esta Etapa preserva o uso avulso de contexto; você pode encerrar aqui se já obteve as instruções de que precisava.

O CIS, sigla de Creative Intelligence Suite, acrescenta caminhos para pensar serviços, estratégia, problemas e histórias. Ele é um módulo opcional, separado do núcleo do BMAD. O brainstorm apresentado na Etapa 02 já está no núcleo; não é necessário instalar o CIS só para usar bmad-brainstorming. Aqui fica o panorama. A Aula 07 — “Brainstorm e criatividade: o módulo CIS” aprofunda as técnicas, a escolha do caminho e a condução das sessões.

Conferência deste panorama. As quatro skills abaixo estão presentes na instalação local. O CIS instalado é a versão v0.3.2, cuja fonte oficial foi conferida separadamente; esse número não é a versão do BMAD. Os nomes, comportamentos e arquivos abaixo vêm dos respectivos SKILL.md, iguais aos instalados em .claude/skills/. {date} representa a data gerada pela sessão; os arquivos ficam na pasta de saída configurada no projeto ({output_folder}). Não foram executadas sessões do módulo para escrever esta Aula.

Escolha um fluxo e prepare suas informações. Os quatro caminhos são alternativas, não quatro Etapas de uma sequência. A chamada direta da skill de fluxo já inicia o trabalho correspondente; os agentes criativos e seus menus são outra forma de entrada, aprofundada na Aula 07. Em todos os quatro fluxos, as instruções mandam salvar o documento à medida que suas partes são produzidas e fazer pausas para a pessoa revisar, continuar ou chamar elicitação ou party mode. Assim, encontrar o arquivo na pasta não prova que a sessão terminou: ele pode conter apenas as partes já trabalhadas. Ao retomar ou entregar o material à equipe, confira o que ficou preenchido e o que continua pendente.

Design thinking: entender a experiência antes de escolher a solução

Situação de negócio. Clientes abandonam o cadastro de um serviço e a empresa ainda não sabe em qual dificuldade deve concentrar o esforço. bmad-cis-design-thinking conduz um percurso centrado nas pessoas: entender sua experiência, definir o problema, gerar opções, preparar protótipos e planejar testes com usuários. A saída prevista é design-thinking-{date}.md, com o desafio, aprendizados, conceitos, proposta de protótipo, plano de teste e próximos passos. Um plano de teste escrito não significa que clientes reais já participaram.

O que fornecer e como conferir. Informe quem encontra a dificuldade, quais observações já existem, os limites de recursos e o que seria melhorar a experiência. Um protótipo é uma representação simples feita para aprender antes de investir na solução inteira: no exemplo, poderia ser uma simulação do cadastro. O fluxo ajuda a definir o mínimo necessário e o que se quer aprender. No documento, confira se observações, suposições, plano de teste e retorno de pessoas reais estão distinguíveis; se o teste ainda não ocorreu, essa lacuna deve continuar explícita.

Pedido — exemplo. Todo o texto depois do nome da skill é um exemplo:

/bmad-cis-design-thinking Quero entender por que clientes abandonam o cadastro da nossa assistência técnica. Ajude a organizar o que precisamos observar, definir o problema e preparar uma forma simples de testar melhorias com clientes reais.

Depois: usar o plano para observar clientes, testar uma proposta de atendimento e decidir o que melhorar. O resultado pode ficar no processo da empresa, sem virar software. A condução detalhada fica na Aula 07.

Estratégia de inovação: explorar outra forma de criar e entregar valor

Situação de negócio. Uma empresa de manutenção vive de chamados avulsos e quer avaliar um serviço recorrente. bmad-cis-innovation-strategy trabalha contexto de mercado, modelo de negócio, oportunidades, opções estratégicas, hipóteses e critérios para avançar. A saída prevista é innovation-strategy-{date}.md, incluindo opções, direção recomendada, plano de execução, métricas e riscos. A recomendação é material para decisão; hipóteses sobre adesão e receita ainda precisam de evidências.

O que fornecer e como conferir. Explique como a empresa ganha receita hoje, por que está revendo a estratégia, quais restrições existem e quais dados de mercado estão disponíveis. A análise escolhe métodos conforme a maturidade do negócio e as informações acessíveis. Confira se a direção recomendada explica por que supera as alternativas, quais hipóteses precisam ser verificadas primeiro e que evidência faria a empresa mudar ou abandonar a direção. No exemplo, uma boa discussão pode terminar em decidir qual condição testar num piloto, sem contratar equipe nem lançar a assinatura durante a sessão.

Pedido — exemplo. Todo o texto depois do nome da skill é um exemplo:

/bmad-cis-innovation-strategy Nossa manutenção de equipamentos depende de chamados avulsos. Quero explorar alternativas de serviço recorrente, deixando explícitas as hipóteses sobre demanda, custo de atendimento e capacidade da equipe.

Depois: escolher uma hipótese para pesquisar ou testar com um piloto comercial. O mapa das possibilidades e das técnicas continua na Aula 07.

Solução de problemas: investigar a causa antes de escolher a ação

Situação de negócio. Os pedidos atrasam, mas contratar mais pessoas não resolveu. bmad-cis-problem-solving orienta a definição e o diagnóstico do problema, a investigação das causas, a comparação de soluções e o planejamento da implementação e da verificação. A saída prevista é problem-solution-{date}.md, com diagnóstico, alternativas, solução recomendada, ações, responsáveis e critérios de acompanhamento. A sessão depende dos fatos apresentados: uma causa sugerida precisa ser confrontada com o que acontece na operação.

O que fornecer e como conferir. Traga o que está acontecendo, onde e quando ocorre, quem é afetado, o impacto e a diferença entre a situação atual e a desejada. Também ajuda mostrar onde o problema não ocorre: atrasos só numa região ou só em pedidos de certo tipo mudam a investigação. O fluxo passa por esse contraste antes de buscar causas e comparar soluções. Confira se a ação recomendada ataca a causa investigada, se os critérios de comparação estão claros e como a equipe reconhecerá uma melhora. Esses cuidados tornam o documento utilizável na operação, mesmo quando a solução é uma regra de despacho ou treinamento.

Pedido — exemplo. Todo o texto depois do nome da skill é um exemplo:

/bmad-cis-problem-solving Os pedidos da nossa distribuidora continuam atrasando mesmo após reforçarmos a equipe. Quero separar sintomas de causas, comparar soluções e definir como verificar se uma mudança resolveu o problema.

Depois: executar uma ação limitada, acompanhar seu efeito e revisar a hipótese. Isso pode terminar numa mudança de processo; a Aula 07 mostra como escolher técnicas para conduzir esse raciocínio.

Storytelling: transformar fatos numa narrativa compreensível

Situação de negócio. A empresa conhece sua história e os resultados de um serviço, mas não consegue explicar ao cliente por que aquilo importa. bmad-cis-storytelling trabalha propósito, público, estrutura narrativa, voz e adaptações para canais diferentes. A saída prevista é story-{date}.md, com a narrativa e versões de diferentes comprimentos, além de orientações de uso. O fluxo pode orientar sua escrita, colaborar com você ou escrever um primeiro rascunho quando isso é solicitado.

O que fornecer e como conferir. Informe público, propósito, mensagem principal, fatos disponíveis, tom e onde o texto será usado. Esses elementos orientam a escolha da estrutura e as versões curta, média e extensa. Se quiser apenas orientação, você pode escrever com apoio; se quiser um rascunho, peça expressamente, como no Pedido abaixo. Ao conferir, procure coerência entre fatos, voz da empresa e ação desejada do público. Uma narrativa mais convincente continua precisando respeitar os fatos fornecidos: não transforma uma experiência isolada em garantia para todos os clientes.

Pedido — exemplo. Todo o texto depois do nome da skill é um exemplo:

/bmad-cis-storytelling Quero contar como nosso serviço ajudou um cliente a organizar as entregas. Vou fornecer os fatos e os resultados comprovados. Ajude a estruturar a história e escreva um primeiro rascunho para apresentação comercial, sem inventar depoimentos ou números.

Depois: conferir os fatos, colher retorno do público e adaptar a narrativa ao uso escolhido. Você pode encerrar com esse material. A Aula 07 aprofunda a escolha das estruturas e o uso do CIS em sessões de criatividade.

1. Preciso completar todas as Fases desta Aula?

   Não. As Fases agrupam necessidades; escolha somente a Etapa que atende ao seu objetivo. As ferramentas de planejamento são independentes e podem ser usadas em qualquer ordem, sem construir software. Você pode encerrar quando tiver o resultado que procurava.

2. Colei o Pedido no terminal e não funcionou

   Os Pedidos desta Aula vão no chat do Claude Code, com o BMAD instalado. O nome da skill carrega o recurso dentro da ferramenta de IA; o texto seguinte explica sua necessidade. Comandos de instalação pertencem ao terminal, como apresentado na Aula 04.

3. A skill não aparece, principalmente uma do CIS

   Confira se ela existe na pasta de skills da ferramenta e se o módulo correspondente foi selecionado na instalação. Algumas ferramentas exigem habilitação das skills nas configurações e reinício ou recarga. O CIS é adicional; bmad-brainstorming pertence ao núcleo e não depende dele.

4. Terminei o brainstorm, mas não apareceu brainstorm.html

   Nas sessões interativas desta Aula, os modos Facilitator e Creative Partner tornam os artefatos finais opcionais: peça os que deseja. No modo Ideate for me, o HTML é automático, mas brainstorm-intent.md continua opcional. A sessão fica registrada em .memlog.md. Retome as condições da Etapa 02 antes de interpretar a ausência de um arquivo como falha. Execuções automáticas sem uma pessoa na conversa têm instruções próprias, também explicadas naquela Etapa.

5. Pedi pesquisa, mas recebi apenas um texto para colar em outra ferramenta

   Isso é a saída de Draft. Execute esse Pedido na ferramenta escolhida e traga o relatório para Process. Se quiser pesquisar na própria sessão, escolha Run; ele precisa de acesso à web. Sem esse acesso, a skill deve oferecer Draft ou Process, sem inventar pesquisa. A Etapa 04 explica como escolher o modo.

6. A revisão encontrou problemas, mas não corrigiu tudo

   Em bmad-review, a entrega são os achados; revisar não equivale a reescrever automaticamente o material. Em bmad-code-review, você escolhe como tratar as correções propostas, e decisões ambíguas precisam ser resolvidas. Confira a saída e indique quais mudanças quer aplicar. A Etapa 10 também explica quando a revisão atualiza registros do projeto.

7. Quero uma mudança pequena; por que Build apresentou um plano?

   Começar sem documentos prévios não elimina o planejamento da execução. bmad-build investiga o projeto e escolhe o caminho adequado; lacunas de intenção, ações irreversíveis ou alcance maior podem exigir um plano escrito e sua aprovação. Confira o impacto identificado, como explicado na Etapa 08.

8. Procurei project-context.md, mas a saída foi para AGENTS.md

   Esse é o destino atual de referência: um bloco entre os marcadores <!-- bmad:context --> e <!-- /bmad:context -->. A skill mostra a proposta antes de escrever. Um project-context.md antigo pode ser aproveitado na migração; não é o arquivo obrigatório da versão conferida. A Etapa 11 explica as intenções de preparação e manutenção.

9. Preciso entregar todas as conversas anteriores à próxima skill?

   Para bmad-spec, a orientação oficial é condensar as decisões relevantes: o que deve ficar verdadeiro, o que precisa ser preservado e o que está fora do escopo. Não entregar uma pilha de documentos brutos. Uma síntese útil mantém as restrições e aponta as fontes que a sustentam; se ela apagar uma decisão importante, ainda não serve como passagem. A Etapa 07 detalha esse caminho.

10. A empresa já tem documentos e um processo; devo começar tudo outra vez?

    Não por obrigação do BMAD. A documentação permite usar as ferramentas de planejamento conforme a lacuna e aproveitar requisitos, decisões e aprovações existentes. Se várias pessoas precisam concordar, o PRD continua servindo como acordo compartilhado; se a intenção já está clara, ela pode alimentar uma spec delimitada. Nesta Aula, isso aparece na Etapa 07; para entrar num sistema existente e manter seu contexto, a continuação é a Aula 09 — BMAD em um projeto que já existe.