Fluxo completo, da ideia ao go-live

Você vai acompanhar uma ideia até ela virar trabalho definido, construção conferida e preparação para entrar no ar. Em cada Etapa, verá o que pedir ao Claude Code, que arquivo procurar e como decidir se já pode seguir. Go-live é o momento em que a versão passa a estar disponível para quem vai usá-la.

O exemplo é inventado: Lia é sócia de um salão e quer organizar os agendamentos com um aplicativo chamado Agenda Clara. A outra sócia também precisa concordar com as regras. Primeiro, a recepção deve controlar os horários. Depois, os clientes poderão reservar sozinhos. A aula usa esse mesmo negócio até o fechamento; na publicação, mostra os limites desse exemplo e acompanha o caso deste próprio guia.

Não foram criados um aplicativo nem arquivos da Agenda Clara para escrever esta aula. As situações, regras e falas de Lia são exemplos didáticos. As entregas descritas vêm da documentação oficial e da instalação do BMAD; não são respostas simuladas do Claude Code.

Comece pela decisão que evita trabalho desnecessário: você já sabe dizer o que precisa existir no fim, o que não pode mudar e o que fica de fora? Se sabe, pode seguir pelo caminho curto. Se ainda precisa descobrir isso ou combinar decisões entre várias pessoas, use as ferramentas de planejamento que resolvem essas lacunas. A documentação oficial as trata como ferramentas independentes, não como uma sequência obrigatória.

Para uma alteração óbvia e de baixo risco que você consegue conferir sozinho, a própria documentação permite pedir a mudança diretamente, sem o processo do BMAD. Para um trabalho que pode afetar o funcionamento do produto, o cuidado deve acompanhar o risco, não apenas a quantidade de arquivos.

Na Agenda Clara, Lia e a sócia ainda precisam decidir como a recepção e o cliente vão usar a mesma agenda. Vamos percorrer o caminho completo para mostrar essas decisões. Não significa que todo salão precise produzir todos os documentos desta aula.

O tamanho muda a quantidade de ciclos. “Curto” não significa necessariamente uma única sessão. Uma intenção clara pode exigir várias entregas. A documentação distingue estas situações:

A referência de cerca de vinte sessões para um projeto maior é uma aproximação da documentação, não uma fronteira obrigatória. Risco, dependências e pessoas envolvidas também mudam a necessidade de planejamento. Uma alteração pequena no acesso às reservas pode exigir mais cuidado do que várias páginas de texto. Esse exemplo é uma aplicação didática do critério de risco.

Como entrar e sair do caminho curto. Depois de preparar a pasta na Etapa 02, use o Passo “Criar a primeira spec no caminho curto”, na Etapa 09. Se o contrato couber em uma sessão, vá à Etapa 11. Se precisar de várias, peça a divisão em stories antes de construir. Confira cada entrega na Etapa 12; feche o épico na Etapa 13 quando houver um conjunto de stories. Se a spec revelar dúvidas que você não sabe resolver, volte à Etapa que trata delas: ideia, requisitos, experiência ou arquitetura. Não transforme uma pergunta aberta em uma decisão só para continuar.

Este guia usou o caminho curto, com spec e documentos de experiência. Esta aula ensina também o completo, para você reconhecer o que um projeto maior pede.

Um mapa, duas escalas. A página oficial “The method” resume o trabalho em quatro fases: Análise, Plano, Implementação e Verificação. Nesta aula, Ideia detalha a Análise; Requisitos, Desenho e Stories detalham o Plano; Desenvolvimento reúne construção e conferência; Fechamento verifica o conjunto. Preparar organiza a entrada, e Go-live acrescenta a publicação fora do BMAD. As oito fases são a organização didática desta aula.

Ele não é uma execução da Agenda Clara.

Pedido — exemplo do guia, pelo Claude Code. Esta Etapa não exige uma skill. Se quiser ajuda para decidir, use a skill de orientação:

/bmad-help Quero criar a Agenda Clara, um aplicativo de agendamento para um salão fictício. Duas sócias precisam combinar as regras. Queremos primeiro a agenda da recepção e depois a reserva pelo cliente. Ainda não decidimos como tratar cancelamentos e horários ocupados. Avalie o que já existe nesta pasta e recomende o menor caminho adequado. Explique o motivo e mostre quais decisões faltam.

Tudo depois de /bmad-help é texto de exemplo desta aula.

O que você recebe: uma recomendação no chat; não há um novo arquivo obrigatório nesta escolha. Quando pular: pode pular a consulta se já escolheu o caminho, mas continue sabendo qual resultado pretende entregar. Erro comum: produzir todos os documentos só porque aparecem no desenho. Como seguir: prepare a pasta na Etapa 02; no caminho completo, avance até a primeira decisão ainda não resolvida.

Abra uma sessão local do Claude Code na pasta do seu projeto. Os exemplos desta aula dependem da instalação e dos arquivos dessa pasta; uma sessão na nuvem pode ter outro ambiente e outro conjunto de skills. O BMAD deve estar instalado, conforme a Aula 04 — Instalação no macOS, e o histórico deve estar preparado, conforme a Aula 05 — Git e GitHub. A Aula 03, de Windows, está em breve.

Essa cópia remota não recebe automaticamente tudo o que você altera no computador. Primeiro as mudanças precisam ser registradas em commits; depois, esses commits precisam ser enviados. O nome desse envio é push. Só ter uma conta ou um repositório no GitHub não comprova que sua última versão chegou lá.

Use uma conversa nova para cada skill e aponte os arquivos que ela precisa ler. O BMAD recomenda esse cuidado para não misturar trabalhos. Há uma exceção útil mais adiante: depois de construir, você pode pedir a conferência guiada na mesma conversa.

Conversa nova não significa refazer decisões. Nas skills que mantêm .memlog.md, informe a pasta existente e peça para retomar o trabalho. Esse arquivo guarda o registro de decisões que permite reconstruir a sessão. Brainstorming, briefing, PRD, UX e arquitetura têm mecanismos de retomada. Confira o caminho antes de aceitar a criação de outra pasta para o mesmo objetivo. Não presuma, porém, que todos os modos de todas as skills retomam da mesma maneira.

Nesta aula, Pedido é o texto para colar no chat do Claude Code. Comando seria uma linha para colar no terminal, a janela que executa instruções do sistema. As chamadas abaixo, como /bmad-prd, são Pedidos no chat; não as cole no terminal do sistema. A instalação pelo terminal está na Aula 04.

Pedido — exemplo do guia, pelo Claude Code. Skill: bmad-help.

/bmad-help Confira se estou na pasta certa para trabalhar na Agenda Clara e identifique os arquivos de planejamento existentes. Oriente a conferência do BMAD e do histórico do projeto. Recomende a próxima skill da versão 6.12.4 e diga como chamá-la. Para fatos dessa versão, use a instalação local e as fontes oficiais do branch V6.12. Mostre o que encontrou e o que ainda não conseguiu conferir.

O que você recebe e onde: orientação no chat, baseada na configuração e nos documentos que a skill encontrar. Ela não exige um arquivo de saída. Isso também não substitui verificar as pastas da instalação e o projeto no GitHub, como nas aulas anteriores.

Como usar os exemplos seguintes: troque o negócio e as regras pelos seus. Quando o Pedido mandar localizar um documento, confirme o caminho exibido. Nos caminhos descritos como padrão, <projeto>, <tema>, <slug> e <data> representam partes variáveis do nome. Slug é um nome curto usado para identificar uma pasta. A pasta de saída padrão usada nesta aula é _bmad-output/; a configuração do projeto pode mudá-la.

Se o produto já existe. Você não precisa recontar toda a história da empresa para mudar uma parte do sistema. Comece pelo que será alterado e pelo que precisa ser preservado. A skill bmad-project-context pode registrar regras verificadas para os agentes em um bloco de AGENTS.md, o arquivo de instruções do projeto. Ela também pode adotar ou atualizar instruções existentes; não precisa substituí-las por um documento novo. Esse contexto orienta o trabalho, mas não substitui os requisitos da mudança.

Pedido opcional — exemplo do guia, para um projeto que já tem código.

/bmad-project-context Confira as instruções existentes deste projeto e proponha o contexto necessário para trabalhar na agenda sem perder regras já adotadas. Verifique os caminhos e os comandos no próprio repositório. Preserve as instruções válidas, apresente o bloco de AGENTS.md proposto e explique cada alteração antes de gravar. Não invente comandos para ferramentas que ainda não existem.

Essa skill pede revisão da proposta antes de escrever. Sua saída é o bloco de instruções no projeto, não um aplicativo funcionando. O Pedido acima não foi executado nesta revisão. Em um projeto novo, ela também pode começar pelas regras humanas e pelos documentos já decididos; os comandos ainda inexistentes ficam identificados como pendências.

Quando pular: pule somente a repetição da conferência se instalação, pasta e histórico já estão confirmados. Erro comum: abrir outra pasta e achar que os documentos sumiram. Como seguir: entre na Ideia, ou vá direto à Etapa 05 ou 06 se já tem uma ideia definida.

Confira antes de seguir:

• A pasta aberta é a do projeto que você quer alterar.
• A instalação responde e os documentos encontrados pertencem a esse projeto.
• Você consegue voltar a uma versão anterior usando o que aprendeu na Aula 05.

Lia começa com um incômodo: a recepção interrompe o atendimento para procurar horários e corrigir combinações feitas por mensagens. Antes de escolher telas, ela quer comparar formas de resolver o problema. As duas Etapas desta Fase são opcionais.

Simulação didática, sem execução do exemplo.

Opcional · Skill: bmad-brainstorming. Use quando o problema existe, mas a solução ainda está aberta. Brainstorm é uma conversa para gerar e explorar ideias antes de escolher uma. Aqui, Lia pode comparar uma agenda só para a recepção, a reserva pelo cliente ou uma combinação em etapas. Esses caminhos são sugestões do exemplo, não resultados obtidos da skill.

Quando pular: quando você já tem uma ideia concreta que consegue explicar e quer apenas testá-la ou registrar os requisitos. Erro comum: tratar a primeira ideia agradável como uma decisão tomada.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-brainstorming Quero explorar como reduzir a confusão de horários no salão fictício da Lia. Hoje a recepção combina horários por mensagens e anota em uma agenda. Há três profissionais. Gere comigo alternativas simples antes de escolhermos um aplicativo. O projeto se chama Agenda Clara. Não inclua cobrança nem envio automático de mensagens nesta primeira versão. Ao terminar a conversa, gere brainstorm.html e brainstorm-intent.md com o rumo escolhido, os limites e as perguntas que sobraram. Mostre os caminhos dos arquivos.

O que você recebe e onde: o registro visual brainstorm.html e o resumo brainstorm-intent.md, pedidos expressamente acima, na pasta padrão _bmad-output/brainstorming/brainstorm-<tema>-<data>/. O resumo leva a intenção adiante sem carregar toda a conversa. Nos modos de facilitação e parceria criativa, os arquivos finais dependem de solicitação; por isso o Pedido os pede pelo nome.

Conferência: nomes, caminhos e condição de geração lidos nas fontes; Pedido não executado.

Escolha como participar da geração de ideias. O modo muda a divisão do trabalho entre você e o Claude Code.

O terceiro modo não faz a escolha do negócio por você. Lia ainda precisa dizer quais alternativas combinam com a rotina do salão. No exemplo, uma agenda visual pode parecer atraente e continuar impraticável se a recepção não conseguir usá-la durante o atendimento. Essa é uma hipótese a examinar, não um resultado observado.

A skill pode tentar abrir uma página local para escolher modo e técnicas. Se ela não abrir ou você preferir o chat, a implementação tem uma alternativa pelo chat. A aula não mostra essa página porque não a executou. Ao fim de uma rodada, você pode explorar outras técnicas, convergir ou encerrar. Convergir é comparar as opções e escolher quais merecem continuar. No modo “Ideias para mim”, o HTML faz parte da entrega automática; nos outros dois, os arquivos finais são opcionais. O Pedido principal solicita os dois arquivos para tornar a intenção explícita.

Como seguir: leia o registro e escolha o problema que vai atacar. No exemplo da aula, Lia decide estudar primeiro a agenda da recepção e manter a reserva pelo cliente como outro resultado do produto. Leve essa escolha à Etapa 04, sem apresentá-la como validada.

Confira:

• há um rumo escolhido, limites claros e perguntas separadas das decisões.

Opcional · Skill: bmad-forge-idea. Use para questionar uma ideia antes de investir na construção. A skill examina pontos fracos, uma pergunta por vez, até a proposta ficar mais firme ou ficar claro que precisa mudar. Isso testa a coerência do raciocínio; não prova que clientes vão usar ou pagar pelo produto.

Lia precisa distinguir “seria bom ter um aplicativo” de “a recepção perde tempo porque não vê os horários ocupados de todos”. A segunda frase permite uma verificação concreta no trabalho do salão.

Quando pular: quando o problema e a solução já foram suficientemente examinados para o risco envolvido. Erro comum: aceitar uma avaliação da inteligência artificial, ou IA, como se fosse pesquisa feita com clientes reais.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-forge-idea Examine a ideia da Agenda Clara. Localize o brainstorm-intent.md deste projeto e confirme que está usando o arquivo certo. A proposta é organizar primeiro a agenda da recepção e depois permitir reservas pelo cliente. Questione o problema, o valor e as suposições, uma questão por vez. Não trate nossas estimativas como fatos nem invente entrevistas com clientes. Quero saber o que precisa ser observado no salão antes de investir. Ao concluir, mostre o relatório, as pendências e os caminhos dos arquivos gerados.

O que você recebe e onde: forge-report.html, na pasta padrão _bmad-output/forge/<slug>/. Se a ideia chegar à condição de estar firme, sai também forged-idea.md, pronto para orientar o próximo trabalho. Esse segundo arquivo é condicional: uma ideia que não se sustentou não deve ganhar uma aprovação inventada.

Conferência: funcionamento e saídas lidos nas fontes; nenhuma avaliação real da Agenda Clara foi feita.

Há três desfechos legítimos. A ideia pode ficar firme, ser descartada com motivos registrados ou ficar mais clara sem estar pronta para virar um contrato. Descobrir que falta uma observação real no salão é um avanço, mesmo sem aprovação da ideia. forge-report.html registra o resultado; forged-idea.md corresponde à saída em que a ideia ficou firme. Durante a conversa, você também pode pedir que a skill ataque a proposta, defenda sua melhor versão ou troque as perspectivas que a examinam. Essas perspectivas são recursos de raciocínio, não entrevistas realizadas com pessoas reais.

Quando a dúvida pede pesquisa, e não outra opinião. Se Lia precisa comparar ferramentas prontas, entender ofertas de concorrentes ou examinar uma decisão técnica, pode usar bmad-deep-recon. Essa skill pesquisa para apoiar uma decisão e exige fontes para as conclusões. Ela não converte as hipóteses do projeto em evidências.

O caminho Draft costuma continuar com Process: você traz o relatório obtido fora para ele entrar no projeto. Se já existe uma pesquisa, Refresh atualiza os pontos que envelheceram e Deepen aprofunda uma parte. Os nomes são modos da skill, não programas para instalar. O relatório fica por padrão em _bmad-output/planning-artifacts/research/<tipo>-<tema>-<data>/research.md; Draft sozinho entrega o Pedido em brief.md, sem fingir que a pesquisa terminou.

Pedido opcional — exemplo do guia, quando faltar evidência externa.

/bmad-deep-recon Use o modo Run para apoiar esta decisão da Agenda Clara: contratar uma ferramenta pronta ou construir a agenda da recepção. Antes de pesquisar, apresente o plano, as perguntas e o esforço proposto. Compare alternativas que atendam às regras já registradas, com fontes oficiais para capacidades e preços e datas das consultas. Separe fatos, limitações da pesquisa e hipóteses. Não trate a preferência de Lia como prova de mercado. Mostre research.md e seu caminho ao terminar.

Quando pular: quando a decisão já tem evidências adequadas ou não depende de pesquisa externa. Como seguir: leve as conclusões relevantes ao briefing, ao PRD ou à spec, preservando as fontes e as incertezas. Esta ramificação foi conferida documentalmente; não houve pesquisa de mercado da Agenda Clara, contratação nem comparação real de preços.

Como seguir: no exemplo, vamos supor que Lia decide continuar com a agenda da recepção e levar a confirmação de demanda para uma observação real no salão. Registre essa incerteza no próximo documento. Se a ideia não se sustentar, volte à Etapa 03 ou encerre a tentativa antes de construir.

Confira:

• você distingue o que sabe, o que está supondo e o que ainda precisa verificar fora do chat.

Agora Lia transforma a ideia em um acordo. Requisitos são as condições que o produto precisa atender para servir ao negócio. O PRD é o documento que reúne esses requisitos: o que o produto deve fazer e por quê. Nesta Fase, Lia define o resultado esperado e os limites, antes das escolhas de implementação.

Briefing, PRD e a skill de experiência da próxima Fase oferecem dois jeitos de conduzir a conversa: no caminho rápido, juntam as lacunas em uma ou duas perguntas e redigem o documento com marcas [ASSUMPTION]; no caminho com orientação, trabalham seção por seção. [ASSUMPTION] significa “suposição”: algo ainda não confirmado. Você pode pausar e retomar essas sessões. Esses dois modos não devem ser confundidos com os caminhos curto e completo da aula.

Skill: bmad-product-brief. Use quando a ideia já está clara, mas falta uma explicação curta que todos consigam ler. Briefing é o resumo de para quem o produto existe, qual problema resolve e que resultado busca. A documentação propõe um documento de uma ou duas páginas, ajustado ao propósito.

Quando pular: quando essa visão já está escrita e é suficiente para seguir, ou quando você prefere começar o PRD contando a ideia diretamente. O briefing não é pré-requisito obrigatório do PRD. Erro comum: encher o resumo de escolhas técnicas antes de explicar por que alguém precisa do produto.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-product-brief Crie o briefing da Agenda Clara. Leia os registros de ideia deste projeto, se existirem. Lia e a sócia querem reduzir a confusão de horários do salão. A recepção deve consultar a agenda dos três profissionais e registrar, remarcar e cancelar atendimentos; a reserva pelo próprio cliente será outro resultado do produto. Pagamentos e mensagens automáticas ficam de fora. Use o caminho rápido e marque com [ASSUMPTION] o que ainda depender de confirmação. Não invente números de economia nem pesquisa com clientes. Mostre brief.md, os arquivos de apoio e as decisões que precisamos conferir.

O que você recebe e onde: brief.md, na pasta padrão _bmad-output/planning-artifacts/briefs/brief-<projeto>-<data>/. Quando houver detalhes que não cabem no resumo, addendum.md guarda esse complemento, como alternativas rejeitadas e restrições. O PRD pode ler ambos. Addendum é apenas um complemento do documento principal.

A pasta também guarda .memlog.md, usado para registrar decisões e retomar o trabalho. Para atualizar o briefing, informe a mudança e a pasta existente: a skill confronta o pedido com o que já foi decidido. Para validar, peça uma crítica sem alterar o documento. Nesse uso, o resultado aparece no chat; um relatório separado só é criado se você pedir. Uma mudança fundamental pode justificar um novo briefing em vez de uma atualização do anterior.

Pedidos adicionais — exemplos do guia, ainda não executados; use somente o que corresponde à sua necessidade.

/bmad-product-brief Atualize o briefing existente da Agenda Clara. A recepção também precisará visualizar intervalos bloqueados na agenda. Vou informar a pasta do briefing. Leia as decisões anteriores e exponha os conflitos antes de alterar o documento. Mostre o que mudou e o que ainda depende de decisão.

/bmad-product-brief Valide o briefing existente da Agenda Clara sem alterá-lo. Confira se problema, público, resultado e limites estão claros. Mostre a crítica no chat e separe suposições de decisões confirmadas.

No caminho rápido, Lia revisa um rascunho inteiro e corrige as suposições marcadas. No caminho com orientação, ela pensa e escreve por partes com a skill. Escolha pelo trabalho que falta: organizar decisões já tomadas ou ajudar a formar essas decisões. Os dois modos continuam exigindo leitura e julgamento de quem conhece o negócio.

Conferência: comportamento lido nas fontes; Pedido não executado. addendum.md não é prometido como arquivo obrigatório em toda execução.

Alternativa ao briefing: examinar a proposta pelo ponto de vista do cliente. A skill bmad-prfaq usa um comunicado de lançamento imaginado e perguntas frequentes para desafiar o conceito antes da construção. PRFAQ reúne os nomes em inglês de comunicado à imprensa e perguntas frequentes. O comunicado é um exercício: não anuncia um lançamento real. Use quando precisar explicar por que alguém escolheria o produto e enfrentar perguntas difíceis sobre seu valor e sua viabilidade. Não é necessário fazer briefing e PRFAQ para todo projeto.

Pedido alternativo — exemplo do guia, pelo Claude Code.

/bmad-prfaq Quero examinar a Agenda Clara pelo ponto de vista da recepcionista e de quem marca um atendimento. Use o processo interativo. O problema é a dificuldade de enxergar horários e evitar reservas sobrepostas; a proposta inicial é uma agenda compartilhada pela recepção. A reserva pelo cliente virá depois. Questione o valor e as limitações antes de redigir um comunicado fictício de lançamento. Não invente clientes, depoimentos nem resultados medidos. Mostre o documento, o resumo para o próximo planejamento e as dúvidas que ficaram.

O documento principal fica por padrão em _bmad-output/planning-artifacts/prfaq-<projeto>.md. O fluxo passa pelo conceito, pelo comunicado, pelas perguntas dos clientes, pelas perguntas internas e pelo veredito. Entrega também um resumo para o PRD ou a spec. Se não houver clareza sobre quem é atendido e qual problema importa, a skill orienta voltar à geração ou ao exame da ideia. Depois, siga ao PRD somente se o tamanho e a coordenação do produto exigirem esse documento. Esta alternativa não foi executada com o exemplo.

Como seguir: Lia e a sócia leem o resumo e corrigem o que não representa o salão. Na hipótese desta aula, elas mantêm dois resultados separados: organizar a recepção e abrir a reserva ao cliente. Só depois levam o acordo à Etapa 06.

Confira:

• o briefing identifica quem usa, qual problema importa e o que não entra agora.

Skill: bmad-prd. PRD é o documento de requisitos do produto: registra o que deve existir e por quê. Use quando mais de uma pessoa precisa concordar sobre o produto ou quando vários épicos precisam seguir as mesmas regras. Ele descreve capacidades e condições de funcionamento; as escolhas de como construir ficam para o desenho.

No exemplo, “não aceitar duas reservas que ocupem o mesmo profissional no mesmo horário” é uma regra que a recepção e a reserva pelo cliente precisam compartilhar. “A agenda deve ser fácil” ainda é vaga: Lia precisa dizer que tarefas consegue concluir e como vai conferir isso.

Quando pular: no caminho curto, se a intenção e as restrições já bastam para uma spec. Erro comum: achar que um PRD longo é um PRD decidido; páginas extras não resolvem uma regra contraditória.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-prd Crie o PRD da Agenda Clara a partir do brief.md e do complemento que existirem neste projeto. Use o caminho com orientação. Separe os resultados da recepção e da reserva pelo cliente. Precisamos combinar disponibilidade por profissional, duração do serviço, remarcação e cancelamento. Não permita reservas sobrepostas para o mesmo profissional. Pagamentos e mensagens automáticas ficam de fora. Registre regras que possamos conferir, explique termos técnicos e marque decisões ainda não confirmadas. Mostre o documento, seus caminhos e o que Lia e a sócia precisam revisar.

O que você recebe e onde: prd.md, o complemento addendum.md quando pertinente e o registro de decisões .memlog.md, na pasta padrão _bmad-output/planning-artifacts/prds/prd-<projeto>-<data>/. .memlog.md é o registro acumulado que preserva decisões, suposições e perguntas da sessão. Confira o caminho efetivamente informado pela skill.

A mesma skill tem três usos. Diga qual deseja: criar escreve o primeiro PRD; atualizar reconcilia uma mudança com decisões anteriores; validar critica o documento sem alterá-lo e entrega um relatório. Validação produz relatórios em HTML, formato de página para abrir no navegador, e Markdown, texto com marcações de formatação. Não é o mesmo que uma nova edição do PRD.

Duas entradas para criar com orientação. “Visão e funcionalidades” começa pelo que o produto precisa permitir e costuma servir a ferramentas internas. “Jornadas” começa pela pessoa e pelo percurso de uso; costuma servir a produtos para consumidores ou com públicos diferentes. Você também pode pedir uma recomendação. Na Agenda Clara, as tarefas da recepção ajudam a começar pelas capacidades; o caminho da cliente, da busca até a confirmação, ajuda a revelar as situações de uso. As duas entradas precisam chegar a requisitos claros, sem contradizer as regras comuns.

A validação gera validation-report.html e validation-report.md na pasta do PRD. Uma validação posterior substitui esses relatórios consolidados; os arquivos individuais de revisão continuam disponíveis para aprofundamento. O PRD em criação pode estar draft, rascunho; ao finalizar, recebe final. Esse estado significa que o documento foi finalizado pelo fluxo. Não prova que a aplicação foi construída ou testada.

Pedidos adicionais — exemplos do guia; use um por vez, quando precisar.

/bmad-prd Atualize o PRD da Agenda Clara com esta mudança proposta: o prazo mínimo para cancelar passa a ser definido pelo salão. Leia a decisão atual, exponha conflitos e apresente o que precisa mudar antes de aplicar. Mostre os arquivos alterados e as decisões pendentes.

/bmad-prd Valide o PRD da Agenda Clara sem alterá-lo. Procure regras vagas, contradições e condições que não conseguiremos conferir, principalmente em reservas simultâneas, remarcações e cancelamentos. Mostre os relatórios e indique o que precisa ser resolvido antes da construção.

Conferência: os três usos e as saídas foram conferidos documentalmente; nenhum dos Pedidos foi executado com o exemplo.

Como seguir: resolva as regras que afetam a primeira entrega. No exemplo, Lia deve conseguir explicar o que acontece quando um horário fica ocupado enquanto outro cliente tenta reservá-lo. Esse acordo alimenta tanto a experiência quanto a arquitetura.

Confira:

• as duas sócias concordam com os limites; as regras podem ser verificadas; as suposições importantes estão visíveis.

Lia já sabe o que o produto deve fazer. Agora precisa registrar como a pessoa usa a agenda e quais decisões técnicas mantêm as partes funcionando juntas. UX, ou experiência de uso, trata do que a pessoa vê e faz. Arquitetura registra as decisões técnicas compartilhadas que evitam soluções incompatíveis.

A aula apresenta UX antes de arquitetura para começar pelo uso da agenda. Essa ordem é didática: a documentação permite trabalhar PRD, UX e arquitetura em qualquer ordem e levar suas decisões à mesma spec. Se uma decisão técnica mudar a experiência, volte ao documento afetado.

Skill: bmad-ux. Use quando a maneira de usar o produto faz diferença. Na Agenda Clara, não basta desenhar uma agenda bonita: a recepção precisa encontrar um horário, entender por que ele ficou indisponível e saber se a remarcação terminou.

Quando pular: quando o trabalho não tem interface relevante ou segue decisões existentes que continuam suficientes. Erro comum: aprovar só a tela ideal e deixar sem resposta o que acontece ao faltar informação ou ocorrer um erro.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-ux Crie a experiência da Agenda Clara usando o PRD aprovado deste projeto. Use o caminho com orientação. Comece pela recepção: consultar a agenda por profissional, registrar, remarcar e cancelar. Depois descreva a reserva pelo cliente usando as mesmas regras. Mostre o que acontece quando não há horário, quando faltam dados e quando o horário fica ocupado durante a reserva. Considere uso no celular e por teclado. Quero conferir os percursos antes de construir. Entregue DESIGN.md e EXPERIENCE.md e mostre seus caminhos e as decisões pendentes.

O que você recebe e onde: DESIGN.md registra a aparência e os padrões visuais; EXPERIENCE.md registra a organização, os percursos e os comportamentos. Ambos ficam, por padrão, em _bmad-output/planning-artifacts/ux-designs/ux-<projeto>-<data>/. Podem existir representações de telas como apoio, mas elas não substituem os dois documentos.

Conferência: há documentos de uso real dessa skill na construção deste guia; o Pedido da Agenda Clara e suas telas não foram executados.

Três formas de desenvolver a experiência. No caminho rápido, a skill prepara os documentos com suposições marcadas, sem a etapa de ferramentas criativas. No caminho com orientação, a conversa percorre as decisões e pode usar representações visuais como apoio. Existe ainda a rota de preparação para uma ferramenta de design: a skill redige um Pedido para você executar nessa ferramenta, e depois incorpora os resultados salvos no projeto. Essa terceira rota depende do seu acesso à ferramenta externa; não é uma tela produzida automaticamente pelo BMAD dentro desta aula. Nela, EXPERIENCE.md pode ser completado depois por uma atualização.

Se o desenho e o documento discordarem. DESIGN.md e EXPERIENCE.md são os contratos usados na construção e prevalecem sobre representações de telas. Resolva a divergência antes de construir. Para mudar uma decisão, use a mesma bmad-ux pedindo atualização da pasta existente. Para uma conferência crítica, peça validação: ela pode gerar validation-report.html e validation-report.md. Na finalização comum, a validação é oferecida como opção; no Pedido que solicita validar, essa intenção já foi expressa. A pasta mantém .memlog.md para preservar decisões e retomada.

Pedido adicional — exemplo do guia, não executado.

/bmad-ux Valide os documentos existentes de experiência da Agenda Clara, sem criar novas telas. Vou informar a pasta. Confira se os percursos de consulta, reserva, remarcação e cancelamento respeitam o PRD, inclusive em erros e uso por teclado. Mostre os relatórios, as divergências e o que depende de decisão antes de atualizar os documentos.

Como seguir: Lia percorre um caso completo em palavras: uma cliente pede terça-feira, escolhe um serviço, não encontra a profissional desejada, aceita outra e recebe a confirmação. Se alguma decisão faltar, ajuste a experiência antes de repassá-la à construção. Esse percurso é inventado para orientar a leitura; não representa uma tela entregue pela skill.

Confira:

• você entende o caminho principal, o que acontece quando algo dá errado e como a pessoa percebe que terminou.

Skill: bmad-architecture. Use quando várias partes ou pessoas poderiam tomar decisões técnicas diferentes para o mesmo assunto. A skill registra o que precisa ser compartilhado; não tenta antecipar cada detalhe do código.

No exemplo, a agenda interna e a reserva do cliente precisam respeitar a mesma disponibilidade. Deixar cada parte inventar sua própria regra pode produzir duas reservas corretas isoladamente e um conflito no salão. Essa situação é uma hipótese didática que Lia quer prevenir.

Quando pular: no caminho curto, uma mudança pequena pode seguir decisões técnicas existentes e suficientes, sem gerar outra arquitetura. No caminho completo desta aula, a skill bmad-create-epics-and-stories exige PRD e arquitetura completos; também exige UX quando há interface. Portanto, pode aproveitar uma arquitetura existente, mas não deve chegar àquela skill sem as decisões que ela exige. Para este exemplo, mantemos a Etapa porque há mais de uma forma de reservar na mesma agenda. Erro comum: escolher uma tecnologia só por ser conhecida, sem explicar qual problema ela resolve.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-architecture Registre a arquitetura da Agenda Clara a partir do PRD, de DESIGN.md e de EXPERIENCE.md deste projeto. Explique em linguagem simples as decisões que a agenda da recepção e a reserva pelo cliente precisam compartilhar. Considere quem pode ver ou alterar cada reserva, onde os agendamentos ficam guardados e como impedir conflitos de horário. Não decida pelo negócio uma regra ainda aberta: destaque a lacuna. Prefira a solução mais simples que atenda aos documentos. Mostre ARCHITECTURE-SPINE.md, o caminho e as escolhas que precisam de confirmação.

O que você recebe e onde: ARCHITECTURE-SPINE.md, por padrão em _bmad-output/planning-artifacts/architecture/architecture-<projeto>-<data>/. O documento usa decisões identificáveis para as partes seguintes herdarem. Seu nome contém “spine”, a ideia de uma estrutura central: decisões comuns, em vez de um manual de todo o sistema.

Conferência: skill e arquivos conferidos na fonte e na instalação; arquitetura da Agenda Clara não produzida nem testada.

O que muda entre projeto novo e existente. No projeto novo, a skill pode propor uma base de implementação e explicar as alternativas. No produto existente, precisa examinar o código e as convenções reais antes de recomendar mudanças. O objetivo é registrar decisões necessárias à consistência, sem trocar uma solução funcionando apenas por preferência.

A arquitetura pode cobrir o produto inteiro ou apenas um épico. A do épico herda as decisões superiores e resolve o que ficou aberto; não pode enfraquecer uma regra comum sem registrar o conflito. No exemplo, a reserva pelo cliente deve respeitar as decisões de disponibilidade que também valem para a recepção. Essa herança é especialmente útil quando pessoas diferentes constroem partes do produto.

Orientar, acelerar, atualizar ou validar. O caminho com orientação é o padrão: escolhas importantes vêm com alternativas e consequências. Se você pedir rapidez, a skill pode redigir o documento com suposições sinalizadas para sua revisão. Depois, pode atualizar decisões existentes ou validar a arquitetura sem alterá-la. As decisões têm identificadores estáveis para preservar o histórico. A validação produz relatórios em HTML e Markdown; esta aula não promete um nome fixo que a implementação não define. Ao concluir ou mudar decisões, peça à bmad-spec que as incorpore ao contrato ou mantenha a arquitetura como documento complementar.

Como seguir: Lia não precisa escolher detalhes de programação sem ajuda. Precisa entender as consequências para o salão: acesso, continuidade dos agendamentos e conflitos. Depois de resolver essas decisões, leve o conjunto à divisão do trabalho.

Confira:

• a recepção e a reserva pelo cliente obedecem às mesmas decisões sobre horários, acesso e armazenamento.

O próximo objetivo de Lia é sair de “construir um aplicativo” para uma sequência que ela consiga acompanhar. As stories precisam ter critérios de aceite: condições observáveis que dizem quando a entrega atende ao combinado.

Skill principal: bmad-create-epics-and-stories. A divisão deve acompanhar resultados para quem usa. No exemplo, “A recepção organiza a agenda” e “O cliente reserva um horário” são candidatos a épicos. “Criar um monte de telas” não explica, sozinho, o resultado para o salão.

Quando pular: pule esta skill no caminho curto: peça a divisão em stories à própria bmad-spec. Se a mudança cabe em uma única sessão, não precisa inventar um épico. Erro comum: criar uma story grande demais ou que só funciona depois de várias outras ainda não construídas.

Pedido — exemplo do guia, pelo Claude Code. Cole ao final os caminhos que as Etapas anteriores realmente mostraram.

/bmad-create-epics-and-stories Organize o trabalho da Agenda Clara a partir dos documentos aprovados cujos caminhos vou informar abaixo. Leia o PRD, DESIGN.md, EXPERIENCE.md e ARCHITECTURE-SPINE.md. Proponha épicos por resultado: primeiro organizar a agenda da recepção; depois permitir a reserva pelo cliente. Divida cada um em stories que possamos construir e conferir separadamente, respeitando dependências e regras comuns. Defina critérios de aceite observáveis e explique a ordem. Não acrescente pagamentos nem mensagens automáticas. Confirme comigo a divisão e mostre o caminho de epics.md e as pendências.

O que você recebe e onde: na implementação instalada, _bmad-output/planning-artifacts/epics.md, reunindo os épicos, suas stories e os critérios de aceite. A documentação geral fala em “arquivos de épico”; este é o nome efetivo do arquivo no fluxo conferido.

Dependência não significa que tudo precisa nascer junto. Uma story pode usar o resultado de outra anterior. O que ela não deve exigir é uma entrega futura para funcionar. A remarcação pode aproveitar o registro de reservas já pronto; a primeira reserva não deve depender de uma entrega que só existirá em um épico posterior. Mais épicos também não significam melhor organização. A skill considera juntar partes muito acopladas quando não há um ponto real de aprendizado ou risco que justifique separá-las.

Você confirma os requisitos encontrados, a divisão em épicos e a conclusão do trabalho. epics.md pode existir ainda como draft, isto é, rascunho. Se a validação encontra problemas, ele permanece nesse estado com os pontos abertos; só recebe final depois de passar pelas verificações e concluir o fluxo com você. Encontrar o arquivo não comprova que o plano terminou.

Para seguir o exemplo, vamos chamar uma possível entrega de story 1.1: a recepção registra uma reserva sem sobrepor horários de um profissional. O número, a divisão final e o nome precisam vir do seu epics.md; a aula não afirma que essa story já foi gerada. Pode haver trabalho de base antes dela.

Passo complementar · Preparar o contrato do épico com bmad-spec. PRD, UX e arquitetura não substituem a spec que reúne o contrato de construção. A documentação da 6.12 orienta produzir uma SPEC.md por épico também no caminho completo. A skill de épicos não faz isso automaticamente; chame bmad-spec separadamente.

Pedido complementar — exemplo do guia, pelo Claude Code, em conversa nova.

/bmad-spec Crie o contrato do épico da recepção da Agenda Clara, com o nome curto agenda-clara-recepcao. Use o épico correspondente em _bmad-output/planning-artifacts/epics.md e as decisões aprovadas do PRD, de DESIGN.md, de EXPERIENCE.md e de ARCHITECTURE-SPINE.md, nos caminhos que vou informar. Preserve as regras de acesso, duração e conflito de horários. Referencie os documentos necessários para construir. Já acompanharemos este projeto por epics.md e sprint-status.yaml; não crie outra divisão em stories. Mostre SPEC.md, os complementos e todas as lacunas restantes.

Arquivo complementar: _bmad-output/specs/spec-agenda-clara-recepcao/SPEC.md é o caminho esperado para o nome do exemplo. A pasta também guarda documentos complementares e .memlog.md. Repita o contrato para os outros épicos quando for prepará-los. Para mudar uma spec, volte à bmad-spec com a mudança; não altere SPEC.md à mão, pois ela é derivada do registro de decisões.

Como ler o contrato antes de aceitar. SPEC.md organiza cinco campos. Leia-os como compromissos do negócio. Na tabela, os exemplos são sugestões didáticas; precisam ser confirmados para o seu projeto.

Cada capacidade ganha um identificador estável, como CAP-1, e precisa ter intenção e condição de sucesso. “Estável” significa que uma atualização não deve trocar o número de uma capacidade já conhecida. Isso ajuda a ligar requisitos, construção e conferência sem perder a referência.

Os documentos complementares também fazem parte do contrato. A lista companions: aponta o que a construção precisa ler junto com SPEC.md; pode incluir documentos de UX já escritos por outra skill. A lista sources: registra materiais totalmente absorvidos na spec, para consulta e auditoria; não promete que o build os relerá. Portanto, uma regra necessária que só ficou em uma fonte precisa estar preservada na spec ou em um complemento. Não duplique um documento só para mudar seu nome.

Passo alternativo · Criar a primeira spec no caminho curto. Se você veio diretamente da Fase Preparar, este é seu ponto de entrada. Conte o resultado, as restrições e o que fica de fora. A skill transforma uma intenção definida em contrato; ela não decide sozinha qual produto você quer.

Pedido — exemplo do caminho curto, pelo Claude Code. Use este exemplo somente se o escopo abaixo representar uma decisão já tomada no seu projeto.

/bmad-spec Crie a primeira spec da Agenda Clara, com o nome curto agenda-clara-recepcao. Nesta alternativa, o escopo decidido é apenas a agenda interna: a recepção consulta horários por profissional e registra, remarca e cancela reservas. Cada reserva deve respeitar a duração do serviço; duas reservas não podem ocupar o mesmo profissional em horários sobrepostos. Reservas pelo cliente, cobrança e mensagens automáticas ficam de fora deste contrato. Use também as regras existentes que eu indicar. Se faltar uma decisão necessária, deixe a pergunta visível; não escolha por mim. Mostre SPEC.md, os complementos, as suposições e as perguntas abertas. Depois avalie comigo se a construção cabe em uma sessão ou se precisa de divisão em stories.

O exemplo curto tem escopo menor do que o produto completo da aula. Se você também quer a reserva pelo cliente, registre essa intenção no planejamento correspondente; não deixe que ela entre implicitamente nesta spec. O caminho de saída esperado continua sendo _bmad-output/specs/spec-agenda-clara-recepcao/, ajustado ao nome e à configuração reais. Pedido e saída não foram executados nesta revisão.

Se a informação vier incompleta ou grande demais. Com material suficiente, a skill extrai o contrato sem uma entrevista adicional. Com lacunas, pode produzir um rascunho com perguntas abertas ou percorrer os cinco campos com você. Se a intenção for vaga demais, orienta voltar ao planejamento. No outro extremo, a documentação estima um limite prático de algumas dezenas de milhares de unidades de texto processadas pela IA, aproximadamente quarenta páginas; isso não é garantia de capacidade. Organize as decisões relevantes e os complementos antes de entregar uma pilha de documentos. Confira a preservação das regras, não apenas o tamanho final do arquivo.

Se você escolheu o caminho curto, a alternativa é pedir à bmad-spec a função Story Breakdown, que significa dividir a spec em stories. Ela gera stories.yaml ao lado de SPEC.md, depois de combinar a divisão e os pontos de conferência com você. Ponto de conferência é uma pausa combinada antes ou depois da implementação para você decidir se o trabalho segue. Essa divisão é uma conversa interativa; não é prometida na execução sem conversa da skill.

Pedido alternativo — exemplo do caminho curto, pelo Claude Code.

/bmad-spec Quero dividir em stories a spec existente da Agenda Clara. Vou informar o caminho de SPEC.md. Use Story Breakdown e proponha uma entrega conferível por story. Combine comigo a ordem e os pontos em que quero revisar antes ou depois da construção. Mostre stories.yaml e os critérios que justificam a divisão.

O que stories.yaml controla. Ele é uma lista ordenada de trabalho, não um boletim de conclusão. Não possui campo status. O estado da execução fica no registro de cada story, dentro de stories/. A ordem da lista indica a sequência; o identificador distingue a story e deve ser preservado depois que seu registro de implementação existe. Já sprint-status.yaml é o acompanhamento próprio do caminho de projeto. Não mantenha dois controles paralelos sem uma decisão explícita de como se relacionam.

Os pontos de conferência são registrados em spec_checkpoint e done_checkpoint. Esses campos orientam quem despacha as stories, isto é, a pessoa ou ferramenta que decide qual execução começa e quando deve parar. Não são uma garantia de que uma chamada isolada a bmad-build fará todas essas pausas por conta própria. Na condução manual, diga no Pedido onde quer revisar. invoke_dev_with guarda instruções adicionais para quem despacha acrescentar ao Pedido; não substitui uma regra que deveria constar da spec.

Se o contrato mudar, atualize-o com bmad-spec e confira se a lista de stories ainda corresponde à decisão. A atualização da spec não reescreve stories.yaml automaticamente: peça uma nova divisão quando necessário. Não reaproveite o identificador de uma story já iniciada para uma entrega diferente.

Conferência: os dois caminhos foram lidos nas fontes e na instalação. Os Pedidos e a combinação de documentos da Agenda Clara não foram executados. No caminho completo continuaremos com epics.md e sprint-status.yaml; no curto, com SPEC.md e stories.yaml.

Como seguir: confira se cada requisito aparece em alguma entrega, se cada story cabe em uma sessão e se não se perdeu uma restrição ao resumir os documentos. Siga à Etapa 10 no caminho completo.

Skill: bmad-sprint-planning. Use antes de começar a construir o projeto dividido em épicos. Sprint é um período de trabalho; aqui, o nome da skill também cobre a conferência do plano e o acompanhamento das stories, sem exigir que você invente um calendário para fazer a aula. O ponto central é saber se alguém consegue implementar sem preencher decisões ausentes por conta própria.

Quando pular: o caminho curto acompanhado por stories.yaml dispensa o arquivo de sprint; isso não dispensa ler e aceitar o contrato. Erro comum: considerar a existência de todos os documentos uma prova de prontidão. A skill lê o conteúdo; a falta de um tipo de documento só importa quando as stories dependem de decisões que ele deveria conter.

Pedido — exemplo do guia, pelo Claude Code.

/bmad-sprint-planning Confira a prontidão da Agenda Clara para implementação. Leia o PRD, os documentos de experiência e arquitetura, epics.md e as specs dos épicos deste projeto. Verifique se é possível construir as stories sem inventar decisões. Mostre o veredito e a evidência de cada problema. Se houver ressalvas, apresente-as antes de prosseguir. Se o plano passar, gere o acompanhamento em sprint-status.yaml e mostre o caminho e a próxima story adequada.

O que você recebe: um destes vereditos, com as evidências que o justificam.

O que sai e onde: após passar pela conferência, _bmad-output/implementation-artifacts/sprint-status.yaml. É o arquivo que registra a situação das stories. O veredito aparece na conversa; em caso de falha, a skill pode oferecer salvar implementation-readiness.md na pasta de planejamento. Esse relatório não é um arquivo obrigatório de toda execução.

Cinco usos, sem confundir as perguntas. O Pedido principal combina prontidão com criação do acompanhamento. A mesma skill também pode executar apenas uma parte.

Pedidos adicionais — exemplos do guia, não executados; escolha um por vez.

/bmad-sprint-planning Verifique somente a prontidão da Agenda Clara. Leia o plano e apresente PASS, CONCERNS ou FAIL com evidências. Não gere nem atualize sprint-status.yaml nesta consulta.

/bmad-sprint-planning Mostre a situação atual das stories da Agenda Clara, os riscos, as ações pendentes e a próxima ação recomendada. Diferencie evidência de conclusão de uma simples marcação no acompanhamento.

/bmad-sprint-planning Valide o formato de sprint-status.yaml sem alterá-lo. Se houver problema, explique o que precisa de reparo.

Se os épicos mudarem, é possível gerar o acompanhamento de novo. A geração procura preservar estados mais avançados, ações de retrospectiva e comentários. Uma entrada sem correspondência exige atenção: pode ser uma story renomeada, não trabalho que deixou de existir. O reparo usa evidências e pode devolver uma story a um estado anterior se isso refletir a situação real. Essa correção precisa ser apresentada antes de ser aplicada.

Conferência: vereditos e arquivos lidos na fonte e na instalação; nenhuma prontidão da Agenda Clara foi avaliada de verdade.

Como seguir: se a regra de cancelamento estiver contraditória, Lia corrige o PRD e os documentos afetados. Se o plano estiver suficiente, ela escolhe a próxima story conforme a ordem aprovada. Um veredito de prontidão não significa que o produto já foi construído, testado ou publicado.

Confira:

• não há impedimento ignorado; as ressalvas têm decisão; você sabe qual story entra na próxima conversa.

Aqui o acordo vira código. Código são os arquivos de instruções que fazem o produto funcionar. Lia acompanha uma entrega de cada vez e verifica o comportamento que combinou, sem precisar ler cada linha de programação.

Principal · Skill: bmad-build. Abra uma conversa nova e indique uma única entrega. A documentação usa como referência uma sessão com um objetivo, cerca de 500 linhas de código adicionadas ou alteradas, sem contar os testes, em poucos arquivos. Isso é uma medida aproximada para dividir o trabalho, não uma meta de produtividade nem uma promessa de duração.

Quando pular: em uma edição trivial que você vai revisar diretamente, sem justificar o processo completo. Para as reservas da Agenda Clara, esta é a Etapa central. Erro comum: pedir a agenda, pagamentos, mensagens e relatórios na mesma sessão.

O plano vem quando é necessário. A skill investiga os arquivos antes de perguntar. Se encontra dúvidas de intenção, ações irreversíveis ou uma mudança de maior alcance, prepara um plano para sua decisão; em um caso simples e claro, pode seguir por um caminho mais curto. Não é necessário inventar uma regra de “sempre ativar o modo Plano do Claude Code”: o plano aqui faz parte do trabalho da skill.

Quando o plano completo é apresentado, você pode aprovar e continuar, aprovar e parar antes da implementação ou discutir ajustes. A segunda opção deixa o registro ready-for-dev, pronto para construir em outra conversa. Isso permite, por exemplo, que Lia confira o plano com a sócia antes de dedicar outra sessão à execução. Não é preciso mandar começar a programar só para salvar o planejamento.

Pedido — exemplo do guia, pelo Claude Code. Ajuste o identificador da story e os caminhos ao que você realmente recebeu.

/bmad-build Implemente a story 1.1 descrita em _bmad-output/planning-artifacts/epics.md da Agenda Clara. Use também o arquivo _bmad-output/specs/spec-agenda-clara-recepcao/SPEC.md e os documentos complementares que ele indicar. Confira a situação da story no sprint-status.yaml existente. Quero que a recepção registre uma reserva respeitando a duração do serviço e sem sobrepor horários do mesmo profissional, conforme os critérios aprovados. Trabalhe só nesta story. Mostre o plano quando houver decisões minhas, o que mudou, quais testes rodaram, as pendências, o registro de implementação e o commit local.

O complemento depois de /bmad-build é um exemplo editorial. O arquivo SPEC.md é citado explicitamente: nesta combinação, ele fornece o contrato; a story continua sendo identificada em epics.md. Não substitua esse Pedido por “pasta da spec + número da story” se você não usa stories.yaml, pois essa outra forma seleciona outro caminho da skill.

O que você recebe e onde: código alterado; testes aprovados quando o projeto tem a estrutura de testes e foi possível executá-los; um registro da implementação; e um commit local, quando há Git disponível e mudanças para salvar. No caminho de projeto usado aqui, o registro fica por padrão em _bmad-output/implementation-artifacts/spec-<slug>.md. A skill pode produzir também epic-<número>-context.md, com o contexto do épico. No caminho curto com pasta de spec e stories.yaml, o registro fica em stories/<id>-<slug>.md dentro da pasta da spec.

Dois arquivos com nomes parecidos. SPEC.md, em letras maiúsculas, é o contrato de intenção preparado na Etapa 09. O registro spec-<slug>.md, criado pelo build, acompanha uma unidade de implementação: plano, decisões, tarefas, revisão e verificações. No caminho com stories dentro da pasta da spec, esse segundo papel cabe a stories/<id>-<slug>.md. Um não substitui o outro. Se a construção revelar uma mudança no contrato compartilhado, a atualização volta à bmad-spec.

Pedido alternativo — uma única sessão no caminho curto. Depois de conferir que a mudança cabe em uma sessão, indique o arquivo SPEC.md real:

/bmad-build Construa a mudança descrita no arquivo SPEC.md cujo caminho vou informar. Leia também os complementos indicados nele. Confira se há um único objetivo que cabe nesta sessão; se o trabalho exigir várias entregas, mostre a divisão antes de implementar. Mostre as decisões pendentes, o registro de implementação, o que mudou, as verificações realizadas e o commit local.

Pedido alternativo — uma story do caminho curto. Use apenas se a divisão da Etapa 09 produziu stories.yaml; substitua 1 pelo identificador exato que existe nesse arquivo:

/bmad-build Use a pasta _bmad-output/specs/spec-agenda-clara-recepcao/ e a story de id "1" em stories.yaml. Leia o contrato SPEC.md dessa pasta e seus complementos. Trabalhe apenas nessa story. Quero revisar o plano antes da implementação. Mostre o registro em stories/, as decisões pendentes e, quando a implementação estiver autorizada e terminar, as verificações e o commit local.

Nessa forma, “pasta + identificador” seleciona o registro da story. Se stories.yaml não existir, não puder ser lido ou não contiver o identificador, a skill para em vez de trocar silenciosamente de caminho. Mais de um registro para o mesmo identificador também exige resolução. Os dois Pedidos alternativos foram conferidos nas instruções da skill, sem execução com a Agenda Clara.

Se a conversa for interrompida. Informe o caminho exato do registro de implementação que já existe. O estado desse registro determina a retomada no build interativo:

Para pedir uma revisão adicional de trabalho concluído, use a ramificação com bmad-code-review da Etapa 12. Orientação do guia: não mude o estado do arquivo à mão apenas para forçar uma rota. O significado de done nessa seleção não é igual ao da variante automática; por isso a aula mantém os dois fluxos separados.

Na entrada de um trabalho novo, o build interativo confere o Git. Se encontrar alterações anteriores ainda não organizadas ou uma linha de trabalho incompatível com o Pedido, para para esclarecer. Branch é uma linha de trabalho no histórico. Essa parada evita misturar mudanças; não prova que o planejamento da story está errado. As rotas que retomam diretamente um registro existente não repetem necessariamente essa conferência inicial. Peça que explique os arquivos encontrados e organize o trabalho antes de continuar, sem mandar apagar alterações desconhecidas.

O que ficou para depois: pedidos extras e problemas anteriores fora da mudança vão para _bmad-output/implementation-artifacts/deferred-work.md. Esse arquivo é a lista de trabalho adiado. Leia-o: “adiado” não significa “resolvido”, e um impedimento da story atual não deve ser tratado como um detalhe irrelevante.

Conferência: fluxo e saídas conferidos documentalmente. O Pedido interativo desta Etapa não foi executado com a Agenda Clara; os registros reais deste guia são da variante bmad-build-auto, conforme o aviso inicial.

Quando considerar a variante automática. bmad-build-auto executa uma unidade sem esperar respostas durante a execução. Ela é uma alternativa depois que as decisões importantes e os padrões de implementação estão estáveis. As stories iniciais, arriscadas ou fundamentais merecem acompanhamento porque podem definir como todo o restante será construído.

Uma chamada automática não percorre todas as stories, não escolhe a próxima e não fecha o épico. Uma pessoa ou um processo de coordenação precisa selecionar cada unidade e ler o resultado. A skill também depende de poder iniciar agentes auxiliares para suas verificações. Se não houver essa capacidade ou se faltar uma decisão de intenção, pode terminar como blocked, bloqueada, com o motivo registrado. Esse estado não é uma autorização para ignorar a lacuna. Esta aula explica a alternativa porque ela aparece na evidência real do guia; não apresenta uma automação contínua como algo já configurado ou testado no exemplo.

Como seguir: leia o resumo e veja a mudança funcionar. No exemplo, Lia deve conseguir registrar uma reserva e observar a recusa de outra que sobreponha o mesmo profissional. Isso é uma condição proposta para conferência, não uma afirmação de teste aprovado. Use a Etapa 12 para ser guiado nessa leitura.

Confira:

• a entrega corresponde à story; você sabe quais testes rodaram; as pendências estão visíveis; o commit foi salvo localmente.

Skill: bmad-walkthrough. Walkthrough é uma visita guiada pela mudança para você entender e julgar o resultado. Ela organiza a explicação pelo motivo e pelas decisões, depois mostra os pontos de maior risco e como observar o comportamento. É uma conferência humana; a revisão automática já faz parte da construção.

Quando pular: pode dispensar a skill se você já conferiu a mudança por outro meio. Não dispense a decisão sobre aceitar o resultado. Erro comum: achar que ouvir a explicação equivale a testar o produto. A skill não executa a suíte de testes, isto é, o conjunto de verificações automáticas do projeto.

Pedido — exemplo do guia, pelo Claude Code. Você pode usar a mesma conversa da construção; para outra mudança, abra uma nova e informe a referência correta.

/bmad-walkthrough Percorra a mudança da story 1.1 da Agenda Clara. Explique primeiro o objetivo, depois as decisões e os pontos em que um erro afetaria o salão. Mostre o que eu devo experimentar para conferir a reserva e o conflito de horários, com o resultado esperado de cada observação. Separe os testes automáticos já realizados das verificações que ainda dependem de mim. Ao final, resuma o que foi observado e o que falta para eu aceitar a entrega.

O que você recebe e onde: uma orientação na conversa, com referências aos arquivos. Para uma mudança típica, a skill procura sugerir de duas a cinco observações manuais. Uma mudança interna pode não ter comportamento observável; nesse caso, a skill deve explicar essa limitação, sem inventar uma demonstração. Não existe um walkthrough.md obrigatório como saída padrão. O encerramento pede sua decisão: aprovar, refazer ou continuar discutindo.

Na simulação da Agenda Clara, Lia pode reservar um horário livre, tentar uma reserva sobreposta e conferir se a primeira continua correta. Use os procedimentos que a skill indicar para a implementação real. Este texto não inventa botões nem mensagens da aplicação.

Conferência: skill e comportamento lidos na fonte; nenhuma observação manual da Agenda Clara foi realizada.

Do computador ao GitHub. Depois de aceitar a mudança, você pode pedir o push, o envio dos commits para o repositório remoto. A documentação do BMAD também sugere um pull request, um pedido de revisão e integração das mudanças, quando esse é o processo do projeto. Siga a política do seu projeto e a Aula 05; o guia, por exemplo, adota commits direto na main, a linha principal do histórico, sem pull request. A bmad-build não envia o commit automaticamente.

Antes de fechar o épico, confira o acompanhamento. O registro da construção pode estar done, isto é, concluído, enquanto a story ainda está review, aguardando revisão, em sprint-status.yaml. Aprovar o walkthrough não atualiza esse arquivo automaticamente. Se faltar revisão, conclua essa conferência; se o acompanhamento divergir de uma conclusão comprovada, peça que ele seja reconciliado com as evidências e confira a proposta antes de aplicá-la.

Se a story está aguardando revisão. A bmad-code-review pode partir da story em review no acompanhamento. Quando identifica o registro correto e resolve todos os achados que exigem ação, pode concluí-lo como done. Se ficam problemas ou ações pendentes, pode colocá-lo em in-progress, em andamento. A sincronização do sprint depende de identificar a chave correta da story e encontrar o arquivo e essa chave. Revisar apenas um commit, sem essa associação, não garante que o acompanhamento será atualizado.

Pedido adicional — exemplo do guia, para uma story que aguarda revisão.

/bmad-code-review Revise a story 1.1 da Agenda Clara que está aguardando revisão em sprint-status.yaml. Identifique o registro de implementação e a chave exata da story antes de prosseguir. Confira a mudança contra o contrato aprovado. Mostre os achados e resolva o que couber no escopo autorizado. Ao terminar, informe o estado do registro, se o acompanhamento foi sincronizado e quais pendências impedem considerá-la concluída.

Este Pedido não foi executado. A revisão não substitui a observação humana do comportamento do salão, e reparar o acompanhamento não substitui uma revisão que ainda falta. São trabalhos diferentes: examinar a implementação, decidir seu aceite e registrar a situação correta.

Pedido de acompanhamento — exemplo do guia, pelo Claude Code.

/bmad-sprint-planning Mostre a situação das stories do épico 1 da Agenda Clara e as pendências antes da retrospectiva. Compare sprint-status.yaml com os registros de implementação, as revisões e as evidências de aceite. Se houver divergência, proponha a correção do acompanhamento para eu conferir antes de aplicar. Não marque como concluído o que ainda não tiver evidência. Mostre a situação resultante e o que falta para fechar o épico.

O modo de consulta mostra a situação na conversa. Quando há reparo, a skill propõe o estado correto e só regrava sprint-status.yaml depois da confirmação. Este Pedido também foi apenas conferido documentalmente.

Como seguir: se a story precisa de ajustes, peça-os antes de avançar. Se foi aceita, construa a próxima conforme o plano. Quando as stories do épico estiverem concluídas, confira o conjunto na Etapa 13.

Confira:

• você observou o que importa para o negócio e decidiu aceitar ou devolver a entrega; não confundiu essa decisão com publicação.

Lia já conferiu entregas separadas. Agora precisa saber se elas funcionam juntas: registrar, remarcar e cancelar não podem deixar a agenda em estados contraditórios. Essa é a hora de olhar o épico inteiro.

Skill: bmad-retrospective. Retrospectiva é a avaliação do que o épico realmente entregou, do que faltou e do que precisa mudar no próximo trabalho. A skill usa documentos, mudanças no código, commits e registros de execução como evidência. Não se baseia apenas na lembrança da conversa.

Quando pular ou adiar: adie enquanto ainda está construindo as stories; em uma mudança isolada sem épico, use a conferência da própria mudança. Erro comum: fechar o épico porque cada story passou sozinha, sem observar a combinação.

Pedido — exemplo do guia, pelo Claude Code. O número 1 só vale se esse for o épico correto no acompanhamento do seu projeto.

/bmad-retrospective 1
Avalie o épico da recepção da Agenda Clara pelas stories, pelo código, pelos commits, pelos testes e pelos critérios aprovados. Use o acompanhamento existente em sprint-status.yaml. Confira as relações entre registrar, remarcar e cancelar reservas. Mostre evidências, o veredito, os itens em aberto e o caminho do relatório. Se não conseguir observar algum comportamento, registre a limitação. Não implemente as ações propostas nesta retrospectiva.

O que você recebe e onde: no caminho completo acompanhado por sprint, _bmad-output/implementation-artifacts/epic-1-retro-<data>.md e a atualização de sprint-status.yaml. No caminho curto, a chamada recebe a pasta da spec e produz RETROSPECTIVE.md ali, sem criar um arquivo de sprint.

Pedido alternativo — exemplo do caminho curto, pelo Claude Code. Use apenas se a pasta realmente contiver SPEC.md, stories.yaml e os registros das stories:

/bmad-retrospective _bmad-output/specs/spec-agenda-clara-recepcao/
Avalie o conjunto das stories desta spec e mostre o veredito, as evidências e o caminho de RETROSPECTIVE.md.

Leia o veredito, não apenas o estado do arquivo. A retrospectiva pode estar registrada como feita e concluir que o épico não foi aceito.

Os três valores e a regra de rejeição por stories inacabadas vêm de Finish an Epic. A pessoa pode contrariar o veredito explicitamente; isso não transforma ausência de evidência em teste aprovado. A skill propõe ações, mas não corrige o código nem atualiza automaticamente as specs. Mudanças no contrato voltam à bmad-spec.

O fechamento também tem ramificações. O número explícito do épico evita avaliar outro conjunto. No caminho de stories, informar a pasta da spec seleciona esse caminho mesmo que exista um arquivo de sprint no projeto. Se a retrospectiva for interrompida, a execução seguinte pode usar o relatório como registro de trabalho, confrontar as evidências atuais e retomar a primeira parte incompleta.

No caminho de sprint, marcar a retrospectiva como done significa que a avaliação foi feita. O veredito fica no relatório; a marcação de execução pode existir mesmo com rejected. Nas avaliações seguintes, a skill também pode revisar ações de épicos anteriores e propor atualizações, sujeitas à confirmação prevista no fluxo. Assim, um item aceito para depois não desaparece apenas porque um novo épico começou.

É possível pedir uma discussão em equipe sobre os achados ou executar a retrospectiva sem interação. A discussão é opcional e precisa partir das evidências encontradas. A execução sem interação registra suposições e não substitui o julgamento do responsável pelo negócio. Ela também não transforma automaticamente stories incompletas em um épico aceito. O Pedido principal desta aula mantém a conversa com a pessoa responsável; nenhuma dessas alternativas foi executada com a Agenda Clara.

Conferência: fontes e instalação conferidas; nenhuma retrospectiva da Agenda Clara foi executada.

Como seguir: na hipótese didática, Lia só considera o épico da recepção aceito depois de resolver os problemas que impedem seu uso. Repete o ciclo para o épico de reserva pelo cliente. Quando a versão que pretende oferecer estiver completa e conferida, prepara um plano de publicação adequado à aplicação.

Confira:

• o conjunto foi avaliado; cada pendência tem uma decisão; você sabe o que ainda impede disponibilizar a versão aos usuários.

O BMAD não tem uma skill de publicação neste fluxo. A bmad-build termina com trabalho conferido e commit local; colocar uma versão na internet exige um procedimento adequado ao projeto e à hospedagem. Hospedagem é o serviço que disponibiliza o site para os visitantes.

Lia chega a esta Fase com outra decisão a tomar: onde a Agenda Clara vai funcionar, quem terá acesso e como os agendamentos serão preservados. A aula não publicou esse aplicativo fictício. Para ensinar a fronteira entre construir e publicar sem inventar uma infraestrutura, o caso concreto passa a ser este próprio guia, um site estático feito com Astro e publicado na Vercel em 15/11/2026, no projeto guia-bmad.

Os participantes são os quatro exigidos pelo contrato do diagrama; o provedor de DNS, explicado na Etapa 15, é uma dependência externa desse desenho.

Skill: nenhuma skill de publicação do BMAD. Esta Etapa usa um Pedido comum ao Claude Code para preparar e executar o procedimento de hospedagem do projeto. Os detalhes são conteúdo próprio do guia, apoiado na documentação da Vercel.

Quando pular: se você quer apenas construir e conferir localmente, pare antes da publicação. Erro comum: considerar que o commit local ou o envio ao GitHub já colocou o produto no ar. Neste guia, a publicação é uma ação separada: a integração Git foi desconectada e os envios ao GitHub não publicam automaticamente.

Pedido — exemplo do guia, pelo Claude Code, sem skill. Este Pedido pode orientar uma nova publicação, depois de cumpridos os pré-requisitos do projeto. O texto do Pedido é didático; os comandos e resultados registrados abaixo vêm da publicação real.

Prepare e realize a publicação deste guia na Vercel conforme a SPEC.md e a seção Publicação de stack.md. Antes de publicar, confirme que as etapas de construção e integração exigidas estão concluídas, que os testes previstos passaram e qual commit será publicado. Confira o acesso à conta e ao repositório privado. Mantenha a publicação automática desativada e não habilite Analytics nem Speed Insights, conforme a decisão do projeto. Use a documentação oficial atual da Vercel. Se faltar acesso ou configuração, informe o impedimento. Mostre o endereço gerado, a versão publicada, o que foi executado e o que ainda precisa ser conferido.

Os nomes Analytics e Speed Insights, nesse Pedido, identificam recursos de medição da Vercel: visitas e páginas no primeiro, desempenho no segundo. A restrição de não habilitá-los é deste guia, registrada em stack.md › Publicação.

Publicação manual ou a cada envio? A integração Git da Vercel pode gerar uma implantação quando recebe mudanças do repositório. Neste guia, a pasta local foi ligada ao projeto guia-bmad com vercel link, e vercel git disconnect desligou a conexão com o repositório na Vercel. Assim, os envios ao GitHub deixaram de disparar publicações; a publicação passou a depender da execução manual com os testes verdes. Em outro projeto, a equipe pode escolher a publicação automática, desde que saiba quais envios geram prévias e quais chegam à produção. A escolha depende do processo daquele projeto.

Comandos usados neste guia. Na preparação, foram executados vercel link e vercel git disconnect. Para publicar a versão conferida, a sequência foi pnpm test, pnpm test:publicacao e, somente depois de ambos passarem, vercel deploy --prod. Os dois comandos pnpm acionam verificações definidas no package.json deste repositório; não são comandos do BMAD nem da Vercel. --prod pede uma implantação de produção. Os comandos da Vercel foram conferidos na documentação oficial e na ajuda da CLI local 50.9.6 em 15/11/2026.

O que você recebe e onde: uma versão hospedada e um endereço para abrir no navegador. Neste caso, o site estático em Astro ficou publicado no projeto guia-bmad da Vercel em 15/11/2026. Não há um arquivo de saída definido por uma skill BMAD. O responsável deve registrar o commit, o endereço, a data e os resultados reais nos documentos de publicação do projeto, conforme stack.md › Publicação.

O código pode continuar em um repositório privado, sujeito às permissões e às condições da conta de hospedagem. Isso não torna o endereço hospedado privado: a visibilidade do código e a proteção de acesso ao site são configurações diferentes.

Dois casos ajudam a conferir essa diferença. Você pode manter o código privado e oferecer o site ao público. Também pode restringir o acesso a uma versão destinada à conferência, se a conta e a configuração oferecerem a proteção necessária. Não presuma que um endereço com aparência de prévia esteja protegido, nem que a proteção escolhida cubra automaticamente o domínio final. Confira os endereços e o alcance da configuração real.

Como seguir: confira o conteúdo da versão publicada antes de considerar o endereço final pronto. Neste guia, a ligação do domínio e a conferência pública foram realizadas como mostra a Etapa 15. Em cada nova publicação, repita os testes antes do envio e a conferência no ar depois dele.

Confira quando executar:

• os testes exigidos passaram; a versão publicada é a versão conferida; você conhece o endereço e sabe se o acesso é público ou protegido.

Skill: nenhuma skill de publicação do BMAD. Em 15/11/2026, este guia passou a responder em https://bmad-guia.olucasales.com, com as Aulas 01, 02, 04, 05, 06 e 07 publicadas e a Aula 03 marcada “Em breve”. Esse endereço é uma decisão deste projeto, não uma escolha que o BMAD faz pelo leitor.

Quando pular: você pode adiar um domínio próprio e usar um endereço fornecido pela hospedagem, conforme o plano. A conferência do site que será usado pelo público continua necessária. Erro comum: achar que “publicado” significa que todas as páginas e o endereço final já funcionam.

Pedido — exemplo da primeira publicação, pelo Claude Code, sem skill. Em publicações posteriores, atualize a lista de aulas conforme o contrato da versão.

Ligue o endereço bmad-guia.olucasales.com a este guia na Vercel, seguindo a decisão de publicação do projeto. Compare a configuração DNS existente com o valor que a Vercel exigir para este projeto. Se os valores divergirem ou faltar acesso, informe o que falta antes de alterar. Depois da validação, confira o HTTPS, a página inicial, as seis aulas publicadas (01, 02, 04, 05, 06 e 07) e a página não encontrada pelo domínio final. O endereço da Aula 03 deve continuar indisponível. Confira também os critérios de privacidade definidos na spec. Registre os resultados reais e a data; atualize o trecho de go-live da Aula 06 somente com o que foi comprovado.

Para um subdomínio, a Vercel orienta configurar um registro CNAME, que aponta um nome para o destino indicado. O valor cname.vercel-dns.com acima registra o que funcionou neste guia. A documentação atual orienta usar o valor específico mostrado para o projeto; confira esse valor em cada instalação. Depois da configuração e da validação, a Vercel cuida da emissão do certificado para HTTPS; a atualização do DNS pode levar tempo para ser reconhecida.

Se o domínio já atende a outros serviços. Para ligar apenas este subdomínio, confira o CNAME no provedor de DNS atual. Mudar todos os servidores de DNS é outro caminho, com alcance maior: exige preservar os registros que mantêm outros serviços, como o e-mail. A aula não pede essa mudança geral. Se a validação do domínio falhar, compare os registros atuais com os valores exigidos e mantenha a pendência explícita. “Domínio adicionado” e “HTTPS funcionando” são conferências distintas; registre o que foi efetivamente comprovado em cada uma.

O que você recebe e onde: o domínio funcionando e um registro das verificações. Neste guia, o endereço com HTTPS e os 27 testes no ar foram confirmados na primeira publicação de 15/11/2026. Não há arquivo obrigatório de uma skill. A story de publicação também prevê registros em README.md e KICKOFF.md; esta atualização da aula se limita ao relato dos fatos fornecidos pelo responsável.

Checklist da primeira publicação — repita a conferência no endereço final a cada nova versão:

• A página inicial abre com HTTPS.
• As Aulas 01, 02, 04, 05, 06 e 07 abrem e seus links funcionam, conforme o escopo da primeira publicação.
• Um endereço inexistente mostra a página não encontrada.
• A Aula 03 continua sem página publicada, com o aviso “Em breve” onde previsto.
• As verificações do projeto confirmam a ausência de requisições a terceiros e de cookies, conforme o contrato do guia.
• O trecho desta aula passa a dizer exatamente o que foi testado, com a data e as pendências restantes.

Cookie é um pequeno registro que um site pode guardar no navegador; o contrato deste guia não permite seu uso. A preferência de tema é a única informação que o projeto prevê guardar no navegador, por outro mecanismo.

Lia faria uma conferência equivalente no endereço da Agenda Clara, mas acrescentaria o que a aplicação de agendamentos exige: acesso de cada pessoa, preservação das reservas e comportamento dos fluxos reais. Esses cuidados dependem da arquitetura e do plano de publicação dela. O exemplo do guia mostra como atravessar a fronteira até um site público; não afirma que um aplicativo com dados de clientes já está pronto para operar.

Para revisar a escolha do caminho, volte à Aula 02 — Para que serve e onde aplicar.

1. Tenho vários arquivos e não sei o que fazer agora

   Use bmad-help. A skill lê a configuração e os documentos para recomendar o próximo passo; um arquivo encontrado não significa, sozinho, uma Etapa concluída.

   Pedido — exemplo do guia, pelo Claude Code.

   Peça ao Claude Code

   /bmad-help Leia os documentos existentes da Agenda Clara e diga em que ponto estamos. Diferencie documento iniciado de etapa concluída. Recomende o próximo passo mais simples, separando o necessário do opcional, e mostre quais evidências sustentam a recomendação. Para os fatos do método, use a instalação 6.12.4 e as fontes do branch V6.12.

   Você recebe orientação na conversa, sem arquivo novo obrigatório. Pedido conferido documentalmente, não executado.

2. A skill diz que não encontrou meu PRD ou minha arquitetura

   Copie o caminho completo que a Etapa anterior informou. A busca inicial de bmad-create-epics-and-stories tem padrões que podem não alcançar as pastas novas da própria versão 6.12. Não conclua que o documento precisa ser refeito só porque a busca falhou.

3. A ideia mudou bastante depois que começamos a construir

   No caminho completo, use bmad-correct-course quando a mudança afeta mais do que uma story: por exemplo, Lia passa a administrar duas unidades, e isso muda as regras de acesso e disponibilidade. A skill exige PRD e épicos, avalia o impacto e propõe uma correção de rumo.

   Pedido — exemplo do guia, pelo Claude Code.

   Peça ao Claude Code

   /bmad-correct-course A Agenda Clara passará a atender duas unidades do salão, com equipes e horários separados. Leia o PRD, os épicos e os documentos de experiência e arquitetura existentes. Avalie o impacto no que já foi construído e no que falta. Proponha o que muda, o que permanece e a ordem de correção. Mostre a proposta e seu caminho antes de aplicar mudanças.

   A saída padrão é _bmad-output/planning-artifacts/sprint-change-proposal-<data>.md. A proposta precisa de decisão antes de seguir para as alterações. No caminho curto, com apenas uma spec, comece por bmad-help e pela atualização com bmad-spec: não prometa que bmad-correct-course funcionará sem os documentos que exige. Pedido não executado nesta aula.

4. Preciso pedir outra revisão automática depois de toda construção

   A bmad-build já inclui revisão. Uma revisão adicional pode fazer sentido para outra mudança ou uma conferência extra; a skill correspondente é bmad-code-review. Não é uma Etapa obrigatória acrescentada depois de toda story.

   Pedido — exemplo do guia, pelo Claude Code.

   Peça ao Claude Code

   /bmad-code-review Revise a mudança da story da Agenda Clara que vou indicar, considerando o contrato aprovado e o comportamento alterado. Confirme o escopo, mostre os achados relevantes e informe quais correções e verificações foram realizadas.

   Os achados podem aparecer na conversa e ser associados ao registro da mudança quando ele existir; não há um único nome de relatório obrigatório para todo contexto. O Pedido não foi executado.

5. A construção encontrou outro problema no projeto

   Confira se ele pertence à story atual. Problemas anteriores e objetivos independentes podem ir para deferred-work.md. Leia a descrição e decida o que entra em outra sessão; não acrescente tudo ao trabalho em andamento.

6. Os testes passaram, mas a retrospectiva rejeitou o épico

   Testes de partes isoladas não provam que o conjunto atende à intenção. Leia as evidências do veredito: pode haver uma story incompleta, uma regra que não foi atendida ou uma combinação de comportamentos que falhou. Corrija o que foi apontado e avalie novamente.

7. Terminei a construção. Por que o site ainda não está no ar

   Porque o commit é local e a publicação é outro procedimento. Retome a Aula 05 para o envio ao GitHub e a Fase 08 para o plano de hospedagem. Não há uma skill de publicação BMAD a procurar neste fluxo.

8. A documentação que abri mostra outros nomes de skills

   Esta aula cobre a 6.12.4. Para conferir os nomes daqui, use os links do branch V6.12 abaixo e a instalação do seu projeto. A página de instalação atual de docs.bmad-method.org identifica seu fluxo como prévia da v7 e direciona quem usa a 6.12 ao branch correspondente. Ela foi consultada somente para confirmar esse aviso, não para ensinar procedimentos da 6.12. Não misture um Pedido de outra versão com os passos deste guia.