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 o
bmad-module-bcpgravaestimated_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 do Levi, 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 — Levi (o 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.
⚠ 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 |
Levi é o Analista de Hyper-Efficiency do PULSE. Ele 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. Comemora vitórias reais, aponta desvios e sugere correções no processo.
Ele não moraliza. Ele aponta.
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. Levi 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 — Levi 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 pelo bmad-module-bcp) — 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 integração com 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. - v1.0 — Proposta à equipe principal do BMAD para adoção nativa.
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.