Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From cook-pt
Facilitates structured multi-role debates to explore trade-offs and find compromises. Use for architecture decisions, technology selection, or balancing priorities.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cook-pt:role-debateThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Comando onde diferentes papéis especializados debatem, consideram trade-offs e derivam soluções ótimas.
Comando onde diferentes papéis especializados debatem, consideram trade-offs e derivam soluções ótimas.
/role-debate <papel 1>,<papel 2> [tópico]
/role-debate <papel 1>,<papel 2>,<papel 3> [tópico]
# Trade-off entre Segurança vs Performance
/role-debate security,performance
"Sobre configuração de tempo de validade do token JWT"
# Equilíbrio entre Usabilidade vs Segurança
/role-debate frontend,security
"Sobre otimização de UX para autenticação de dois fatores"
# Discussão de seleção tecnológica
/role-debate architect,mobile
"Sobre escolha entre React Native vs Flutter"
# Debate entre 3 papéis
/role-debate architect,security,performance
"Sobre prós e contras da arquitetura de microsserviços"
Cada papel expressa opinião independentemente de perspectiva especializada
Debate cruzado entre papéis
Busca por soluções implementáveis
Determinação de recomendações finais
Debate de Papéis: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tópico: Configuração de tempo de validade do token JWT
Alegação do papel Security:
"Recomendo tempo de validade curto de 15 minutos"
Base:
- Conformidade com OWASP JWT Security Cheat Sheet
- Minimização da janela de tempo de danos em caso de vazamento do token
- Limitação do tempo disponível para atacantes
Preocupações:
- Tempo de validade longo aumenta exponencialmente o risco de ataque
- Requisitos de compliance (setor financeiro) exigem tempo curto obrigatoriamente
Indicadores de sucesso:
- Taxa de ocorrência de incidentes de segurança < 0,1%
- Tempo médio de detecção de ataques < 5 minutos
Contra-argumento do papel Performance:
"Recomendo tempo de validade de 2 horas"
Base:
- Referência ao Google OAuth 2.0 Best Practices
- Evitar aumento da carga do servidor por reautenticação frequente
- Minimização da experiência do usuário (interrupção do trabalho)
Preocupações:
- Reautenticação a intervalos de 15 minutos aumenta carga da API em 8 vezes
- Desconexões frequentes em ambientes móveis
Indicadores de sucesso:
- Manter tempo de resposta da API < 200ms
- Uso de CPU do servidor < 60%
Debate mútuo:
Security → Performance:
"A perda comercial de violação de segurança é maior que a carga do servidor.
Exemplo: Incidente Equifax resultou em perda de 700 milhões de dólares"
Performance → Security:
"É possível compatibilizar ambos com mecanismo de refresh token.
Garantia de segurança sem prejudicar UX através de atualização em background"
Security → Performance:
"Refresh token também é alvo de ataque. Implementação adequada é pré-requisito"
Performance → Security:
"Proponho abordagem em fases. Operações normais 30 min, operações confidenciais 15 min"
Busca de pontos de compromisso:
Entendimento comum:
- Necessária compatibilização entre experiência do usuário e segurança
- Resposta flexível de acordo com nível de risco
- Consideração realista de custos de implementação e operação
Elementos Win-Win:
- Utilização de mecanismo de refresh token
- Introdução em fases de autenticação baseada em risco
- Complementação com função de logout automático
Conclusão integrada:
"30 min de validade + refresh token + autenticação baseada em risco"
Detalhes da implementação:
1. Access token: 30 min de validade
2. Refresh token: 7 dias de validade
3. Operações de alto risco: reautenticação forçada em 15 min
4. Logout automático após 30 min sem operação
Implementação em fases:
Semana 1-2: Implementação básica de token de 30 min
Semana 3-4: Adição de mecanismo de refresh token
Mês 2: Introdução de autenticação baseada em risco
Indicadores de sucesso:
- Segurança: Taxa de ocorrência de incidentes < 0,1%
- Performance: Taxa de aumento de carga da API < 20%
- UX: Satisfação do usuário > 85%
Revisão futura:
- Após 3 meses: Avaliar padrões de ataque reais e situação de carga
- Após 6 meses: Considerar migração para autenticação baseada em risco mais refinada
Debate de Papéis: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tópico: Prós e contras da arquitetura de microsserviços
Alegação do papel Architect:
"Recomendo microsserviços em fases"
Base: Clarificação de fronteiras de domínio, deploy independente, liberdade de escolha tecnológica
Preocupação do papel Security:
"Complexificação da segurança da comunicação entre serviços"
Base: Custos de gerenciamento de API Gateway, mTLS, autenticação distribuída
Preocupação do papel Performance:
"Aumento de latência por comunicação de rede"
Base: Problema N+1 por chamadas de API internas, transações distribuídas
Debate entre 3 papéis:
Architect → Security: "Possível controle por gerenciamento centralizado com API Gateway"
Security → Architect: "Risco de se tornar ponto único de falha"
Performance → Architect: "Importante a granularidade da divisão de serviços"
...(continuação do debate)
Conclusão integrada:
"Divisão em fases por Domain-Driven Design + design security-first"
/role-debate architect,performance
"Escolha de banco de dados: PostgreSQL vs MongoDB"
/role-debate frontend,mobile
"Framework de UI: React vs Vue"
/role-debate security,architect
"Método de autenticação: JWT vs Session Cookie"
/role-debate security,frontend
"Design de UX para autenticação de usuário"
/role-debate performance,mobile
"Otimização de estratégia de sincronização de dados"
/role-debate architect,qa
"Estratégia de teste e design de arquitetura"
/role-debate security,performance
"Nível de criptografia vs velocidade de processamento"
/role-debate frontend,performance
"UI rica vs velocidade de carregamento da página"
/role-debate mobile,security
"Conveniência vs nível de proteção de dados"
Postura de debate:
- Abordagem conservadora (minimização de riscos)
- Foco em conformidade com regras (cauteloso com desvios de padrões)
- Suposição de pior caso (perspectiva do atacante)
- Foco em impacto de longo prazo (segurança como dívida técnica)
Pontos típicos:
- Trade-off "segurança vs conveniência"
- "Cumprimento obrigatório de requisitos de compliance"
- "Comparação custo de ataque vs custo de defesa"
- "Proteção completa de privacidade"
Fontes de argumentação:
- Diretrizes OWASP
- Framework NIST
- Padrões da indústria (ISO 27001, SOC 2)
- Casos e estatísticas de ataques reais
Pontos fortes no debate:
- Precisão na avaliação de riscos
- Conhecimento de requisitos regulamentares
- Entendimento de métodos de ataque
Preconceitos a serem observados:
- Conservadorismo excessivo (obstáculo à inovação)
- Falta de consideração pela UX
- Subestimação de custos de implementação
Postura de debate:
- Decisões orientadas por dados (baseadas em medições)
- Foco em eficiência (otimização custo-benefício)
- Prioridade na experiência do usuário (foco na velocidade percebida)
- Melhoria contínua (otimização em fases)
Pontos típicos:
- "Performance vs segurança"
- "ROI do custo vs efeito da otimização"
- "Escalabilidade atual vs futura"
- "Experiência do usuário vs eficiência do sistema"
Fontes de argumentação:
- Métricas Core Web Vitals
- Resultados de benchmark e estatísticas
- Dados de impacto no comportamento do usuário
- Padrões de performance da indústria
Pontos fortes no debate:
- Capacidade de avaliação quantitativa
- Identificação de gargalos
- Conhecimento de técnicas de otimização
Preconceitos a serem observados:
- Subestimação da segurança
- Falta de consideração pela manutenibilidade
- Otimização prematura
Postura de debate:
- Foco na perspectiva de longo prazo (consideração da evolução do sistema)
- Busca de equilíbrio (otimização global)
- Mudanças graduais (gestão de riscos)
- Conformidade com padrões (prioridade de padrões testados)
Pontos típicos:
- "Eficiência de curto prazo vs manutenibilidade de longo prazo"
- "Dívida técnica vs velocidade de desenvolvimento"
- "Microsserviços vs monólito"
- "Adoção de novas tecnologias vs estabilidade"
Fontes de argumentação:
- Coleção de padrões de arquitetura
- Princípios de design (SOLID, DDD)
- Casos de sistemas de grande escala
- Tendências de evolução tecnológica
Pontos fortes no debate:
- Capacidade de visão global
- Conhecimento de padrões de design
- Previsão de impactos de longo prazo
Preconceitos a serem observados:
- Generalização excessiva
- Conservadorismo com novas tecnologias
- Falta de compreensão de detalhes de implementação
Postura de debate:
- Design centrado no usuário (prioridade máxima na UX)
- Abordagem inclusiva (consideração da diversidade)
- Foco na intuitividade (minimização do custo de aprendizado)
- Padrões de acessibilidade (conformidade WCAG)
Pontos típicos:
- "Usabilidade vs segurança"
- "Unificação de design vs otimização de plataforma"
- "Funcionalidade vs simplicidade"
- "Performance vs experiência rica"
Fontes de argumentação:
- Resultados de pesquisa UX e testes de usabilidade
- Diretrizes de acessibilidade
- Padrões de sistema de design
- Dados de comportamento do usuário
Pontos fortes no debate:
- Defesa da perspectiva do usuário
- Conhecimento de princípios de design
- Requisitos de acessibilidade
Preconceitos a serem observados:
- Falta de compreensão de restrições técnicas
- Subestimação de requisitos de segurança
- Subestimação do impacto na performance
Postura de debate:
- Especialização em plataforma (consideração de diferenças iOS/Android)
- Adaptação contextual (uso em movimento, operação com uma mão)
- Restrições de recursos (bateria, memória, comunicação)
- Conformidade com lojas (diretrizes de revisão)
Pontos típicos:
- "Nativo vs multiplataforma"
- "Suporte offline vs sincronização em tempo real"
- "Eficiência da bateria vs funcionalidade"
- "Unificação vs otimização de plataforma"
Fontes de argumentação:
- iOS HIG / Android Material Design
- Diretrizes App Store / Google Play
- Pesquisa UX móvel
- Estatísticas de performance de dispositivos
Pontos fortes no debate:
- Compreensão de restrições específicas móveis
- Conhecimento de diferenças de plataforma
- Design de interface touch
Preconceitos a serem observados:
- Falta de compreensão de plataformas web
- Subestimação de restrições do lado servidor
- Falta de consideração por ambientes desktop
Postura de debate:
- Foco em evidências (data-first)
- Verificação de hipóteses (abordagem científica)
- Pensamento estrutural (pensamento sistêmico)
- Remoção de vieses (busca de objetividade)
Pontos típicos:
- "Correlação vs causalidade"
- "Tratamento sintomático vs solução fundamental"
- "Distinção entre hipótese vs fato"
- "Sintomas de curto prazo vs problemas estruturais"
Fontes de argumentação:
- Dados de medição real e análise de logs
- Métodos estatísticos e resultados de análise
- Teoria do pensamento sistêmico
- Pesquisa sobre vieses cognitivos
Pontos fortes no debate:
- Capacidade de análise lógica
- Objetividade na avaliação de evidências
- Descoberta de problemas estruturais
Preconceitos a serem observados:
- Paralisia analítica (falta de capacidade de ação)
- Perfeccionismo (subestimação da praticidade)
- Supremacia dos dados
Proposta recomendada do 【Nome do Papel】:
"[proposta específica]"
Base:
- [referência a documentos/padrões oficiais]
- [casos de prova/dados]
- [princípios da área especializada]
Efeitos esperados:
- [efeitos de curto prazo]
- [efeitos de médio a longo prazo]
Preocupações/Riscos:
- [riscos de implementação]
- [riscos operacionais]
- [impactos em outras áreas]
Indicadores de sucesso:
- [indicador mensurável 1]
- [indicador mensurável 2]
Contra-argumento para [Papel Alvo]:
"[contra-argumento específico à proposta alvo]"
Base da refutação:
- [perspectiva negligenciada]
- [evidências/casos conflitantes]
- [preocupações da área especializada]
Proposta alternativa:
"[proposta melhorada]"
Pontos de possível compromisso:
- [condições aceitáveis]
- [possibilidade de implementação em fases]
Proposta de solução integrada:
"[proposta final considerando preocupações de cada papel]"
Considerações para cada papel:
- [Security]: [método de satisfação dos requisitos de segurança]
- [Performance]: [método de satisfação dos requisitos de performance]
- [Outros]: [método de satisfação de outros requisitos]
Roadmap de implementação:
- Fase 1 (imediato): [itens de resposta urgente]
- Fase 2 (curto prazo): [implementação básica]
- Fase 3 (médio prazo): [implementação completa]
Indicadores de sucesso/Métodos de medição:
- [indicadores integrados de sucesso]
- [métodos/frequência de medição]
- [timing de revisão]
# Debate baseado em documentos de design
cat system-design.md
/role-debate architect,security
"Debata sobre questões de segurança neste design"
# Debate de soluções baseado em problemas
cat performance-issues.md
/role-debate performance,architect
"Debata sobre soluções fundamentais para problemas de performance"
# Debate de seleção tecnológica baseado em requisitos
/role-debate mobile,frontend
"Debata sobre estratégia de UI unificada para iOS, Android e Web"
npx claudepluginhub wasabeef/claude-code-cookbook --plugin cook-ptFacilitates structured multi-role debates to explore trade-offs and derive optimal solutions. Useful for architecture decisions, technology selection, and balancing competing priorities.
Facilitates structured multi-role debates to explore trade-offs and derive compromises. Useful for architecture, security, and performance decisions.
Spawns multiple expert roles to debate design/architecture trade-offs and produce integrated, balanced conclusions.