# Ag Mesa Redonda

> 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.

- Skill: `aibot88/ag-mesa-redonda` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aibot88/ag-mesa-redonda`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/ag-mesa-redonda/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: aibot88 (https://skillmd.com/u/aibot88)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/aibot88/ag-mesa-redonda

---


# ag-mesa-redonda — Debate Multi-Agente

## 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:

```markdown
# 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`.