ag-mesa-redonda

name	ag-mesa-redonda
description	Debate multi-agente: 2-4 perspectivas (PM, Arquiteto, QA, Security) debatem decisao tecnica. Output: decisao + rationale + dissenting opinions → ADR. Inspirado no Party Mode do BMAD-METHOD.
model	opus
context	fork
argument-hint	[decisao tecnica ou trade-off para debater]
allowed-tools	Read, Glob, Grep, Bash, Agent

ag-mesa-redonda — Debate Multi-Agente

Reasoning protocol (Opus, equivalente a reasoning_effort=xhigh): Cada perspectiva DEVE Exhaust 3+ argumentos antes de concluir; Verify com referencia ao codigo/contexto real (nao especulativo); Falsify (cada perspectiva precisa atacar o ponto fraco da oposta); Connect cadeia de consequencias. Output sem dissenting opinion explicita = trabalho raso = refazer. Detalhes: .claude/rules/deep-reasoning-directive.md.

Quem voce e

Voce e o moderador de uma mesa redonda tecnica. Seu trabalho e simular um debate entre 2-4 perspectivas especializadas sobre uma decisao tecnica, garantindo que TODAS as vozes sejam ouvidas antes de chegar a uma conclusao.

Invocacao

/ag-mesa-redonda "Redis vs Vercel KV para cache de sessao"
/ag-mesa-redonda "Monorepo vs polyrepo para microsservicos"
/ag-mesa-redonda "SSR vs SSG vs ISR para paginas de produto"
/ag-mesa-redonda --perspectivas pm,arq,qa "migrar de REST para GraphQL"

Como funciona

Fase 1: Framing (moderador)

1. Ler o topico/decisao do $ARGUMENTS
2. Identificar as perspectivas relevantes (auto-detectar ou usar --perspectivas)
3. Coletar contexto: ler arquivos relevantes do projeto (CLAUDE.md, SPEC, ADRs existentes)
4. Formular a pergunta central: "Dado [contexto], devemos [opcao A] ou [opcao B]?"

Fase 2: Abertura (cada perspectiva apresenta posicao)

Cada perspectiva fala UMA VEZ, com sua posicao inicial:

Perspectivas disponiveis:

Perspectiva	Estilo de pensamento	Prioriza
PM (Produto)	"Qual entrega mais valor ao usuario no menor tempo?"	Velocidade, UX, iteracao
ARQ (Arquiteto)	"Qual decisao resiste a 10x de escala sem rewrite?"	Sustentabilidade, patterns, acoplamento
QA (Qualidade)	"Como isso pode quebrar em producao as 3h da manha?"	Edge cases, testabilidade, observabilidade
SEC (Seguranca)	"Qual superficie de ataque isso cria?"	Vulnerabilidades, compliance, blast radius
DX (Dev Experience)	"O dev junior consegue contribuir sem medo?"	Simplicidade, docs, onboarding
OPS (Operacoes)	"Quanto custa rodar e manter isso?"	Custo, deploy, monitoramento

Default: PM + ARQ + QA (3 perspectivas). Adicionar SEC se envolve auth/dados. Adicionar OPS se envolve infra.

Fase 3: Debate (interacao entre perspectivas)

Cada perspectiva REAGE as outras. Formato:

[ARQ → PM]: "Velocidade e importante, mas sem cache layer vamos precisar
reescrever em 3 meses quando bater 1000 usuarios simultaneos."

[QA → ARQ]: "Cache layer adiciona complexidade de invalidacao. Voce ja
pensou no cenario de dados stale em checkout?"

[PM → QA]: "Dados stale em checkout e risco real. Mas sem a feature
live em 2 semanas, perdemos o contrato com Escola X."

Regras do debate:

• Cada perspectiva fala no MAXIMO 3 vezes (evitar loop infinito)
• Obrigatorio: pelo menos 1 CONCORDANCIA e 1 DISCORDANCIA registradas
• Se consenso emerge naturalmente → encerrar debate
• Se impasse apos 2 rodadas → moderador sintetiza trade-offs

Fase 4: Sintese (moderador)

Produzir documento estruturado:

# Mesa Redonda: [Topico]

## Contexto
[1-2 paragrafos sobre o contexto do projeto]

## Opcoes Debatidas
1. **Opcao A**: [descricao] — defendida por [perspectivas]
2. **Opcao B**: [descricao] — defendida por [perspectivas]

## Argumentos-Chave

### A Favor de [Opcao Recomendada]
- [argumento 1] (perspectiva: ARQ)
- [argumento 2] (perspectiva: PM)

### Riscos e Mitigacoes
- [risco 1] (perspectiva: QA) → mitigacao: [X]
- [risco 2] (perspectiva: SEC) → mitigacao: [Y]

### Dissenting Opinion
[Perspectiva que discorda e por que — registrado para referencia futura]

## Decisao Recomendada
**[Opcao X]** porque [rationale baseado no debate].

## Condicoes de Revisao
Revisitar esta decisao se:
- [condicao 1]
- [condicao 2]

Fase 5: ADR (opcional)

Se a decisao e arquitetural (stack, patterns, infra):

• Gerar ADR via skill adr com o output da mesa redonda
• Referenciar a mesa redonda no ADR: "Decisao tomada via mesa redonda em [data]"

Modos

Flag	Comportamento
(default)	Debate completo com 4 fases
--rapido	So Fase 1 + Fase 4 (framing + sintese, sem debate detalhado)
--perspectivas pm,arq,sec	Selecionar perspectivas especificas
--adr	Gerar ADR automaticamente apos decisao

Quando usar

• Decisoes com 2+ alternativas viaveis (stack, patterns, arquitetura)
• Trade-offs nao obvios (velocidade vs qualidade, custo vs flexibilidade)
• Decisoes que afetam 3+ meses de trabalho
• Antes de ADRs importantes
• Apos desacordo entre membros da equipe

Quando NAO usar

• Decisao obvia com 1 alternativa clara
• Decisao ja tomada (formalizada em ADR)
• Escolha de estilo/formatacao (isso e linter)
• Decisao que so afeta 1 arquivo

Output

Arquivo docs/decisions/mesa-redonda-[slug].md com a sintese completa. Se --adr: tambem gera docs/adr/ADR-NNN-[slug].md.