PULSE — Sinais de previsibilidade de entrega para times BMAD.
Não prove só que você é 10x mais rápido — prove que seu plano estava certo, e erre menos sprint após sprint.
Saída exemplo de
/bmad-pulse-dashboard— baseado em projeto BMAD real:
| Métrica | Valor |
|---|---|
| Stories medidas | 12 |
| Previsibilidade | 88% (mediana) ↑ — margem de erro 12% |
| Horas reais AI | 24h |
| Taxa de first-pass | 83% |
| Alavancagem AI (vs PLANO) | 1.1x — contexto, não meta |
| Alavancagem AI (vs REFERÊNCIA frozen) | 6.9x — ROI estável (não colapsa) |
| Economia vs benchmark de referência (152h) | 128h |
Leia com honestidade — três enquadramentos, papéis distintos:
- Previsibilidade (herói): suas estimativas estão convergindo para a realidade? Menor = melhor;
↓= convergindo. É o sinal durável.- Alavancagem vs PLANO: o número andaime — só é grande enquanto a base de estimativa não está calibrada. Este time já calibrou: ela colapsou para ~1.1x (e esse colapso é o produto funcionando — virou a previsibilidade). Contexto, nunca meta.
- Alavancagem vs REFERÊNCIA frozen (quando a estimativa por BCP está ligada e grava
estimated_hours_reference): denominador congelado e governado, então não colapsa — o multiplicador de ROI honesto vs um benchmark fixo (4.0h/BCP), para a cadência de board. Continua não sendo meta nem "vs humano".
Sem estimated_hours_reference, só aparecem previsibilidade + alavancagem-vs-plano. (Veja o Roadmap.)
Epic 1: ████████░░░░░░░░░░░░ 4.2x (3 stories)
Epic 4: ██████████░░░░░░░░░░ 5.1x (2 stories)
Epic 5: ████████████████░░░░ 7.8x (3 stories)
Epic 14: ██████████████░░░░░░ 6.9x (3 stories)
Epic 15: ████████████████████ 8.4x (1 story)
📊 Ver dashboard completo → (quebra por categoria, previsão de capacidade, insights da Max, breakdown story-a-story)
Veja mais cenários de dashboard para diferentes tamanhos de time e estágios de adoção.
Em algum momento, todo desenvolvedor que trabalha com IA já viveu este instante: olhou para o relógio, percebeu que fez em duas horas o que estimou em dois dias, e não soube muito bem o que fazer com aquela sensação.
PULSE foi construído para esse momento. Para transformar essa sensação em número. Esse número em história. E essa história em evidência.
Você adotou BMAD. Plugou Claude Code ou Cursor. Seu time parece mais rápido — mas quando a liderança pergunta "quão mais rápido?", você está chutando.
Toda ferramenta de produtividade de IA mede linhas de código, commits ou gasto de tokens. Nenhuma responde a pergunta que seu CTO está realmente fazendo: estamos entregando mais valor visível ao usuário por hora de engenharia?
Existem dois tipos de time em 2026: o time que usa IA, e o time que tem IA usando IA. A diferença não aparece em linhas de código. Aparece em stories entregues por hora estimada.
PULSE mede isso!
- Um número defensável de previsibilidade do seu SDLC — quão perto suas estimativas caem da realidade, sprint a sprint, pronto para o seu deck de stakeholders. (Alavancagem também — mas como sinal do primeiro mês, não a manchete.)
- Aviso antecipado de trabalho travado — previsões de capacidade e alertas de halt antes da sprint escorregar.
- Um coach, não só um dashboard — Max (a agente do PULSE) lê seus sinais e te diz onde a alavancagem está vazando.
O mercado mede linhas. PULSE mede stories.
É a diferença entre peso na balança e percentual de gordura corporal. LOC te diz que algo está se mexendo. Alavancagem te diz se é músculo ou inchaço.
Uma story é a menor unidade de valor que seu usuário sente. Acompanhar alavancagem de IA no nível da story — horas estimadas vs. horas reais, do planning ao done — te dá a única métrica que sobrevive a uma reunião de board.
PULSE também é o primeiro plugin de observabilidade BMAD-native do marketplace. Não existe incumbente. Não existe segundo lugar ainda. Se você roda BMAD e quer analytics de SDLC que falem o vocabulário BMAD (epics, stories, agentes, workflows), essa é a ferramenta.
Stories, não linhas. Outcomes, não output. Previsibilidade, não bravata.
| Métrica | O que é | Por que importa |
|---|---|---|
| AI Leverage Ratio | horas_estimadas / horas_reais |
Sinal do primeiro mês; colapsa para ~1.0x conforme você calibra (e isso é saudável) |
| First-Pass Rate | % de stories aprovadas sem revisão | Qualidade do processo de desenvolvimento |
| Process Health | Aderência ao workflow BMAD | Halts, skills subutilizadas, drift |
npx bmad-method install --custom-source https://github.com/nidelson/bmad-module-pulseDepois, no seu projeto BMAD:
/bmad-pulse-setup # Configure uma vez
/bmad-pulse-track-start # Quando começar uma story
/bmad-pulse-track-done # Quando terminar — alavancagem é calculada
/bmad-pulse-track-backfill # Esqueceu de medir? Recupere HI/HF depois do fato
/bmad-pulse-dashboard # Veja a tendência cumulativaPULSE se conecta aos seus arquivos de story BMAD existentes — sem migrations, sem banco separado.
Depois de atualizar o PULSE, rode
/bmad-pulse-setupde novo. Nem todo o PULSE chega pelo instalador. O setup também grava arquivos dentro do seu projeto, e uma atualização do módulo renova as skills sem tocar neles — eles continuam na versão que era a atual da última vez que você rodou o setup. Rodar de novo traz tudo para a versão que você acabou de instalar; é seguro repetir a qualquer momento e mantém suas respostas anteriores como padrão.Arquivos desatualizados falham de forma silenciosa, não barulhenta — então nada numa execução posterior vai apontar a atualização como causa. O instalador exibe um painel "Action needed" sobre isso ao fim da instalação e da atualização (#124).
⚠ Atualizando da v0.3.x? Os slash commands foram renomeados de
pulse-*parabmad-pulse-*na v0.4.0. Leia MIGRATION.md antes de atualizar — v0.4.0 tem BREAKING CHANGES.
| Skill | Comando | Função |
|---|---|---|
bmad-pulse-setup |
/bmad-pulse-setup |
Configura o módulo no seu projeto |
bmad-pulse-track-start |
/bmad-pulse-track-start [story_id] |
Registra início da story |
bmad-pulse-track-done |
/bmad-pulse-track-done [story_id] |
Registra conclusão + calcula métricas |
bmad-pulse-track-backfill |
/bmad-pulse-track-backfill [story_id] --hi <ts> --hf <ts> |
Registra HI/HF + métricas retroativamente para story medida tarde demais |
bmad-pulse-dashboard |
/bmad-pulse-dashboard |
Gera dashboard cumulativo |
Estimativa por BCP — opt-in (só entram em cena com pulse_estimation_method = "bcp"):
| Skill | Comando | Função |
|---|---|---|
bmad-bcp-rule-card |
/bmad-bcp-rule-card [elemento] |
Mostra a régua canônica (10 elementos × 5 tamanhos) |
bmad-bcp-score |
/bmad-bcp-score [story] |
Pontua a story e deriva estimated_hours do score |
bmad-bcp-score-batch |
/bmad-bcp-score-batch [glob] |
Pontua stories existentes em lote (retroativo) |
bmad-bcp-rescore |
/bmad-bcp-rescore [story] |
Repontua após mudança de escopo, preservando o histórico |
bmad-bcp-recalibrate |
/bmad-bcp-recalibrate [story] |
Recalibra o baseline por categoria com horas reais |
bmad-bcp-backfill-baseline |
/bmad-bcp-backfill-baseline [glob] |
Sai do cold start usando o histórico já entregue |
PULSE nasceu medindo alavancagem: você estimou 10h, entregou em 1h, são 10x. O número é real, mas o denominador é um palpite — e recalibrar um palpite não converge para nada, porque não existe unidade comparável embaixo dele.
Ligar a estimativa por BCP (Business Complexity Points, framework da CI&T) troca o palpite por uma régua canônica: 10 BCP × 5h/BCP = 50h. Aí a estimativa vira comparável entre times e ao longo do tempo, e recalibrar passa a significar alguma coisa — o que ela revela é a previsibilidade do squad. É esse o pulso que o PULSE quer medir.
# _bmad/config.toml — [modules.pulse]
pulse_estimation_method = "bcp" # default: "hours"| Sem BCP | Com BCP |
|---|---|
| Estimativa em horas, subjetiva | Estimativa derivada de um score contra uma régua |
| Métrica-herói: alavancagem (não colapsa, porque nada recalibra) | Métrica-herói: previsibilidade (a alavancagem migra para o denominador frozen) |
| Nenhuma seção BCP no dashboard | Produtividade BCP, forecast BCP × h/BCP ± IC 90%, convergência de baseline |
hours continua sendo o default, e nada empurra você para o BCP. Um projeto sem BCP renderiza um dashboard completo, sem seção vazia e sem aviso de que "falta" algo — não é modo degradado, é o produto. Detalhes, contrato de frontmatter e a fronteira interna entre pontuar e medir: docs/bcp.md.
Max é a Analista de Previsibilidade de Entrega do PULSE. Ela lê suas métricas e te diz, em linguagem clara, onde o squad está perdendo tempo: drift de estimativa, etapas BMAD sendo puladas, agentes mal utilizados. Lidera com o número que a configuração atual consegue defender — alavancagem enquanto a estimativa for em horas, previsibilidade quando uma régua canônica a torna comparável entre times.
Ela mede o sistema, nunca a pessoa. E nunca dá um número sem a faixa em volta dele.
PULSE instrumenta três pontos no ciclo de vida da story BMAD:
- Story start — captura horas estimadas do arquivo da story.
- Story done — captura horas reais e calcula a razão de alavancagem.
- Sprint rollup — agrega alavancagem na sprint ativa e projeta capacidade.
| Razão | Sinal | O que significa |
|---|---|---|
| ≥ 3.0x | Excepcional | IA está comprimindo materialmente seu SDLC. Documente o padrão, replique. |
| 1.8x – 2.9x | Sólido | Alavancagem saudável. A norma para times BMAD maduros. |
| 1.2x – 1.7x | Atenção | Ganho marginal. Investigue onde a IA está desacelerando. |
| < 1.2x | Alerta | IA não está puxando o peso dela. Max vai apontar a causa provável. |
- Track — horas estimadas vs. reais por story, timestamps de início/fim, atribuição por agente.
- Aggregate — dashboard cumulativo com tendências semanais e por sprint.
- Forecast — projeção de capacidade baseada em alavancagem rolante e velocidade do time.
- Audit — checagens de saúde de processo: stories sem estimativa, trabalho parado, artefatos faltando.
- Alert — detecção de halt quando uma story trava além da estimativa.
- Coach — Max lê as métricas e aponta gargalos em linguagem clara.
Wall-clock pode ser inflado por latências que não são trabalho de dev. PULSE captura essas latências como halts estruturados em process_health.halts e subtrai do actual_hours para que a alavancagem reflita esforço real de engenharia.
kind |
O que representa |
|---|---|
approval_wait |
Pausa aguardando aprovação explícita do usuário (admin merge, expansão de escopo, ação irreversível). |
incident |
Indisponibilidade externa, GitHub fora, dependência indisponível. |
external_pause |
Pausa iniciada pelo usuário que não deve contar como trabalho de dev. |
other |
Qualquer outro caso — documentar com note. |
Threshold: documentar apenas halts maiores que 2 minutos. Abaixo disso é latência conversacional, não halt.
Decisões batch pré-aprovadas: quando uma story anterior concedeu aprovação durável que cobre a atual (ex.: "Admin merge vale para todo o batch epic-setup"), marque pre_approved_batch: true na entrada do halt. PULSE registra mas não subtrai — isso premia o comportamento de batch-decision, operacionalmente correto para workflows human-in-the-loop com IA.
process_health:
halts:
- kind: approval_wait
context: admin_merge_decision
duration_min: 7
pre_approved_batch: falsePor que importa: taxa de dev de IA >> taxa de review humano. Sem isso, cada ciclo "IA faz 5min de trabalho, humano leva 5min para aprovar" é logado como 0.5x de alavancagem em vez do número real.
PULSE oferece 25 variáveis configuráveis com defaults opinionated. Durante o setup (/bmad-pulse-setup), você customiza:
- Metodologia de estimativa — horas, story points ou t-shirt sizes
- Mapeamento de campos — adapta nomes de campos do seu projeto
- Categorias de trabalho — backend/web/mobile/fullstack ou customizado
- Limiares de alavancagem — quando considerar excepcional, sólido ou alerta
- Dashboard — formato, seções e previsões
- Process Health — nível de checagens e alertas
O PULSE pode regenerar o dashboard cumulativo automaticamente após cada track-done — fechando o loop "story concluída → estado consistente" sem invocação manual de /bmad-pulse-dashboard. O trigger é opt-in via flag de configuração:
# _bmad/config.yaml — seção pulse
pulse:
# ... outras configurações PULSE ...
pulse_auto_dashboard: yes # default: 'no' (regen manual, preserva comportamento pré-flag)Quando yes, o hook on_complete padrão de bmad-pulse-track-done invoca /bmad-pulse-dashboard logo depois do card Efficiency Pulse aparecer. Quando no, ausente ou qualquer outro valor, o hook é um no-op silencioso.
Auto-regenerar dashboard.md em cada track-done garante conflitos de merge em workflows com pull requests paralelas — cada track-done reescreve o arquivo inteiro. Três estratégias documentadas de mitigação:
1. dashboard.md em .gitignore (recomendado para repos com paralelismo)
Fonte de verdade fica em sprint-status.yaml sob pulse_metrics:. Cada dev regenera localmente sob demanda. Zero conflitos, zero perda de histórico.
# .gitignore
implementation-artifacts/pulse-dashboards/dashboard.md2. Workflow CI pós-merge em main
Dashboard é regenerado por uma GitHub Action serializada e commitado direto em main com [skip ci]. Devs locais deixam pulse_auto_dashboard: no — a CI central é dona do arquivo.
# .github/workflows/pulse-dashboard.yml
on:
push:
branches: [main]
paths: ['**/sprint-status.yaml']
jobs:
regen:
runs-on: ubuntu-latest
concurrency:
group: pulse-dashboard
cancel-in-progress: false
# ... invocar /bmad-pulse-dashboard via seu runner ...3. Aceitar conflito como resolução trivial
Para times pequenos (1–2 devs trabalhando serial), git checkout --theirs dashboard.md && /bmad-pulse-dashboard resolve em ~5 segundos. Aceitável quando paralelismo é raro.
Para manter pulse_auto_dashboard: yes mas substituir o regen do dashboard por outro comportamento (push pra Grafana, notificação Slack, etc.), sobrescreva on_complete em _bmad/custom/bmad-pulse-track-done.toml. Para desabilitar completamente, defina on_complete = "" no mesmo arquivo de override.
Alavancagem sustentada de 6.9x medida em um projeto BMAD em produção (SIP — plataforma de pesquisa local-first, monorepo com apps mobile, web, backend e worker), capturada pelo próprio PULSE ao longo de múltiplas sprints.
Esse 6.9x é honesto porque é lido vs uma referência frozen (estimated_hours_reference, denominador congelado e governado por configuração) — um benchmark fixo que não colapsa conforme o time calibra. É diferente da alavancagem-vs-plano, que colapsa para ~1.0x por construção (e vira a previsibilidade). Veja a estimativa por BCP.
PULSE usa o próprio remédio.
Esse número não é o teto, nem uma meta. É um ponto de dado vs um benchmark fixo. PULSE existe para que seu time encontre o dele — e a métrica-herói continua sendo previsibilidade, não o multiplicador.
O PULSE está mudando sua métrica-norte de um multiplicador de alavancagem para previsibilidade. Cada marco abaixo operacionaliza essa mudança.
- v0.5 — Engine de medição honesto. Estimador de
h/BCPpor média geométrica (não aritmética), segmentação micro vs story-size, faixa de confiança em vez de ponto, e contract test anti-Goodhart. - v0.6 — Inverter o velocímetro. A métrica-herói passa a ser convergência/acurácia (um ~1.0x estável é saudável; um multiplicador alto sinaliza estimativa inflada, não velocidade) mais o drift auto-referente de
h/BCP. Detecção de regime viaestimated_hours_basis. Três enquadramentos de multiplicador: "vs PLANO" (colapsa → previsibilidade) e "vs REFERÊNCIA frozen" (denominador congelado, ROI estável que não colapsa, lendoestimated_hours_referencedobmad-module-bcp) — nunca "vs humano". - v0.7 — A ação que importa. Um alerta de drift no momento da estimativa — "stories como X erraram +N% nas últimas K — reestimar?" — interrompendo a estimativa ruim antes de virar compromisso.
- v0.8 — Previsibilidade para precificar. Forecast de projeto
BCP × h/BCP ± IC(90%)para times que faturam por hora; quebras por desenvolvedor/agente e digests Slack/Linear entram aqui. - v0.9 — A régua entra em casa. A pontuação BCP passa a ser uma feature opt-in do próprio PULSE (as seis skills
bmad-bcp-*), em vez de um módulo separado que precisava ser instalado ao lado. Levi se aposenta e Max assume como Analista de Previsibilidade de Entrega. - v1.0 — Proposta à equipe principal do BMAD para adoção nativa.
Nota de leitura. Os marcos até a v0.8 foram entregues quando a pontuação BCP ainda vivia num módulo separado, e os textos acima preservam isso — é o registro do que foi entregue quando. Da v0.9 em diante, tudo o que eles chamam de "módulo BCP" mora aqui.
Por que a mudança? Os próprios dados do PULSE mostraram que a alavancagem mede o basis da estimativa, não o trabalho — calibrar empurra qualquer multiplicador para 1.0x por construção, então uma meta de alavancagem literalmente premia nunca calibrar. O sinal durável é previsibilidade: você entregou o que prometeu, e consegue provar? O gráfico 10x→1x não é o problema — é o moat. (Telemetria de uso de tokens fica parqueada como possível módulo separado.)
- BMAD Method >= 6.4.0 (veja MIGRATION.md se atualizando da v0.3.x)
- Python >= 3.9 (para scripts de setup)
- Assistente de IA agnóstico — Claude Code, Cursor, Copilot ou qualquer outro. PULSE mede o squad, não a IDE.
Ver histórico em star-history.com
MIT — veja LICENSE.
PULSE — Contra fatos, não há argumentos.