Initial commit
This commit is contained in:
Zhongwei Li
158
commands/analyze-dependencies.md
Normal file
158
commands/analyze-dependencies.md
Normal file
@@ -0,0 +1,158 @@
|
||||
## Análise de Dependências
|
||||
|
||||
Analisa as dependências do projeto e avalia a saúde da arquitetura.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/dependency-analysis [opções]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--visual` : Exibe as dependências visualmente
|
||||
- `--circular` : Detecta apenas dependências circulares
|
||||
- `--depth <número>` : Especifica a profundidade da análise (padrão: 3)
|
||||
- `--focus <caminho>` : Foca em um módulo/diretório específico
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Análise completa das dependências do projeto
|
||||
/dependency-analysis
|
||||
|
||||
# Detecção de dependências circulares
|
||||
/dependency-analysis --circular
|
||||
|
||||
# Análise detalhada de um módulo específico
|
||||
/dependency-analysis --focus src/core --depth 5
|
||||
```
|
||||
|
||||
### Itens de Análise
|
||||
|
||||
#### 1. Matriz de Dependências
|
||||
|
||||
Exibe as dependências entre módulos de forma numerizada:
|
||||
|
||||
- Dependências diretas
|
||||
- Dependências indiretas
|
||||
- Profundidade das dependências
|
||||
- Fan-in/Fan-out
|
||||
|
||||
#### 2. Detecção de Violações Arquiteturais
|
||||
|
||||
- Violações de camadas (camada inferior dependendo da superior)
|
||||
- Dependências circulares
|
||||
- Acoplamento excessivo (alta dependência)
|
||||
- Módulos isolados
|
||||
|
||||
#### 3. Verificação de Conformidade com Clean Architecture
|
||||
|
||||
- Independência da camada de domínio
|
||||
- Separação adequada da camada de infraestrutura
|
||||
- Direção das dependências da camada de casos de uso
|
||||
- Status da aplicação de interfaces
|
||||
|
||||
### Exemplo de Saída
|
||||
|
||||
```text
|
||||
Relatório de Análise de Dependências
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
📊 Resumo de Métricas
|
||||
├─ Total de módulos: 42
|
||||
├─ Média de dependências: 3.2
|
||||
├─ Profundidade máxima de dependências: 5
|
||||
└─ Dependências circulares: 2 detectadas
|
||||
|
||||
⚠️ Violações Arquiteturais
|
||||
├─ [HIGH] src/domain/user.js → src/infra/database.js
|
||||
│ └─ Camada de domínio depende diretamente da camada de infraestrutura
|
||||
├─ [MED] src/api/auth.js ⟲ src/services/user.js
|
||||
│ └─ Dependência circular detectada
|
||||
└─ [LOW] src/utils/helper.js → 12 módulos
|
||||
└─ Fan-out excessivo
|
||||
|
||||
✅ Ações Recomendadas
|
||||
1. Introduzir interface UserRepository
|
||||
2. Redesenhar as responsabilidades do serviço de autenticação
|
||||
3. Dividir funções auxiliares por funcionalidade
|
||||
|
||||
📈 Gráfico de Dependências
|
||||
[Exibe diagrama visual de dependências em ASCII art]
|
||||
```
|
||||
|
||||
### Exemplos de Uso Avançado
|
||||
|
||||
```bash
|
||||
# Verificação automática em pipeline CI/CD
|
||||
/dependency-analysis --circular --fail-on-violation
|
||||
|
||||
# Definição e verificação de regras arquiteturais
|
||||
/dependency-analysis --rules .architecture-rules.yml
|
||||
|
||||
# Rastreamento de mudanças nas dependências ao longo do tempo
|
||||
/dependency-analysis --compare HEAD~10
|
||||
```
|
||||
|
||||
### Exemplo de Arquivo de Configuração (.dependency-analysis.yml)
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- name: "Domain Independence"
|
||||
source: "src/domain/**"
|
||||
forbidden: ["src/infra/**", "src/api/**"]
|
||||
|
||||
- name: "API Layer Dependencies"
|
||||
source: "src/api/**"
|
||||
allowed: ["src/domain/**", "src/application/**"]
|
||||
forbidden: ["src/infra/**"]
|
||||
|
||||
thresholds:
|
||||
max_dependencies: 8
|
||||
max_depth: 4
|
||||
coupling_threshold: 0.7
|
||||
|
||||
ignore:
|
||||
- "**/test/**"
|
||||
- "**/mocks/**"
|
||||
```
|
||||
|
||||
### Ferramentas de Integração
|
||||
|
||||
- `madge` : Visualização de dependências JavaScript/TypeScript
|
||||
- `dep-cruiser` : Validação de regras de dependências
|
||||
- `nx` : Gerenciamento de dependências em monorepo
|
||||
- `plato` : Análise integrada de complexidade e dependências
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise incluindo package.json
|
||||
cat package.json
|
||||
/analyze-dependencies
|
||||
「Analise os problemas de dependências deste projeto」
|
||||
|
||||
# Combinando com código-fonte de módulo específico
|
||||
ls -la src/core/
|
||||
/analyze-dependencies --focus src/core
|
||||
「Avalie em detalhes as dependências do módulo core」
|
||||
|
||||
# Comparação com documentação de arquitetura
|
||||
cat docs/architecture.md
|
||||
/analyze-dependencies --visual
|
||||
「Verifique a divergência entre o documento de design e a implementação」
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Pré-requisitos**: Deve ser executado na raiz do projeto
|
||||
- **Limitações**: Em projetos grandes, a análise pode demorar
|
||||
- **Recomendação**: Se dependências circulares forem encontradas, considere ação imediata
|
||||
|
||||
### Melhores Práticas
|
||||
|
||||
1. **Análise regular**: Verifique a saúde das dependências semanalmente
|
||||
2. **Formalização de regras**: Gerencie regras arquiteturais em arquivos de configuração
|
||||
3. **Melhoria gradual**: Evite refatorações em larga escala, melhore progressivamente
|
||||
4. **Rastreamento de métricas**: Monitore a complexidade das dependências ao longo do tempo
|
||||
168
commands/analyze-performance.md
Normal file
168
commands/analyze-performance.md
Normal file
@@ -0,0 +1,168 @@
|
||||
## Analyze Performance
|
||||
|
||||
Analisa o desempenho da aplicação sob a perspectiva da experiência do usuário e quantifica as melhorias de velocidade percebida através de otimizações. Calcula pontuações UX baseadas em Core Web Vitals e propõe estratégias de otimização priorizadas.
|
||||
|
||||
### Pontuação de Performance UX
|
||||
|
||||
```text
|
||||
Pontuação de Experiência do Usuário: B+ (78/100)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
⏱️ Core Web Vitals
|
||||
├─ LCP (carregamento): 2.3s [Bom] Meta<2.5s ✅
|
||||
├─ FID (resposta): 95ms [Bom] Meta<100ms ✅
|
||||
├─ CLS (estabilidade): 0.08 [Bom] Meta<0.1 ✅
|
||||
├─ FCP (primeiro desenho): 1.8s [Bom] Meta<1.8s ✅
|
||||
├─ TTFB (servidor): 450ms [Precisa melhorar] Meta<200ms ⚠️
|
||||
└─ TTI (interativo): 3.5s [Precisa melhorar] Meta<3.8s ⚠️
|
||||
|
||||
📊 Velocidade Percebida pelo Usuário
|
||||
├─ Exibição inicial: 2.3s [Média da indústria: 3.0s]
|
||||
├─ Transição de página: 1.1s [Média da indústria: 1.5s]
|
||||
├─ Exibição resultados busca: 0.8s [Média da indústria: 1.2s]
|
||||
├─ Envio de formulário: 1.5s [Média da indústria: 2.0s]
|
||||
└─ Carregamento de imagens: lazy loading implementado ✅
|
||||
|
||||
😊 Previsão de Satisfação do Usuário
|
||||
├─ Previsão taxa de rejeição: 12% (média da indústria: 20%)
|
||||
├─ Previsão taxa de conclusão: 78% (objetivo: 85%)
|
||||
├─ NPS recomendado: +24 (média da indústria: +15)
|
||||
└─ Taxa de retorno: 65% (objetivo: 70%)
|
||||
|
||||
📊 Impacto na Experiência do Usuário
|
||||
├─ Acelerar exibição 0.5s → taxa rejeição -7%
|
||||
├─ Reduzir taxa rejeição 5% → duração sessão +15%
|
||||
├─ Melhorar busca → tempo permanência +15%
|
||||
└─ Melhoria UX geral: +25%
|
||||
|
||||
🎯 Efeitos Esperados de Melhoria (ordem de prioridade)
|
||||
├─ [P0] Melhoria TTFB (introduzir CDN) → LCP -0.3s = velocidade percebida +15%
|
||||
├─ [P1] Otimização bundle JS → TTI -0.8s = tempo interativo -20%
|
||||
├─ [P2] Otimização imagens (WebP) → volume transferência -40% = tempo carregamento -25%
|
||||
└─ [P3] Estratégia cache → 50% mais rápido em visitas repetidas
|
||||
```
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Análise integral da pontuação UX
|
||||
find . -name "*.js" -o -name "*.ts" | xargs wc -l | sort -rn | head -10
|
||||
「Calcular pontuação de performance UX e avaliar Core Web Vitals」
|
||||
|
||||
# Detecção de gargalos de performance
|
||||
grep -r "for.*await\|forEach.*await" . --include="*.js"
|
||||
「Detectar gargalos de processamento assíncrono e analisar impacto na experiência do usuário」
|
||||
|
||||
# Análise de impacto na experiência do usuário
|
||||
grep -r "addEventListener\|setInterval" . --include="*.js" | grep -v "removeEventListener\|clearInterval"
|
||||
「Analisar o impacto de problemas de performance na experiência do usuário」
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Tamanho de bundle e tempo de carregamento
|
||||
npm ls --depth=0 && find ./public -name "*.js" -o -name "*.css" | xargs ls -lh
|
||||
"Identificar pontos de melhoria no tamanho do bundle e otimização de assets"
|
||||
|
||||
# Performance de banco de dados
|
||||
grep -r "SELECT\|findAll\|query" . --include="*.js" | head -20
|
||||
"Analisar pontos de otimização de consultas de banco de dados"
|
||||
|
||||
# Impacto de performance das dependências
|
||||
npm outdated && npm audit
|
||||
"Avaliar o impacto de dependências desatualizadas no desempenho"
|
||||
```
|
||||
|
||||
### Perspectivas de Análise
|
||||
|
||||
#### 1. Problemas no Nível de Código
|
||||
|
||||
- **Algoritmos O(n²)**: Detecção de operações de array ineficientes
|
||||
- **I/O síncrono**: Identificação de processos bloqueantes
|
||||
- **Processamento duplicado**: Remoção de cálculos e requests desnecessários
|
||||
- **Vazamentos de memória**: Gestão de event listeners e timers
|
||||
|
||||
#### 2. Problemas no Nível de Arquitetura
|
||||
|
||||
- **Consultas N+1**: Padrões de acesso ao banco de dados
|
||||
- **Falta de cache**: Cálculos repetidos e chamadas API
|
||||
- **Tamanho de bundle**: Bibliotecas desnecessárias e divisão de código
|
||||
- **Gestão de recursos**: Uso de connection pools e threads
|
||||
|
||||
#### 3. Impacto da Dívida Técnica
|
||||
|
||||
- **Código legacy**: Degradação de performance por implementações antigas
|
||||
- **Problemas de design**: Alto acoplamento por falta de distribuição de responsabilidades
|
||||
- **Falta de testes**: Falta de detecção de regressões de performance
|
||||
- **Falta de monitoramento**: Sistema de detecção precoce de problemas
|
||||
|
||||
### Matriz ROI de Melhoria de Performance
|
||||
|
||||
```text
|
||||
ROI de melhoria = (efeito redução tempo + melhoria qualidade) ÷ horas implementação
|
||||
```
|
||||
|
||||
| Prioridade | Melhoria Experiência Usuário | Dificuldade Implementação | Efeito Redução Tempo | Exemplo Concreto | Horas | Efeito |
|
||||
| ----------------------------------- | ---------------------------- | ------------------------- | -------------------- | ------------------- | ----- | ----------------- |
|
||||
| **[P0] Implementar imediatamente** | Alta | Baixa | > 50% | Introduzir CDN | 8h | Resposta -60% |
|
||||
| **[P1] Implementar em breve** | Alta | Média | 20-50% | Otimizar imagens | 16h | Carregamento -30% |
|
||||
| **[P2] Implementar planejadamente** | Baixa | Alta | 10-20% | Divisão código | 40h | Inicial -15% |
|
||||
| **[P3] Reter/observar** | Baixa | Baixa | < 10% | Otimizações menores | 20h | Parcial -5% |
|
||||
|
||||
#### Critérios de Determinação de Prioridade
|
||||
|
||||
- **P0 (implementar imediatamente)**: Melhoria UX "Alta" × Dificuldade "Baixa" = ROI máximo
|
||||
- **P1 (implementar em breve)**: Melhoria UX "Alta" × Dificuldade "Média" = ROI alto
|
||||
- **P2 (planejadamente)**: Melhoria UX "Baixa" × Dificuldade "Alta" = ROI médio
|
||||
- **P3 (reter)**: Melhoria UX "Baixa" × Dificuldade "Baixa" = ROI baixo
|
||||
|
||||
### Correlação entre Métricas de Performance e Melhoria UX
|
||||
|
||||
| Métrica | Faixa Melhoria | Melhoria Velocidade Percebida | Satisfação Usuário | Horas Implementação |
|
||||
| ---------------------- | -------------- | ----------------------------- | ------------------------- | ------------------- |
|
||||
| **LCP (carregamento)** | -0.5s | +30% | Taxa rejeição -7% | 16h |
|
||||
| **FID (resposta)** | -50ms | +15% | Estresse -20% | 8h |
|
||||
| **CLS (estabilidade)** | -0.05 | +10% | Operação errônea -50% | 4h |
|
||||
| **TTFB (servidor)** | -200ms | +25% | Velocidade percebida +40% | 24h |
|
||||
| **TTI (interativo)** | -1.0s | +35% | Taxa conclusão +15% | 32h |
|
||||
| **Tamanho bundle** | -30% | +20% | Primeira visita +25% | 16h |
|
||||
|
||||
### Medição e Ferramentas
|
||||
|
||||
#### Node.js / JavaScript
|
||||
|
||||
```bash
|
||||
# Profiling
|
||||
node --prof app.js
|
||||
clinic doctor -- node app.js
|
||||
|
||||
# Análise de bundle
|
||||
npx webpack-bundle-analyzer
|
||||
lighthouse --chrome-flags="--headless"
|
||||
```
|
||||
|
||||
#### Banco de Dados
|
||||
|
||||
```sql
|
||||
-- Análise de consultas
|
||||
EXPLAIN ANALYZE SELECT ...
|
||||
SHOW SLOW LOG;
|
||||
```
|
||||
|
||||
#### Frontend
|
||||
|
||||
```bash
|
||||
# Performance React
|
||||
grep -r "useMemo\|useCallback" . --include="*.jsx"
|
||||
|
||||
# Análise de recursos
|
||||
find ./src -name "*.png" -o -name "*.jpg" | xargs ls -lh
|
||||
```
|
||||
|
||||
### Melhoria Contínua
|
||||
|
||||
- **Auditoria regular**: Execução de testes de performance semanais
|
||||
- **Coleta de métricas**: Rastreamento de tempo de resposta e uso de memória
|
||||
- **Configuração de alertas**: Notificação automática quando limites são excedidos
|
||||
- **Compartilhamento com equipe**: Documentação de casos de melhoria e antipadrões
|
||||
104
commands/check-fact.md
Normal file
104
commands/check-fact.md
Normal file
@@ -0,0 +1,104 @@
|
||||
## Verificar Fatos
|
||||
|
||||
Comando para verificar a precisão de informações fornecidas, referenciando a base de código do projeto e documentação (docs/, README.md, etc.).
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Uso básico
|
||||
/check-fact "O aplicativo Flutter usa Riverpod"
|
||||
|
||||
# Verificar múltiplas informações de uma vez
|
||||
/check-fact "Este projeto usa GraphQL e gerencia roteamento com auto_route"
|
||||
|
||||
# Verificar especificações técnicas específicas
|
||||
/check-fact "A autenticação usa JWT e não usa Firebase Auth"
|
||||
```
|
||||
|
||||
### Processo de Verificação
|
||||
|
||||
1. **Prioridade das Fontes de Informação**
|
||||
- Base de código (mais confiável)
|
||||
- README.md, documentação em docs/
|
||||
- Arquivos de configuração como package.json, pubspec.yaml
|
||||
- Histórico de discussões em Issues e Pull Requests
|
||||
|
||||
2. **Classificação dos Resultados**
|
||||
- `✅ Correto` - A informação coincide completamente com a base de código
|
||||
- `❌ Incorreto` - A informação está claramente errada
|
||||
- `⚠️ Parcialmente correto` - Parcialmente preciso, mas incompleto
|
||||
- `❓ Não pode julgar` - Falta informação necessária para verificação
|
||||
|
||||
3. **Demonstração de Evidências**
|
||||
- Nome do arquivo e número da linha
|
||||
- Trechos de código relevantes
|
||||
- Seção correspondente da documentação
|
||||
|
||||
### Formato do Relatório
|
||||
|
||||
```text
|
||||
## Resultado da Verificação de Fatos
|
||||
|
||||
### Alvo de Verificação
|
||||
"[Informação fornecida pelo usuário]"
|
||||
|
||||
### Conclusão
|
||||
[✅/❌/⚠️/❓] [Resultado da avaliação]
|
||||
|
||||
### Evidência
|
||||
- **Arquivo**: `path/to/file.dart:123`
|
||||
- **Conteúdo**: [Código/texto correspondente]
|
||||
- **Observação**: [Explicação adicional]
|
||||
|
||||
### Explicação Detalhada
|
||||
[Se incorreto, apresentar informação correta]
|
||||
[Se parcialmente correto, apontar partes imprecisas]
|
||||
[Se não pode julgar, explicar informação em falta]
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Verificação da stack tecnológica do projeto
|
||||
/check-fact "Este app tem configuração Flutter + Riverpod + GraphQL"
|
||||
|
||||
# Verificação do status de implementação
|
||||
/check-fact "A funcionalidade de modo escuro está implementada e pode ser alternada nas configurações do usuário"
|
||||
|
||||
# Verificação da arquitetura
|
||||
/check-fact "Todo gerenciamento de estado é feito com Riverpod, não usa BLoC"
|
||||
|
||||
# Verificação de implementação de segurança
|
||||
/check-fact "Tokens de autenticação são armazenados criptografados no secure storage"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Verificação após análise completa da base de código
|
||||
ls -la && find . -name "pubspec.yaml" -exec cat {} \;
|
||||
/check-fact "As principais dependências usadas neste projeto são..."
|
||||
|
||||
# Verificação do status de implementação de funcionalidades específicas
|
||||
grep -r "authentication" . --include="*.dart"
|
||||
/check-fact "A funcionalidade de autenticação é implementação customizada, não usa autenticação de terceiros"
|
||||
|
||||
# Verificação de consistência com documentação
|
||||
cat README.md
|
||||
/check-fact "Todas as funcionalidades descritas no README estão implementadas"
|
||||
```
|
||||
|
||||
### Cenários de Uso
|
||||
|
||||
- Criação de especificações técnicas: Verificação da precisão do conteúdo
|
||||
- Transferência de projeto: Verificação de compreensão da implementação existente
|
||||
- Antes de relatórios ao cliente: Verificação factual do status de implementação
|
||||
- Escrita de blog técnico: Verificação da precisão do conteúdo do artigo
|
||||
- Criação de materiais para entrevista/apresentação: Verificação da precisão do resumo do projeto
|
||||
|
||||
### Observações
|
||||
|
||||
- A base de código é a fonte de informação mais confiável
|
||||
- Quando a documentação está desatualizada, a implementação tem prioridade
|
||||
- Se falta informação necessária para julgamento, honestamente marcar como "não pode julgar"
|
||||
- Informações relacionadas à segurança são verificadas com especial cuidado
|
||||
53
commands/check-github-ci.md
Normal file
53
commands/check-github-ci.md
Normal file
@@ -0,0 +1,53 @@
|
||||
## Monitoramento de CI do GitHub
|
||||
|
||||
Monitora o status do CI do GitHub Actions e acompanha até a conclusão.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Verificar status dos checks do CI
|
||||
gh pr checks
|
||||
```
|
||||
|
||||
### Exemplo Básico
|
||||
|
||||
```bash
|
||||
# Verificação do CI após criação de PR
|
||||
gh pr create --title "Adição de nova funcionalidade" --body "descrição"
|
||||
gh pr checks
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Fluxo desde verificação do CI até correção
|
||||
gh pr checks
|
||||
"Analise os resultados dos checks do CI e proponha métodos de correção se houver itens com falha"
|
||||
|
||||
# Reverificação após correção
|
||||
git push origin feature-branch
|
||||
gh pr checks
|
||||
"Verifique os resultados do CI após correção e confirme que não há problemas"
|
||||
```
|
||||
|
||||
### Exemplo de Resultado de Execução
|
||||
|
||||
```text
|
||||
All checks were successful
|
||||
0 cancelled, 0 failing, 8 successful, 3 skipped, and 0 pending checks
|
||||
|
||||
NAME DESCRIPTION ELAPSED URL
|
||||
○ Build/test (pull_request) 5m20s https://github.com/user/repo/actions/runs/123456789
|
||||
○ Build/lint (pull_request) 2m15s https://github.com/user/repo/actions/runs/123456789
|
||||
○ Security/scan (pull_request) 1m30s https://github.com/user/repo/actions/runs/123456789
|
||||
○ Type Check (pull_request) 45s https://github.com/user/repo/actions/runs/123456789
|
||||
○ Commit Messages (pull_request) 12s https://github.com/user/repo/actions/runs/123456789
|
||||
- Deploy Preview (pull_request) https://github.com/user/repo/actions/runs/123456789
|
||||
- Visual Test (pull_request) https://github.com/user/repo/actions/runs/123456789
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- Em caso de falha, verificar detalhes
|
||||
- Aguardar conclusão de todos os checks antes do merge
|
||||
- Reexecutar `gh pr checks` conforme necessário
|
||||
461
commands/check-prompt.md
Normal file
461
commands/check-prompt.md
Normal file
@@ -0,0 +1,461 @@
|
||||
## Verificar Prompt
|
||||
|
||||
Coleção abrangente de melhores práticas para avaliar e melhorar a qualidade de prompts para AI Agent. Sistematiza conhecimentos obtidos através de processos reais de melhoria de prompts, cobrindo todos os aspectos importantes: eliminação de ambiguidade, integração de informações, reforço de obrigatoriedade, sistema de rastreamento e melhoria contínua.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Verificar qualidade de arquivo de prompt
|
||||
cat your-prompt.md
|
||||
/check-prompt
|
||||
"Verifique a qualidade deste prompt e apresente propostas de melhoria"
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- nenhuma : Analisa o arquivo atual ou texto selecionado
|
||||
- `--category <name>` : Verifica apenas categoria específica (structure/execution/restrictions/quality/roles/improvement)
|
||||
- `--score` : Calcula apenas o score de qualidade
|
||||
- `--fix` : Proposta de correção automática dos problemas detectados
|
||||
- `--deep` : Modo de análise profunda (foco em ambiguidade, dispersão de informação, força obrigatória)
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Avaliação geral da qualidade do prompt
|
||||
cat devin/playbooks/code-review.md
|
||||
/check-prompt
|
||||
"Avalie a qualidade deste prompt em 6 categorias e apresente problemas e propostas de melhoria"
|
||||
|
||||
# Modo de análise profunda
|
||||
/check-prompt --deep
|
||||
"Verifique intensivamente ambiguidade, dispersão de informação e falta de força obrigatória e apresente propostas de melhoria fundamentais"
|
||||
|
||||
# Verificação de categoria específica
|
||||
/check-prompt --category structure
|
||||
"Verifique este prompt na perspectiva de estrutura e clareza"
|
||||
|
||||
# Detecção e correção de expressões ambíguas
|
||||
/check-prompt --fix
|
||||
"Detecte expressões ambíguas e proponha correções para expressões claras"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Princípios Fundamentais de Design
|
||||
|
||||
### Princípio 1: Eliminação Completa de Margem para Interpretação
|
||||
|
||||
- **Absolutamente proibido**: "em princípio", "recomendado", "se possível", "dependendo da situação", "julgue adequadamente"
|
||||
- **Uso obrigatório**: "obrigatoriamente", "absolutamente", "cumprimento rigoroso", "sem exceção", "forçado"
|
||||
- **Condições de exceção**: Limitação rigorosa com números ("apenas as 3 condições a seguir", "exceto estes 2 casos")
|
||||
|
||||
### Princípio 2: Integração Estratégica de Informações
|
||||
|
||||
- Integração completa de informações importantes relacionadas em uma seção
|
||||
- Resumo do quadro geral em checklist de execução
|
||||
- Eliminação completa de referências circulares ou dispersas
|
||||
|
||||
### Princípio 3: Construção de Força Obrigatória por Etapas
|
||||
|
||||
- 🔴 (nível de parada de execução) → 🟡 (qualidade importante) → 🟢 (item recomendado) hierarquia clara
|
||||
- Promoção gradual do nível recomendado para obrigatório
|
||||
- Demonstração clara do grau de impacto e métodos de tratamento em caso de violação
|
||||
|
||||
### Princípio 4: Garantia de Rastreabilidade
|
||||
|
||||
- Capacidade de registrar e verificar todos os resultados de execução
|
||||
- Prevenção técnica de relatórios falsos
|
||||
- Critérios objetivos de julgamento de sucesso/falha
|
||||
|
||||
### Princípio 5: Melhoria Baseada em Feedback
|
||||
|
||||
- Aprendizado a partir de casos reais de falha
|
||||
- Verificação contínua de eficácia
|
||||
- Detecção automática de novos padrões
|
||||
|
||||
---
|
||||
|
||||
## 📋 Itens de Verificação Abrangentes
|
||||
|
||||
### 1. 📐 Estrutura e Clareza (Pontuação: 25 pontos)
|
||||
|
||||
#### 1.1 Exibição de Prioridade de Instruções (8 pontos)
|
||||
|
||||
- [ ] Prioridades 🔴🟡🟢 são claramente indicadas em todas as instruções importantes
|
||||
- [ ] Condições de nível de parada de execução são definidas de forma específica e clara
|
||||
- [ ] Critérios de julgamento de cada prioridade são objetivos e verificáveis
|
||||
- [ ] Hierarquia de prioridades é aplicada de forma consistente
|
||||
|
||||
#### 1.2 Eliminação Completa de Expressões Ambíguas (9 pontos)
|
||||
|
||||
- [ ] **Expressões ambíguas fatais**: "em princípio", "recomendado", "se possível" = 0 ocorrências
|
||||
- [ ] **Uso de expressões obrigatórias**: Uso apropriado de "obrigatoriamente", "absolutamente", "cumprimento rigoroso", "sem exceção"
|
||||
- [ ] **Limitação numérica de condições de exceção**: Linhas de demarcação claras como "apenas 3 condições"
|
||||
- [ ] **Eliminação de margem de julgamento**: Uso apenas de expressões que não permitem múltiplas interpretações
|
||||
- [ ] **Erradicação de zonas cinzentas**: Critérios claros de julgamento em todas as situações
|
||||
|
||||
#### 1.3 Integração Estratégica de Informações (8 pontos)
|
||||
|
||||
- [ ] Dispersão de informações importantes em múltiplos locais completamente resolvida
|
||||
- [ ] Instruções relacionadas logicamente integradas em uma seção
|
||||
- [ ] Quadro geral completamente resumido em checklist de execução
|
||||
- [ ] Não existem referências circulares ou loops infinitos
|
||||
|
||||
### 2. 🎯 Executabilidade (Pontuação: 20 pontos)
|
||||
|
||||
#### 2.1 Integridade de Procedimentos Específicos (7 pontos)
|
||||
|
||||
- [ ] Todos os exemplos de comandos são executáveis e verificados
|
||||
- [ ] Variáveis de ambiente, pré-requisitos e dependências claramente especificados
|
||||
- [ ] Métodos de tratamento de erros específicos e executáveis
|
||||
- [ ] Ordem dos procedimentos lógica e com necessidade
|
||||
|
||||
#### 2.2 Garantia de Verificabilidade (7 pontos)
|
||||
|
||||
- [ ] Sucesso/falha dos resultados de execução podem ser julgados objetivamente
|
||||
- [ ] Exemplos de saída, formatos de log e valores esperados mostrados especificamente
|
||||
- [ ] Métodos de teste e procedimentos de verificação implementáveis
|
||||
- [ ] Pontos de verificação de resultados intermediários adequadamente posicionados
|
||||
|
||||
#### 2.3 Adaptabilidade à Automação (6 pontos)
|
||||
|
||||
- [ ] Formato fácil para criação de scripts e integração CI/CD
|
||||
- [ ] Separação clara entre partes de julgamento humano e execução de IA
|
||||
- [ ] Suporte para processamento em lote e execução paralela
|
||||
|
||||
### 3. 🚫 Clarificação de Itens Proibidos (Pontuação: 15 pontos)
|
||||
|
||||
#### 3.1 Sistematização de Itens Absolutamente Proibidos (8 pontos)
|
||||
|
||||
- [ ] Lista completa de operações que não devem ser executadas
|
||||
- [ ] Indicação do grau de impacto de violação de cada item proibido (leve/grave/fatal)
|
||||
- [ ] Apresentação específica de meios alternativos e métodos de contorno
|
||||
- [ ] Explicação das bases técnicas dos itens proibidos
|
||||
|
||||
#### 3.2 Limitação Rigorosa de Condições de Exceção (7 pontos)
|
||||
|
||||
- [ ] Condições para reconhecer exceções específicas e limitadas (especificação numérica)
|
||||
- [ ] Critérios objetivos de julgamento como "completamente duplicado", "explicitamente descrito"
|
||||
- [ ] Linhas de demarcação claras que não deixam zonas cinzentas
|
||||
- [ ] Indicação de condições e restrições adicionais ao aplicar exceções
|
||||
|
||||
### 4. 📊 Mecanismo de Garantia de Qualidade (Pontuação: 20 pontos)
|
||||
|
||||
#### 4.1 Integridade do Sistema de Rastreamento (8 pontos)
|
||||
|
||||
- [ ] Função de registro automático e obtenção de estatísticas de todos os resultados de execução
|
||||
- [ ] Função de verificação que previne tecnicamente relatórios falsos
|
||||
- [ ] Função de monitoramento em tempo real e alertas
|
||||
- [ ] Função de prevenção de alteração de logs de auditoria
|
||||
|
||||
#### 4.2 Obrigatoriedade de Conformidade com Template (7 pontos)
|
||||
|
||||
- [ ] Definição clara de elementos obrigatórios e função de verificação
|
||||
- [ ] Limitações técnicas em locais proibidos de customização
|
||||
- [ ] Checkpoints automatizados de confirmação de conformidade
|
||||
- [ ] Função automática de correção e aviso em caso de violação
|
||||
|
||||
#### 4.3 Abrangência do Tratamento de Erros (5 pontos)
|
||||
|
||||
- [ ] Catalogação completa de padrões de erro esperados
|
||||
- [ ] Processo de tratamento por etapas em caso de erro
|
||||
- [ ] Prevenção técnica de relatar falha como sucesso
|
||||
|
||||
### 5. 🎭 Clarificação de Papéis e Responsabilidades (Pontuação: 10 pontos)
|
||||
|
||||
#### 5.1 Escopo de Autoridade do AI Agent (5 pontos)
|
||||
|
||||
- [ ] Linha de demarcação clara entre operações executáveis e proibidas
|
||||
- [ ] Escopo específico e restrições da autoridade de julgamento
|
||||
- [ ] Separação clara de operações que requerem confirmação humana
|
||||
|
||||
#### 5.2 Unificação do Sistema de Classificação (5 pontos)
|
||||
|
||||
- [ ] Clareza, unicidade e exclusividade das definições de classificação
|
||||
- [ ] Explicação explícita para prevenir mal-entendidos sobre importância entre classificações
|
||||
- [ ] Exemplos específicos de uso de cada classificação e fluxograma de julgamento
|
||||
|
||||
### 6. 🔄 Melhoria Contínua (Pontuação: 10 pontos)
|
||||
|
||||
#### 6.1 Automação da Coleta de Feedback (5 pontos)
|
||||
|
||||
- [ ] Extração automática de pontos de melhoria de logs de execução
|
||||
- [ ] Análise baseada em machine learning de padrões de falha
|
||||
- [ ] Mecanismo de atualização automática de melhores práticas
|
||||
|
||||
#### 6.2 Implementação de Função de Aprendizado (5 pontos)
|
||||
|
||||
- [ ] Detecção e classificação automática de novos padrões
|
||||
- [ ] Monitoramento contínuo da eficácia de regras existentes
|
||||
- [ ] Proposta automática de melhorias graduais
|
||||
|
||||
---
|
||||
|
||||
## 🚨 Padrões de Problemas Fatais (Correção Imediata Necessária)
|
||||
|
||||
### ❌ Nível 1: Ambiguidade Fatal (Nível de Parada de Execução)
|
||||
|
||||
- **Instruções com múltiplas interpretações possíveis**: "julgue adequadamente", "dependendo da situação", "em princípio"
|
||||
- **Condições ambíguas de exceção**: "em casos especiais", "conforme necessário"
|
||||
- **Critérios subjetivos de julgamento**: "adequadamente", "suficientemente", "na medida do possível"
|
||||
- **Conceitos importantes não definidos**: "padrão", "geral", "básico"
|
||||
|
||||
### ❌ Nível 2: Defeitos Estruturais (Nível de Qualidade Importante)
|
||||
|
||||
- **Dispersão de informações**: Informações importantes relacionadas dispersas em 3 ou mais locais
|
||||
- **Referência circular**: Loop infinito Seção A→B→C→A
|
||||
- **Instruções contraditórias**: Instruções opostas em seções diferentes
|
||||
- **Ordem de execução não clara**: Procedimentos com dependências não claras
|
||||
|
||||
### ❌ Nível 3: Degradação da Qualidade (Nível de Melhoria Recomendada)
|
||||
|
||||
- **Não verificabilidade**: Critérios de julgamento de sucesso/falha não claros
|
||||
- **Dificuldade de automação**: Design que depende de julgamento subjetivo humano
|
||||
- **Dificuldade de manutenção**: Estrutura onde o escopo de impacto de atualizações não pode ser previsto
|
||||
- **Dificuldade de aprendizado**: Complexidade que leva tempo para novos usuários entenderem
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Métodos de Melhoria Comprovados
|
||||
|
||||
### ✅ Abordagem de Reforço Gradual
|
||||
|
||||
1. **Análise da situação atual**: Classificação de problemas, priorização, avaliação do grau de impacto
|
||||
2. **Prioridade para problemas fatais**: Resolução completa de problemas Nível 1 como máxima prioridade
|
||||
3. **Implementação gradual**: Não fazer todas as mudanças de uma vez, implementar em unidades verificáveis
|
||||
4. **Medição de efeitos**: Comparação quantitativa antes e depois da melhoria
|
||||
5. **Monitoramento contínuo**: Confirmação da sustentabilidade dos efeitos de melhoria
|
||||
|
||||
### ✅ Métodos Práticos de Eliminação de Ambiguidade
|
||||
|
||||
```markdown
|
||||
# ❌ Antes da melhoria (ambíguo)
|
||||
|
||||
"Pontos apontados devem, em princípio, ser descritos como comentários inline nos locais de mudança correspondentes no GitHub"
|
||||
|
||||
# ✅ Depois da melhoria (claro)
|
||||
|
||||
"Pontos apontados devem ser obrigatoriamente descritos como comentários inline nos locais de mudança correspondentes no GitHub. Exceções são apenas as 3 condições definidas na Seção 3.3"
|
||||
```
|
||||
|
||||
### ✅ Métodos Práticos de Integração de Informações
|
||||
|
||||
```markdown
|
||||
# ❌ Antes da melhoria (disperso)
|
||||
|
||||
Seção 2.1: "Usar 6 seções obrigatórias"
|
||||
Seção 3.5: "📊 Avaliação geral, 📋 Itens apontados..."
|
||||
Seção 4.2: "Proibição de deletar seções"
|
||||
|
||||
# ✅ Depois da melhoria (integrado)
|
||||
|
||||
Checklist de execução:
|
||||
□ 10. Postar comentário de resumo (usar 6 seções obrigatórias)
|
||||
🔴 6 seções obrigatórias: 1) 📊 Avaliação geral 2) 📋 Agregação por classificação de itens apontados 3) ⚠️ Principais preocupações 4) ✅ Pontos avaliáveis 5) 🎯 Conclusão 6) 🤖 Auto-avaliação da qualidade do review de IA
|
||||
❌ Absolutamente proibido: deletar, adicionar, renomear seções
|
||||
```
|
||||
|
||||
### ✅ Padrões de Implementação de Sistema de Rastreamento
|
||||
|
||||
```bash
|
||||
# Rastreamento rigoroso de resultados de execução
|
||||
POSTED_COMMENTS=0
|
||||
FAILED_COMMENTS=0
|
||||
TOTAL_COMMENTS=0
|
||||
|
||||
# Registro de resultado de cada operação
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "✅ Sucesso: $OPERATION" >> /tmp/execution_log.txt
|
||||
POSTED_COMMENTS=$((POSTED_COMMENTS + 1))
|
||||
else
|
||||
echo "❌ Falha: $OPERATION" >> /tmp/execution_log.txt
|
||||
FAILED_COMMENTS=$((FAILED_COMMENTS + 1))
|
||||
fi
|
||||
|
||||
# Prevenção de relatórios falsos
|
||||
if [ $POSTED_COMMENTS -ne $REPORTED_COMMENTS ]; then
|
||||
echo "🚨 Aviso: Número reportado e número real de posts não coincidem"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📈 Cálculo de Score de Qualidade (Versão Melhorada)
|
||||
|
||||
### Cálculo do Score Total
|
||||
|
||||
```text
|
||||
Score base = Σ(Score de cada categoria × Pontuação) / 100
|
||||
|
||||
Penalidades por problemas fatais:
|
||||
- Problemas Nível 1: -20 pontos/caso
|
||||
- Problemas Nível 2: -10 pontos/caso
|
||||
- Problemas Nível 3: -5 pontos/caso
|
||||
|
||||
Elementos de bônus:
|
||||
- Suporte à automação: +5 pontos
|
||||
- Implementação de função de aprendizado: +5 pontos
|
||||
- Casos de melhoria comprovados: +5 pontos
|
||||
|
||||
Score final = Score base + Bônus - Penalidades
|
||||
```
|
||||
|
||||
### Julgamento do Nível de Qualidade
|
||||
|
||||
```text
|
||||
95-100 pontos: Padrão mundial mais alto (recomendável como padrão da indústria)
|
||||
90-94 pontos: Excelente (operável em produção)
|
||||
80-89 pontos: Bom (operável com melhorias menores)
|
||||
70-79 pontos: Normal (melhoria necessária)
|
||||
60-69 pontos: Requer melhoria (correção substancial necessária)
|
||||
50-59 pontos: Requer correção substancial (revisão fundamental necessária)
|
||||
49 pontos ou menos: Proibido o uso (redesign completo necessário)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Processo Prático de Melhoria
|
||||
|
||||
### Fase 1: Diagnóstico e Análise (1-2 dias)
|
||||
|
||||
1. **Compreensão da estrutura geral**: Visualização de configuração de seções, fluxo de informações, relações de dependência
|
||||
2. **Detecção de ambiguidade**: Extração de todas as expressões com margem de interpretação
|
||||
3. **Análise de dispersão de informações**: Mapeamento de padrões de dispersão de informações relacionadas
|
||||
4. **Avaliação de força obrigatória**: Avaliação de classificação e eficácia de recomendado/obrigatório
|
||||
5. **Confirmação de rastreabilidade**: Avaliação de funções de registro e verificação de resultados de execução
|
||||
|
||||
### Fase 2: Priorização e Planejamento (meio dia)
|
||||
|
||||
1. **Classificação de criticidade**: Classificação de problemas Nível 1-3 e avaliação do grau de impacto
|
||||
2. **Determinação da ordem de melhoria**: Ordem ótima considerando relações de interdependência
|
||||
3. **Alocação de recursos**: Otimização do equilíbrio entre efeito de melhoria e custo
|
||||
4. **Avaliação de riscos**: Previsão de efeitos colaterais e problemas de compatibilidade durante melhoria
|
||||
|
||||
### Fase 3: Implementação Gradual (2-5 dias)
|
||||
|
||||
1. **Resolução de problemas Nível 1**: Eliminação completa de ambiguidade fatal
|
||||
2. **Implementação de integração de informações**: Agregação estratégica de informações dispersas
|
||||
3. **Reforço de força obrigatória**: Promoção gradual de recomendado → obrigatório
|
||||
4. **Implementação de sistema de rastreamento**: Função automática de registro e verificação de resultados de execução
|
||||
5. **Reforço de template**: Clarificação de elementos obrigatórios e obrigatoriedade de conformidade
|
||||
|
||||
### Fase 4: Verificação e Ajuste (1-2 dias)
|
||||
|
||||
1. **Teste de função**: Confirmação de operação de todos os pontos de mudança
|
||||
2. **Teste de integração**: Confirmação de consistência do sistema como um todo
|
||||
3. **Teste de performance**: Confirmação de eficiência de execução e resposta
|
||||
4. **Teste de usabilidade**: Verificação em cenários reais de uso
|
||||
|
||||
### Fase 5: Operação e Monitoramento (contínuo)
|
||||
|
||||
1. **Medição de efeitos**: Comparação quantitativa antes e depois da melhoria
|
||||
2. **Monitoramento contínuo**: Detecção precoce de degradação da qualidade
|
||||
3. **Coleta de feedback**: Extração de problemas na operação real
|
||||
4. **Otimização contínua**: Ciclo de melhoria contínua
|
||||
|
||||
---
|
||||
|
||||
## 📊 Casos Reais de Melhoria (Versão Detalhada)
|
||||
|
||||
### Estudo de Caso: Melhoria da Qualidade de Prompt de Grande Escala
|
||||
|
||||
#### Situação Antes da Melhoria
|
||||
|
||||
```bash
|
||||
Score de qualidade: 70 pontos/100 pontos
|
||||
- Expressões ambíguas: 15 locais encontrados
|
||||
- Dispersão de informações: Informações importantes dispersas em 6 locais
|
||||
- Falta de força obrigatória: 80% expressões de nível recomendado
|
||||
- Função de rastreamento: Nenhum registro de resultados de execução
|
||||
- Tratamento de erros: Métodos de tratamento em caso de falha não claros
|
||||
```
|
||||
|
||||
#### Conteúdos de Melhoria Implementados
|
||||
|
||||
```bash
|
||||
# 1. Eliminação de ambiguidade (2 dias)
|
||||
- "em princípio" → "exceções são apenas as 3 condições da Seção 3.3"
|
||||
- "recomendado" → "obrigatório" (nível de importância 2 ou superior)
|
||||
- "adequadamente" → indicação de critérios específicos de julgamento
|
||||
|
||||
# 2. Integração de informações (1 dia)
|
||||
- Informações dispersas das 6 seções obrigatórias → integradas no checklist de execução
|
||||
- Itens proibidos relacionados → agregados em uma seção
|
||||
- Resolução de referências circulares → fluxo linear de informações
|
||||
|
||||
# 3. Implementação de sistema de rastreamento (1 dia)
|
||||
- Registro automático de logs de resultados de execução
|
||||
- Função de verificação para prevenção de relatórios falsos
|
||||
- Exibição de estatísticas em tempo real
|
||||
|
||||
# 4. Reforço do tratamento de erros (meio dia)
|
||||
- Catalogação completa de padrões de erro esperados
|
||||
- Documentação de processo de tratamento por etapas
|
||||
- Implementação de função de recuperação automática
|
||||
```
|
||||
|
||||
#### Resultados Após Melhoria
|
||||
|
||||
```bash
|
||||
Score de qualidade: 90 pontos/100 pontos (+20 pontos de melhoria)
|
||||
- Expressões ambíguas: 0 locais (eliminação completa)
|
||||
- Integração de informações: Informações importantes agregadas em 3 locais
|
||||
- Força obrigatória: 95% expressões de nível obrigatório
|
||||
- Função de rastreamento: Automação completa
|
||||
- Tratamento de erros: 90% dos problemas resolvidos automaticamente
|
||||
|
||||
Efeitos reais de melhoria:
|
||||
- Erros de julgamento: 85% de redução
|
||||
- Tempo de execução: 40% de redução
|
||||
- Taxa de ocorrência de erros: 70% de redução
|
||||
- Satisfação do usuário: 95% de melhoria
|
||||
```
|
||||
|
||||
### Lições Aprendidas e Melhores Práticas
|
||||
|
||||
#### Fatores de Sucesso
|
||||
|
||||
1. **Abordagem gradual**: Não fazer todas as mudanças de uma vez, implementar em unidades verificáveis
|
||||
2. **Baseado em dados**: Melhoria baseada em dados medidos, não julgamento subjetivo
|
||||
3. **Monitoramento contínuo**: Confirmação periódica da sustentabilidade dos efeitos de melhoria
|
||||
4. **Foco no feedback**: Coleta ativa de opiniões de usuários reais
|
||||
|
||||
#### Estratégias para Evitar Falhas
|
||||
|
||||
1. **Perfeccionismo excessivo**: Começar operação ao atingir 90 pontos, buscar 100 pontos com melhoria contínua
|
||||
2. **Perigo de mudanças em lote**: Implementar sempre mudanças de grande escala de forma gradual
|
||||
3. **Compatibilidade com versões anteriores**: Minimizar impacto em workflows existentes
|
||||
4. **Falta de documentação**: Registrar e compartilhar todas as mudanças detalhadamente
|
||||
|
||||
---
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Verificação de qualidade combinando com arquivo de prompt
|
||||
cat your-prompt.md
|
||||
/check-prompt
|
||||
"Avalie a qualidade deste prompt e proponha pontos de melhoria"
|
||||
|
||||
# Comparação de múltiplos arquivos de prompt
|
||||
cat prompt-v1.md && echo "---" && cat prompt-v2.md
|
||||
/check-prompt
|
||||
"Compare as duas versões e analise pontos melhorados e desafios restantes"
|
||||
|
||||
# Análise combinando com log de erros reais
|
||||
cat execution-errors.log
|
||||
/check-prompt --deep
|
||||
"Identifique problemas no prompt que podem ter causado este erro"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Pré-requisitos**: Recomenda-se que os arquivos de prompt sejam descritos em formato Markdown
|
||||
- **Limitações**: Para prompts de grande escala (mais de 10 mil linhas), recomenda-se dividir para análise
|
||||
- **Recomendação**: Implemente verificações regulares de qualidade de prompt e melhore continuamente
|
||||
|
||||
---
|
||||
|
||||
_Esta checklist é uma versão completa de conhecimentos comprovados em projetos reais de melhoria de prompts e continua evoluindo continuamente._
|
||||
354
commands/commit-message.md
Normal file
354
commands/commit-message.md
Normal file
@@ -0,0 +1,354 @@
|
||||
## Commit Message
|
||||
|
||||
Gera mensagens de commit apropriadas a partir de mudanças staged (git diff --staged). Não executa comandos git, apenas gera mensagens e copia para a área de transferência.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/commit-message [opções]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--format <formato>` : Especifica formato da mensagem (conventional, gitmoji, angular)
|
||||
- `--lang <idioma>` : Força especificação do idioma da mensagem (en, pt)
|
||||
- `--breaking` : Detecção e descrição de Breaking Change
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Gerar mensagem a partir de mudanças staged (detecção automática de idioma)
|
||||
# O candidato principal é automaticamente copiado para a área de transferência
|
||||
/commit-message
|
||||
|
||||
# Forçar especificação de idioma
|
||||
/commit-message --lang pt
|
||||
/commit-message --lang en
|
||||
|
||||
# Detectar Breaking Change
|
||||
/commit-message --breaking
|
||||
```
|
||||
|
||||
### Pré-requisitos
|
||||
|
||||
**Importante**: Este comando analisa apenas mudanças staged. É necessário fazer staging das mudanças com `git add` previamente.
|
||||
|
||||
```bash
|
||||
# Se não houver staging, será exibido um aviso
|
||||
$ /commit-message
|
||||
Não há mudanças staged. Execute git add primeiro.
|
||||
```
|
||||
|
||||
### Função Automática de Área de Transferência
|
||||
|
||||
O candidato principal gerado é automaticamente copiado para a área de transferência no formato completo `git commit -m "mensagem"`. Pode ser colado diretamente no terminal para execução.
|
||||
|
||||
**Atenção na implementação**:
|
||||
|
||||
- Ao passar comando de commit para `pbcopy`, execute em processo separado da saída da mensagem
|
||||
- Use `printf` em vez de `echo` para evitar quebra de linha no final
|
||||
|
||||
### Detecção Automática de Convenções do Projeto
|
||||
|
||||
**Importante**: Se existirem convenções específicas do projeto, elas têm prioridade.
|
||||
|
||||
#### 1. Verificação de Configuração CommitLint
|
||||
|
||||
Detecção automática a partir dos seguintes arquivos:
|
||||
|
||||
- `commitlint.config.js`
|
||||
- `commitlint.config.mjs`
|
||||
- `commitlint.config.cjs`
|
||||
- `commitlint.config.ts`
|
||||
- `.commitlintrc.js`
|
||||
- `.commitlintrc.json`
|
||||
- `.commitlintrc.yml`
|
||||
- `.commitlintrc.yaml`
|
||||
- Seção `commitlint` do `package.json`
|
||||
|
||||
```bash
|
||||
# Busca por arquivos de configuração
|
||||
find . -name "commitlint.config.*" -o -name ".commitlintrc.*" | head -1
|
||||
```
|
||||
|
||||
#### 2. Detecção de Tipos Customizados
|
||||
|
||||
Exemplo de tipos específicos do projeto:
|
||||
|
||||
```javascript
|
||||
// commitlint.config.mjs
|
||||
export default {
|
||||
extends: ["@commitlint/config-conventional"],
|
||||
rules: {
|
||||
"type-enum": [
|
||||
2,
|
||||
"always",
|
||||
[
|
||||
"feat",
|
||||
"fix",
|
||||
"docs",
|
||||
"style",
|
||||
"refactor",
|
||||
"test",
|
||||
"chore",
|
||||
"wip", // em andamento
|
||||
"hotfix", // correção urgente
|
||||
"release", // release
|
||||
"deps", // atualização de dependências
|
||||
"config", // mudança de configuração
|
||||
],
|
||||
],
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
#### 3. Detecção de Configuração de Idioma
|
||||
|
||||
```javascript
|
||||
// Quando o projeto usa mensagens em japonês
|
||||
export default {
|
||||
rules: {
|
||||
"subject-case": [0], // Desabilitado para suporte ao japonês
|
||||
"subject-max-length": [2, "always", 72], // Ajuste de limite de caracteres para japonês
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
#### 4. Análise de Histórico de Commits Existentes
|
||||
|
||||
```bash
|
||||
# Aprendizado de padrões de uso a partir de commits recentes
|
||||
git log --oneline -50 --pretty=format:"%s"
|
||||
|
||||
# Estatísticas de tipos utilizados
|
||||
git log --oneline -100 --pretty=format:"%s" | \
|
||||
grep -oE '^[a-z]+(\([^)]+\))?' | \
|
||||
sort | uniq -c | sort -nr
|
||||
```
|
||||
|
||||
### Detecção Automática de Idioma
|
||||
|
||||
Alternância automática entre japonês/inglês baseada nas seguintes condições:
|
||||
|
||||
1. Verificação de configuração de idioma nas **configurações CommitLint**
|
||||
2. Julgamento automático através de **análise do git log**
|
||||
3. Configurações de idioma de **arquivos do projeto**
|
||||
4. Análise de comentários e strings **dentro de arquivos modificados**
|
||||
|
||||
O padrão é inglês. Quando identificado como projeto japonês, gera em japonês.
|
||||
|
||||
### Formato da Mensagem
|
||||
|
||||
#### Conventional Commits (padrão)
|
||||
|
||||
```text
|
||||
<type>: <description>
|
||||
```
|
||||
|
||||
**Importante**: Sempre gera mensagem de commit de 1 linha. Não gera mensagens de múltiplas linhas.
|
||||
|
||||
**Nota**: Se existirem convenções específicas do projeto, elas têm prioridade.
|
||||
|
||||
### Tipos Padrão
|
||||
|
||||
**Tipos obrigatórios**:
|
||||
|
||||
- `feat`: Nova funcionalidade (adição de funcionalidade visível ao usuário)
|
||||
- `fix`: Correção de bug
|
||||
|
||||
**Tipos opcionais**:
|
||||
|
||||
- `build`: Mudanças no sistema de build ou dependências externas
|
||||
- `chore`: Outras mudanças (que não afetam o release)
|
||||
- `ci`: Mudanças em arquivos de configuração ou scripts de CI
|
||||
- `docs`: Mudanças apenas na documentação
|
||||
- `style`: Mudanças que não afetam o significado do código (espaços, formatação, ponto e vírgula, etc.)
|
||||
- `refactor`: Mudanças no código que não envolvem correção de bug ou adição de funcionalidade
|
||||
- `perf`: Melhoria de performance
|
||||
- `test`: Adição ou correção de testes
|
||||
|
||||
### Exemplo de Saída (Projeto em Inglês)
|
||||
|
||||
```bash
|
||||
$ /commit-message
|
||||
|
||||
📝 Sugestão de mensagem de commit
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
✨ Candidato principal:
|
||||
feat: implement JWT-based authentication system
|
||||
|
||||
📋 Alternativas:
|
||||
1. feat: add user authentication with JWT tokens
|
||||
2. fix: resolve token validation error in auth middleware
|
||||
3. refactor: extract auth logic into separate module
|
||||
|
||||
✅ `git commit -m "feat: implement JWT-based authentication system"` copiado para a área de transferência
|
||||
```
|
||||
|
||||
**Exemplo de implementação (versão corrigida)**:
|
||||
|
||||
```bash
|
||||
# Copiar comando de commit para área de transferência primeiro (sem quebra de linha)
|
||||
printf 'git commit -m "%s"' "$COMMIT_MESSAGE" | pbcopy
|
||||
|
||||
# Depois exibir mensagem
|
||||
cat << EOF
|
||||
📝 Sugestão de mensagem de commit
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
✨ Candidato principal:
|
||||
$COMMIT_MESSAGE
|
||||
|
||||
📋 Alternativas:
|
||||
1. ...
|
||||
2. ...
|
||||
3. ...
|
||||
|
||||
✅ \`git commit -m "$COMMIT_MESSAGE"\` copiado para a área de transferência
|
||||
EOF
|
||||
```
|
||||
|
||||
### Exemplo de Saída (Projeto em Japonês)
|
||||
|
||||
```bash
|
||||
$ /commit-message
|
||||
|
||||
📝 Sugestão de mensagem de commit
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
✨ Candidato principal:
|
||||
feat: implementar sistema de autenticação JWT
|
||||
|
||||
📋 Alternativas:
|
||||
1. feat: adicionar autenticação de usuário com token JWT
|
||||
2. fix: resolver erro de validação de token no middleware de autenticação
|
||||
3. docs: separar lógica de autenticação em módulo independente
|
||||
|
||||
✅ `git commit -m "feat: implementar sistema de autenticação JWT"` copiado para a área de transferência
|
||||
```
|
||||
|
||||
### Visão Geral da Operação
|
||||
|
||||
1. **Análise**: Analisar conteúdo de `git diff --staged`
|
||||
2. **Geração**: Gerar mensagem de commit apropriada
|
||||
3. **Cópia**: Copiar candidato principal automaticamente para a área de transferência
|
||||
|
||||
**Nota**: Este comando não executa git add ou git commit. Apenas gera mensagem de commit e copia para a área de transferência.
|
||||
|
||||
### Funcionalidades Inteligentes
|
||||
|
||||
#### 1. Classificação Automática do Conteúdo das Mudanças (apenas arquivos staged)
|
||||
|
||||
- Adição de novo arquivo → `feat`
|
||||
- Padrão de correção de erro → `fix`
|
||||
- Apenas arquivos de teste → `test`
|
||||
- Mudança de arquivo de configuração → `chore`
|
||||
- Atualização de README/docs → `docs`
|
||||
|
||||
#### 2. Detecção Automática de Convenções do Projeto
|
||||
|
||||
- Arquivo `.gitmessage`
|
||||
- Convenções dentro de `CONTRIBUTING.md`
|
||||
- Padrões de histórico de commits anteriores
|
||||
|
||||
#### 3. Detalhes da Detecção de Idioma (apenas mudanças staged)
|
||||
|
||||
```bash
|
||||
# Critérios de julgamento (ordem de prioridade)
|
||||
1. Julgar idioma a partir do conteúdo de git diff --staged
|
||||
2. Análise de comentários de arquivos staged
|
||||
3. Análise de idioma de git log --oneline -20
|
||||
4. Configuração de idioma principal do projeto
|
||||
```
|
||||
|
||||
#### 4. Detalhes da Análise de Staging
|
||||
|
||||
Informações usadas para análise (apenas leitura):
|
||||
|
||||
- `git diff --staged --name-only` - Lista de arquivos modificados
|
||||
- `git diff --staged` - Conteúdo real das mudanças
|
||||
- `git status --porcelain` - Status dos arquivos
|
||||
|
||||
### Quando Breaking Change é Detectado
|
||||
|
||||
Se houver mudanças disruptivas na API:
|
||||
|
||||
**Inglês**:
|
||||
|
||||
```bash
|
||||
feat!: change user API response format
|
||||
|
||||
BREAKING CHANGE: user response now includes additional metadata
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```bash
|
||||
feat(api)!: change authentication flow
|
||||
```
|
||||
|
||||
**Exemplo de Breaking Change**:
|
||||
|
||||
```bash
|
||||
feat!: alterar formato de resposta da API de usuários
|
||||
|
||||
BREAKING CHANGE: A resposta agora inclui metadados adicionais
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```bash
|
||||
feat(api)!: modificar fluxo de autenticação
|
||||
```
|
||||
|
||||
### Melhores Práticas
|
||||
|
||||
1. **Adaptar ao projeto**: Seguir o idioma dos commits existentes
|
||||
2. **Concisão**: Clara em até 50 caracteres
|
||||
3. **Consistência**: Não misturar (se inglês, unificar em inglês)
|
||||
4. **OSS**: Para open source, recomenda-se inglês
|
||||
5. **Rigor de 1 linha**: Sempre fazer mensagem de commit de 1 linha (se necessária explicação detalhada, complementar no PR)
|
||||
|
||||
### Padrões Comuns
|
||||
|
||||
**Inglês**:
|
||||
|
||||
```text
|
||||
feat: add user registration endpoint
|
||||
fix: resolve memory leak in cache manager
|
||||
docs: update API documentation
|
||||
```
|
||||
|
||||
**Exemplo com múltiplas mudanças**:
|
||||
|
||||
```text
|
||||
feat: adicionar endpoint de registro de usuários
|
||||
fix: resolver vazamento de memória no gerenciador de cache
|
||||
docs: atualizar documentação da API
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Usar em combinação com mudanças staged
|
||||
git add -p # Staging interativo
|
||||
/commit-message
|
||||
"Gere a mensagem de commit mais adequada"
|
||||
|
||||
# Analisar fazendo staging apenas de arquivos específicos
|
||||
git add src/auth/*.js
|
||||
/commit-message --lang en
|
||||
"Gere mensagem adequada para mudanças relacionadas à autenticação"
|
||||
|
||||
# Detecção e tratamento de Breaking Change
|
||||
git add -A
|
||||
/commit-message --breaking
|
||||
"Se houver mudança disruptiva, marque adequadamente"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Pré-requisitos**: As mudanças devem ser previamente staged com `git add`
|
||||
- **Limitações**: Mudanças não staged estão fora do escopo de análise
|
||||
- **Recomendação**: Verifique previamente as convenções de commit existentes do projeto
|
||||
50
commands/context7.md
Normal file
50
commands/context7.md
Normal file
@@ -0,0 +1,50 @@
|
||||
## Context7
|
||||
|
||||
Pesquisa documentação técnica no Context7 via MCP.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Formato de solicitação ao Claude
|
||||
"pesquise [palavra-chave] no context7"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Investigação de React hooks
|
||||
"pesquise React hooks no context7"
|
||||
|
||||
# Busca por métodos de resolução de erros
|
||||
"pesquise sobre erros de tipo TypeScript no context7"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Solicitação de investigação técnica
|
||||
"pesquise o sistema de ownership do Rust no context7 e explique para iniciantes"
|
||||
|
||||
# Solicitação de resolução de erros
|
||||
"pesquise no context7 as causas comuns e soluções para ImportError do Python"
|
||||
|
||||
# Verificação de melhores práticas
|
||||
"encontre no context7 as melhores práticas de otimização de performance do React"
|
||||
```
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Investigação de múltiplas perspectivas
|
||||
"pesquise GraphQL no context7 nas seguintes perspectivas:
|
||||
1. Conceitos básicos e diferenças com REST API
|
||||
2. Métodos de implementação e melhores práticas
|
||||
3. Problemas comuns e soluções"
|
||||
|
||||
# Investigação de versões ou ambientes específicos
|
||||
"pesquise as novas funcionalidades do Next.js 14 no context7 e explique focando no uso do App Router"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
Quando informações não são encontradas no Context7, Claude automaticamente sugere outros métodos como busca web.
|
||||
186
commands/design-patterns.md
Normal file
186
commands/design-patterns.md
Normal file
@@ -0,0 +1,186 @@
|
||||
## Design Patterns
|
||||
|
||||
Propõe padrões de design aplicáveis à base de código e avalia a conformidade com os princípios SOLID.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/design-patterns [alvo-de-análise] [opções]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--suggest` : Propor padrões aplicáveis (padrão)
|
||||
- `--analyze` : Analisar uso de padrões existentes
|
||||
- `--refactor` : Gerar propostas de refatoração
|
||||
- `--solid` : Verificar conformidade com princípios SOLID
|
||||
- `--anti-patterns` : Detectar antipadrões
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Análise de padrões de todo o projeto
|
||||
/design-patterns
|
||||
|
||||
# Proposta de padrões para arquivo específico
|
||||
/design-patterns src/services/user.js --suggest
|
||||
|
||||
# Verificação de princípios SOLID
|
||||
/design-patterns --solid
|
||||
|
||||
# Detecção de antipadrões
|
||||
/design-patterns --anti-patterns
|
||||
```
|
||||
|
||||
### Categorias de Análise
|
||||
|
||||
#### 1. Padrões de Criação
|
||||
|
||||
- **Factory Pattern**: Abstração da criação de objetos
|
||||
- **Builder Pattern**: Construção gradual de objetos complexos
|
||||
- **Singleton Pattern**: Garantia de unicidade de instância
|
||||
- **Prototype Pattern**: Geração de clones de objetos
|
||||
|
||||
#### 2. Padrões Estruturais
|
||||
|
||||
- **Adapter Pattern**: Conversão de interfaces
|
||||
- **Decorator Pattern**: Adição dinâmica de funcionalidades
|
||||
- **Facade Pattern**: Simplificação de subsistemas complexos
|
||||
- **Proxy Pattern**: Controle de acesso a objetos
|
||||
|
||||
#### 3. Padrões Comportamentais
|
||||
|
||||
- **Observer Pattern**: Implementação de notificação de eventos
|
||||
- **Strategy Pattern**: Alternância de algoritmos
|
||||
- **Command Pattern**: Encapsulamento de operações
|
||||
- **Iterator Pattern**: Percorrer coleções
|
||||
|
||||
### Itens de Verificação dos Princípios SOLID
|
||||
|
||||
```text
|
||||
S - Single Responsibility Principle (Princípio da Responsabilidade Única)
|
||||
O - Open/Closed Principle (Princípio Aberto/Fechado)
|
||||
L - Liskov Substitution Principle (Princípio da Substituição de Liskov)
|
||||
I - Interface Segregation Principle (Princípio da Segregação de Interface)
|
||||
D - Dependency Inversion Principle (Princípio da Inversão de Dependência)
|
||||
```
|
||||
|
||||
### Exemplo de Saída
|
||||
|
||||
```text
|
||||
Relatório de Análise de Design Patterns
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Padrões Atualmente em Uso
|
||||
├─ Observer Pattern: EventEmitter (12 locais)
|
||||
├─ Factory Pattern: UserFactory (3 locais)
|
||||
├─ Singleton Pattern: DatabaseConnection (1 local)
|
||||
└─ Strategy Pattern: PaymentProcessor (5 locais)
|
||||
|
||||
Padrões Recomendados
|
||||
├─ [HIGH] Repository Pattern
|
||||
│ └─ Alvo: src/models/*.js
|
||||
│ └─ Motivo: Separação da lógica de acesso a dados
|
||||
│ └─ Exemplo:
|
||||
│ class UserRepository {
|
||||
│ async findById(id) { ... }
|
||||
│ async save(user) { ... }
|
||||
│ }
|
||||
│
|
||||
├─ [MED] Command Pattern
|
||||
│ └─ Alvo: src/api/handlers/*.js
|
||||
│ └─ Motivo: Unificação do processamento de requisições
|
||||
│
|
||||
└─ [LOW] Decorator Pattern
|
||||
└─ Alvo: src/middleware/*.js
|
||||
└─ Motivo: Melhoria da combinação de funcionalidades
|
||||
|
||||
Violações dos Princípios SOLID
|
||||
├─ [S] UserService: responsável tanto por autenticação quanto gerenciamento de permissões
|
||||
├─ [O] PaymentGateway: necessária modificação ao adicionar novos métodos de pagamento
|
||||
├─ [D] EmailService: depende diretamente de classes concretas
|
||||
└─ [I] IDataStore: contém métodos não utilizados
|
||||
|
||||
Propostas de Refatoração
|
||||
1. Dividir UserService em autenticação e gerenciamento de permissões
|
||||
2. Introduzir interface PaymentStrategy
|
||||
3. Definir interface EmailService
|
||||
4. Separar IDataStore por uso
|
||||
```
|
||||
|
||||
### Exemplos de Uso Avançado
|
||||
|
||||
```bash
|
||||
# Análise de impacto da aplicação de padrões
|
||||
/design-patterns --impact-analysis Repository
|
||||
|
||||
# Geração de exemplo de implementação de padrão específico
|
||||
/design-patterns --generate Factory --for src/models/Product.js
|
||||
|
||||
# Proposta de combinação de padrões
|
||||
/design-patterns --combine --context "API with caching"
|
||||
|
||||
# Avaliação de padrões arquiteturais
|
||||
/design-patterns --architecture MVC
|
||||
```
|
||||
|
||||
### Exemplo de Aplicação de Padrão
|
||||
|
||||
#### Antes (código problemático)
|
||||
|
||||
```javascript
|
||||
class OrderService {
|
||||
processOrder(order, paymentType) {
|
||||
if (paymentType === "credit") {
|
||||
// Processamento de cartão de crédito
|
||||
} else if (paymentType === "paypal") {
|
||||
// Processamento PayPal
|
||||
}
|
||||
// Outros métodos de pagamento...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Depois (aplicação do Strategy Pattern)
|
||||
|
||||
```javascript
|
||||
// Interface de estratégia
|
||||
class PaymentStrategy {
|
||||
process(amount) {
|
||||
throw new Error("Must implement process method");
|
||||
}
|
||||
}
|
||||
|
||||
// Estratégia concreta
|
||||
class CreditCardPayment extends PaymentStrategy {
|
||||
process(amount) {
|
||||
/* implementação */
|
||||
}
|
||||
}
|
||||
|
||||
// Contexto
|
||||
class OrderService {
|
||||
constructor(paymentStrategy) {
|
||||
this.paymentStrategy = paymentStrategy;
|
||||
}
|
||||
|
||||
processOrder(order) {
|
||||
this.paymentStrategy.process(order.total);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Detecção de Antipadrões
|
||||
|
||||
- **God Object**: Classe com responsabilidades excessivas
|
||||
- **Spaghetti Code**: Código com fluxo de controle complexamente entrelaçado
|
||||
- **Copy-Paste Programming**: Uso excessivo de código duplicado
|
||||
- **Magic Numbers**: Constantes hardcoded
|
||||
- **Callback Hell**: Callbacks profundamente aninhados
|
||||
|
||||
### Melhores Práticas
|
||||
|
||||
1. **Aplicação gradual**: Não aplicar muitos padrões de uma vez
|
||||
2. **Verificação de necessidade**: Padrões são meios para resolver problemas, não fins
|
||||
3. **Consenso da equipe**: Discutir em equipe antes de aplicar padrões
|
||||
4. **Documentação**: Registrar a intenção dos padrões aplicados
|
||||
75
commands/explain-code.md
Normal file
75
commands/explain-code.md
Normal file
@@ -0,0 +1,75 @@
|
||||
## Code Explain
|
||||
|
||||
Explica detalhadamente o funcionamento do código.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Exibir conteúdo do arquivo e solicitar ao Claude
|
||||
cat <file>
|
||||
"Explique o funcionamento deste código"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Compreender ownership do Rust
|
||||
cat main.rs
|
||||
"Explique do ponto de vista de ownership e lifetime do Rust"
|
||||
|
||||
# Explicação de algoritmo
|
||||
grep -A 50 "quicksort" sort.rs
|
||||
"Explique o mecanismo e a complexidade deste algoritmo de ordenação"
|
||||
|
||||
# Explicação de padrões de design
|
||||
cat factory.rs
|
||||
"Explique os padrões de design utilizados e suas vantagens"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Explicação para iniciantes
|
||||
cat complex_function.py
|
||||
"Explique este código linha por linha de forma fácil para iniciantes"
|
||||
|
||||
# Análise de performance
|
||||
cat algorithm.rs
|
||||
"Apresente os problemas de performance deste código e sugestões de melhoria"
|
||||
|
||||
# Explicação com diagrama
|
||||
cat state_machine.js
|
||||
"Explique o fluxo de processamento deste código com diagrama em ASCII art"
|
||||
|
||||
# Revisão de segurança
|
||||
cat auth_handler.go
|
||||
"Aponte as preocupações de segurança deste código"
|
||||
```
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Explicação de lógica complexa
|
||||
cat recursive_parser.rs
|
||||
"Explique o funcionamento deste parser recursivo sob os seguintes aspectos:
|
||||
1. Fluxo geral de processamento
|
||||
2. Papel e responsabilidade de cada função
|
||||
3. Tratamento de casos extremos
|
||||
4. Pontos que podem ser melhorados"
|
||||
|
||||
# Explicação de processamento assíncrono
|
||||
cat async_handler.ts
|
||||
"Explique sobre este processamento assíncrono:
|
||||
1. Fluxo da cadeia de Promises
|
||||
2. Mecanismo de tratamento de erros
|
||||
3. Presença de processamento paralelo
|
||||
4. Possibilidade de deadlock"
|
||||
|
||||
# Explicação de arquitetura
|
||||
ls -la src/ && cat src/main.rs src/lib.rs
|
||||
"Explique a arquitetura e estrutura de módulos deste projeto"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
Na explicação de código, além de simplesmente explicar o funcionamento, também fornece insights profundos sobre por que foi implementado dessa forma, quais são as vantagens e quais são os problemas potenciais.
|
||||
311
commands/fix-error.md
Normal file
311
commands/fix-error.md
Normal file
@@ -0,0 +1,311 @@
|
||||
## Error Fix
|
||||
|
||||
Identifica a causa raiz a partir de mensagens de erro, prediz o tempo de resolução e propõe soluções comprovadas. Aprende padrões de erros similares e apresenta imediatamente o método de resolução apropriado.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/fix-error [opções]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- nenhuma : Análise padrão de erro
|
||||
- `--deep` : Modo de análise profunda (inclui dependências e fatores ambientais)
|
||||
- `--preventive` : Análise focada em medidas preventivas
|
||||
- `--quick` : Apresenta apenas correções aplicáveis imediatamente
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Análise padrão de erro
|
||||
npm run build 2>&1
|
||||
/fix-error
|
||||
"Analise o erro de build e apresente métodos de correção"
|
||||
|
||||
# Modo de análise profunda
|
||||
python app.py 2>&1
|
||||
/fix-error --deep
|
||||
"Analise a causa raiz do erro incluindo fatores ambientais"
|
||||
|
||||
# Foco em correção imediata
|
||||
cargo test 2>&1
|
||||
/fix-error --quick
|
||||
"Apresente métodos de correção que podem ser aplicados imediatamente"
|
||||
|
||||
# Foco em prevenção
|
||||
./app 2>&1 | tail -50
|
||||
/fix-error --preventive
|
||||
"Apresente correção do erro e medidas preventivas futuras"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise de log de erro
|
||||
cat error.log
|
||||
/fix-error
|
||||
"Identifique a causa raiz do erro e proponha métodos de correção"
|
||||
|
||||
# Resolução de falha em testes
|
||||
npm test 2>&1
|
||||
/fix-error --quick
|
||||
"Analise o teste falhado e apresente proposta de correção aplicável imediatamente"
|
||||
|
||||
# Análise de stack trace
|
||||
python script.py 2>&1
|
||||
/fix-error --deep
|
||||
"Identifique a parte problemática deste stack trace e analise incluindo fatores ambientais"
|
||||
|
||||
# Resolução conjunta de múltiplos erros
|
||||
grep -E "ERROR|WARN" app.log | tail -20
|
||||
/fix-error
|
||||
"Classifique esses erros e avisos por ordem de prioridade e proponha métodos de resolução para cada um"
|
||||
```
|
||||
|
||||
### Previsão de Tempo de Resolução de Erro
|
||||
|
||||
```text
|
||||
🚀 Correção Imediata(menos de 5 min)
|
||||
├─ Erro de digitação, import esquecido
|
||||
├─ Variável de ambiente não definida
|
||||
├─ Referência a variável indefinida
|
||||
└─ Tempo previsto: 2-5 min
|
||||
|
||||
⚡ Correção Rápida(menos de 30 min)
|
||||
├─ Inconsistência de dependência
|
||||
├─ Erro de arquivo de configuração
|
||||
├─ Incompatibilidade de tipo
|
||||
└─ Tempo previsto: 10-30 min
|
||||
|
||||
🔧 Investigação Necessária(menos de 2 horas)
|
||||
├─ Erro de lógica complexa
|
||||
├─ Conflito de processamento assíncrono
|
||||
├─ Problema de integração de API
|
||||
└─ Tempo previsto: 30 min-2 horas
|
||||
|
||||
🔬 Análise Profunda(mais de meio dia)
|
||||
├─ Originado da arquitetura
|
||||
├─ Integração multi-sistema
|
||||
├─ Degradação de performance
|
||||
└─ Tempo previsto: 4 horas-vários dias
|
||||
```
|
||||
|
||||
### Banco de Dados de Padrões de Erro Similares
|
||||
|
||||
```text
|
||||
Erros Frequentes e Soluções Imediatas
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
📊 "Cannot read property 'X' of undefined/null" (Frequência: Muito Alta)
|
||||
├─ Causa principal: Falta de verificação de null do objeto
|
||||
├─ Tempo de resolução: 5-10 min
|
||||
└─ Solução: Adicionar Optional chaining (?.) ou verificação de null
|
||||
|
||||
📊 "ECONNREFUSED" / "ENOTFOUND" (Frequência: Alta)
|
||||
├─ Causa principal: Serviço não iniciado ou erro de configuração de URL
|
||||
├─ Tempo de resolução: 5-15 min
|
||||
└─ Solução: Verificar inicialização do serviço, checar variáveis de ambiente
|
||||
|
||||
📊 "Module not found" / "Cannot resolve" (Frequência: Alta)
|
||||
├─ Causa principal: Pacote não instalado, erro de especificação de caminho
|
||||
├─ Tempo de resolução: 2-5 min
|
||||
└─ Solução: Executar npm install, verificar caminho relativo
|
||||
|
||||
📊 "Unexpected token" / "SyntaxError" (Frequência: Média)
|
||||
├─ Causa principal: Parênteses ・aspas inconsistentes, uso de palavra reservada
|
||||
├─ Tempo de resolução: 2-10 min
|
||||
└─ Solução: Verificar syntax highlight, executar Linter
|
||||
|
||||
📊 "CORS policy" / "Access-Control-Allow-Origin" (Frequência: Média)
|
||||
├─ Causa principal: Falta de configuração CORS no servidor
|
||||
├─ Tempo de resolução: 15-30 min
|
||||
└─ Solução: Configuração CORS do servidor, configuração de proxy
|
||||
|
||||
📊 "Maximum call stack size exceeded" (Frequência: Baixa)
|
||||
├─ Causa principal: Loop infinito ・recursão, referência circular
|
||||
├─ Tempo de resolução: 30 min-2 horas
|
||||
└─ Solução: Verificar condição de parada da recursão, resolver referência circular
|
||||
```
|
||||
|
||||
### Matriz de Prioridade da Análise de Erro
|
||||
|
||||
| Prioridade | Ícone | Alcance do Impacto | Dificuldade de Resolução | Prazo de Resposta | Descrição |
|
||||
| ----------------- | ---------------------- | ------------------ | ------------------------ | --------------------- | ------------------------------------------------------------------- |
|
||||
| **Critical** | 🔴 Resposta Urgente | Amplo | Baixa | Iniciar em 15 min | Parada total do sistema, risco de perda de dados |
|
||||
| **High Priority** | 🟠 Resposta Antecipada | Amplo | Alta | Iniciar em 1 hora | Parada de funcionalidade principal, impacto em muitos usuários |
|
||||
| **Medium** | 🟡 Resposta Planejada | Restrito | Alta | Resposta no mesmo dia | Restrição de funcionalidade parcial, solução alternativa disponível |
|
||||
| **Low** | 🟢 Observação | Restrito | Baixa | Na próxima correção | Falha menor, pequeno impacto na UX |
|
||||
|
||||
### Processo de Análise
|
||||
|
||||
#### Fase 1: Coleta de Informações do Erro
|
||||
|
||||
```bash
|
||||
🔴 Execução obrigatória:
|
||||
- Obtenção completa da mensagem de erro
|
||||
- Verificação do stack trace
|
||||
- Identificação das condições de ocorrência (reprodutibilidade)
|
||||
|
||||
🟡 Execução antecipada:
|
||||
- Coleta de informações ambientais (OS, versão, dependências)
|
||||
- Histórico de mudanças recentes (git log, commits recentes)
|
||||
- Verificação de logs relacionados
|
||||
|
||||
🟢 Execução adicional:
|
||||
- Status de recursos do sistema
|
||||
- Estado da rede
|
||||
- Estado de serviços externos
|
||||
```
|
||||
|
||||
#### Fase 2: Análise de Causa Raiz
|
||||
|
||||
1. **Organização de Sintomas Superficiais**
|
||||
- Conteúdo exato da mensagem de erro
|
||||
- Timing de ocorrência e padrão
|
||||
- Identificação do alcance do impacto
|
||||
|
||||
2. **Identificação de Causa Profunda**
|
||||
- Aplicação da análise 5 Whys
|
||||
- Rastreamento de relações de dependência
|
||||
- Verificação de diferenças ambientais
|
||||
|
||||
3. **Verificação de Hipóteses**
|
||||
- Criação de código de reprodução mínima
|
||||
- Execução de testes isolados
|
||||
- Refinamento da causa
|
||||
|
||||
#### Fase 3: Implementação da Solução
|
||||
|
||||
```bash
|
||||
🔴 Resposta Imediata(hotfix):
|
||||
- Correção mínima para suprimir sintomas
|
||||
- Aplicação de solução temporária
|
||||
- Preparação para deploy de emergência
|
||||
|
||||
🟡 Solução Fundamental:
|
||||
- Correção essencial para a causa
|
||||
- Adição de casos de teste
|
||||
- Atualização de documentação
|
||||
|
||||
🟢 Implementação de Prevenção:
|
||||
- Fortalecimento do tratamento de erro
|
||||
- Configuração de monitoramento ・alerta
|
||||
- Melhoria do pipeline de CI/CD
|
||||
```
|
||||
|
||||
### Exemplo de Saída
|
||||
|
||||
```text
|
||||
🚨 Relatório de Análise de Erro
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
📍 Resumo do Erro
|
||||
├─ Tipo: [Compilação/Runtime/Lógico/Ambiente]
|
||||
├─ Urgência: 🔴 Alta / 🟡 Média / 🟢 Baixa
|
||||
├─ Alcance do Impacto: [Nome da Funcionalidade/Componente]
|
||||
└─ Reprodutibilidade: [100% / Intermitente / Condição Específica]
|
||||
|
||||
🔍 Causa Raiz
|
||||
├─ Causa Direta: [Causa específica]
|
||||
├─ Fatores de Fundo: [Ambiente/Configuração/Dependência]
|
||||
└─ Gatilho: [Condição de ocorrência]
|
||||
|
||||
💡 Solução
|
||||
🔴 Resposta Imediata:
|
||||
1. [Comando/código de correção específica]
|
||||
2. [Solução temporária]
|
||||
|
||||
🟡 Solução Fundamental:
|
||||
1. [Método de correção essencial]
|
||||
2. [Refatoração necessária]
|
||||
|
||||
🟢 Prevenção:
|
||||
1. [Melhoria do tratamento de erro]
|
||||
2. [Adição de teste]
|
||||
3. [Configuração de monitoramento]
|
||||
|
||||
📝 Procedimento de Verificação
|
||||
1. [Método de verificação após aplicação da correção]
|
||||
2. [Comando de execução de teste]
|
||||
3. [Itens de verificação de operação]
|
||||
```
|
||||
|
||||
### Técnicas de Análise por Tipo de Erro
|
||||
|
||||
#### Erro de Compilação/Build
|
||||
|
||||
```bash
|
||||
# Erro de tipo TypeScript
|
||||
Verificação obrigatória(Alta):
|
||||
- Configuração do tsconfig.json
|
||||
- Existência de arquivo de definição de tipo(.d.ts)
|
||||
- Precisão da declaração import
|
||||
|
||||
# Erro de lifetime do Rust
|
||||
Verificação obrigatória(Alta):
|
||||
- Movimento de propriedade
|
||||
- Período de validade da referência
|
||||
- Conflito de mutabilidade
|
||||
```
|
||||
|
||||
#### Erro de Runtime
|
||||
|
||||
```bash
|
||||
# Referência Null/Undefined
|
||||
Verificação obrigatória(Alta):
|
||||
- Falta de optional chaining
|
||||
- Timing de inicialização
|
||||
- Espera pela conclusão do processamento assíncrono
|
||||
|
||||
# Erro relacionado à memória
|
||||
Verificação obrigatória(Alta):
|
||||
- Obtenção de heap dump
|
||||
- Análise de log GC
|
||||
- Detecção de referência circular
|
||||
```
|
||||
|
||||
#### Erro de Dependência
|
||||
|
||||
```bash
|
||||
# Conflito de versão
|
||||
Verificação obrigatória(Alta):
|
||||
- Integridade do arquivo lock
|
||||
- Requisitos de peer dependencies
|
||||
- Dependência transitiva
|
||||
|
||||
# Erro de resolução de módulo
|
||||
Verificação obrigatória(Alta):
|
||||
- Configuração NODE_PATH
|
||||
- Configuração de alias de caminho
|
||||
- Link simbólico
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Absolutamente proibido**: Julgamento baseado apenas em parte da mensagem de erro, aplicação de soluções do Stack Overflow sem verificação
|
||||
- **Condições de exceção**: Soluções temporárias são permitidas apenas nas seguintes 3 condições
|
||||
1. Resposta de emergência no ambiente de produção(resolução fundamental obrigatória em 24 horas)
|
||||
2. Falha de serviço externo(meio alternativo durante espera de recuperação)
|
||||
3. Bug conhecido do framework(esperando lançamento de versão corrigida)
|
||||
- **Recomendação**: Priorizar a identificação da causa raiz e evitar correções superficiais
|
||||
|
||||
### Melhores Práticas
|
||||
|
||||
1. **Coleta completa de informações**: Verificar mensagem de erro do início ao fim
|
||||
2. **Confirmação de reprodutibilidade**: Priorizar criação de código de reprodução mínima
|
||||
3. **Abordagem gradual**: Começar com pequenas correções e verificar
|
||||
4. **Documentação**: Registrar processo de resolução para compartilhamento de conhecimento
|
||||
|
||||
#### Erros Comuns
|
||||
|
||||
- **Lidar com sintomas**: Correção superficial que perde a causa raiz
|
||||
- **Generalização excessiva**: Aplicar amplamente solução de caso específico
|
||||
- **Omitir verificação**: Não verificar efeitos colaterais após correção
|
||||
- **Personalização do conhecimento**: Não documentar método de resolução
|
||||
|
||||
### Comandos Relacionados
|
||||
|
||||
- `/design-patterns` : Analisar problemas de estrutura de código e propor padrões
|
||||
- `/tech-debt` : Analisar causa raiz de erro do ponto de vista da dívida técnica
|
||||
- `/analyzer` : Quando necessária análise mais profunda da causa raiz
|
||||
312
commands/multi-role.md
Normal file
312
commands/multi-role.md
Normal file
@@ -0,0 +1,312 @@
|
||||
## Multi Role
|
||||
|
||||
Comando que realiza análise paralela do mesmo objeto com múltiplos roles e gera relatório integrado.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
/multi-role <role1>,<role2> [--agent|-a] [objeto de análise]
|
||||
/multi-role <role1>,<role2>,<role3> [--agent|-a] [objeto de análise]
|
||||
```
|
||||
|
||||
### Roles Disponíveis
|
||||
|
||||
#### Roles de Análise Especializada
|
||||
|
||||
- `security` : Especialista em auditoria de segurança
|
||||
- `performance` : Especialista em otimização de performance
|
||||
- `analyzer` : Especialista em análise de causa raiz
|
||||
- `frontend` : Especialista em Frontend/UI/UX
|
||||
- `mobile` : Especialista em desenvolvimento mobile
|
||||
- `backend` : Especialista em backend e servidor
|
||||
|
||||
#### Roles de Suporte ao Desenvolvimento
|
||||
|
||||
- `reviewer` : Especialista em revisão de código
|
||||
- `architect` : Arquiteto de sistemas
|
||||
- `qa` : Engenheiro de testes
|
||||
|
||||
**Importante**:
|
||||
|
||||
- A opção `--agent` deve ser colocada imediatamente após a especificação dos roles
|
||||
- A mensagem deve ser escrita após `--agent`
|
||||
- Exemplo correto: `/multi-role qa,architect --agent avalie o plano`
|
||||
- Exemplo incorreto: `/multi-role qa,architect avalie o plano --agent`
|
||||
|
||||
### Opções
|
||||
|
||||
- `--agent` ou `-a` : Executa cada role como subagente em paralelo (recomendado para análises em larga escala)
|
||||
- Quando esta opção é usada, se a descrição de cada role contém frases de promoção de delegação automática (como "use PROACTIVELY"), uma delegação automática mais agressiva será habilitada
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Análise de segurança e performance (normal)
|
||||
/multi-role security,performance
|
||||
"Avalie este endpoint de API"
|
||||
|
||||
# Análise paralela de sistema em larga escala (subagente)
|
||||
/multi-role security,performance --agent
|
||||
"Analise comprehensivamente a segurança e performance de todo o sistema"
|
||||
|
||||
# Análise integrada de frontend, mobile e performance
|
||||
/multi-role frontend,mobile,performance
|
||||
"Considere propostas de otimização desta tela"
|
||||
|
||||
# Avaliação multifacetada de design arquitetural (subagente)
|
||||
/multi-role architect,security,performance --agent
|
||||
"Avalie o design de migração para microsserviços"
|
||||
```
|
||||
|
||||
### Processo de Análise
|
||||
|
||||
### Phase 1: Análise Paralela
|
||||
|
||||
Cada role analisa independentemente o mesmo objeto
|
||||
|
||||
- Execução de avaliação do ponto de vista especializado
|
||||
- Julgamento com critérios específicos do role
|
||||
- Geração de recomendações independentes
|
||||
|
||||
### Phase 2: Análise de Integração
|
||||
|
||||
Estrutura e integra os resultados
|
||||
|
||||
- Organização dos resultados de avaliação de cada role
|
||||
- Identificação de sobreposições e pontos contraditórios
|
||||
- Clarificação de relacionamentos complementares
|
||||
|
||||
### Phase 3: Relatório Integrado
|
||||
|
||||
Geração de recomendações finais
|
||||
|
||||
- Plano de ação com prioridades
|
||||
- Explicitação de trade-offs
|
||||
- Apresentação de roadmap de implementação
|
||||
|
||||
### Exemplo de Formato de Saída
|
||||
|
||||
### Caso de análise com 2 roles
|
||||
|
||||
```text
|
||||
Análise Multi-Role: Security + Performance
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Objeto de análise: Endpoint API /api/users
|
||||
|
||||
Resultado da análise Security:
|
||||
Autenticação: Verificação JWT implementada adequadamente
|
||||
Autorização: Controle de acesso baseado em roles incompleto
|
||||
Criptografia: Chave API sendo outputada em texto plano nos logs
|
||||
|
||||
Score de avaliação: 65/100
|
||||
Importância: Alta (devido ao acesso a dados confidenciais)
|
||||
|
||||
Resultado da análise Performance:
|
||||
Tempo de resposta: Média 180ms (meta: dentro de 200ms)
|
||||
Query de banco de dados: Problema N+1 detectado
|
||||
Cache: Cache Redis não implementado
|
||||
|
||||
Score de avaliação: 70/100
|
||||
Importância: Média (dentro do range aceitável atualmente)
|
||||
|
||||
Análise de correlação:
|
||||
Oportunidades sinérgicas:
|
||||
- Considerar criptografia simultaneamente na implementação do cache Redis
|
||||
- Melhoria na saída de logs beneficia segurança + performance
|
||||
|
||||
Pontos de trade-off:
|
||||
- Reforço da verificação de autorização ↔ Impacto no tempo de resposta
|
||||
- Criptografia de logs ↔ Redução da eficiência de debug
|
||||
|
||||
Prioridade integrada:
|
||||
Critical: Correção da saída de chave API em texto plano
|
||||
High: Resolução de query N+1
|
||||
Medium: Implementação de cache Redis + criptografia
|
||||
Low: Detalhamento do controle de autorização
|
||||
|
||||
Roadmap de implementação:
|
||||
Semana 1: Implementação de mascaramento de chave API
|
||||
Semana 2: Otimização de query de banco de dados
|
||||
Semana 3-4: Design e implementação de camada de cache
|
||||
Mês 2: Reforço gradual do controle de autorização
|
||||
```
|
||||
|
||||
### Caso de análise com 3 roles
|
||||
|
||||
```text
|
||||
Análise Multi-Role: Frontend + Mobile + Performance
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Objeto de análise: Tela de perfil do usuário
|
||||
|
||||
Resultado da análise Frontend:
|
||||
Usabilidade: Layout intuitivo
|
||||
Acessibilidade: Taxa de conformidade WCAG 2.1: 85%
|
||||
Responsivo: Problemas na exibição em tablet
|
||||
|
||||
Resultado da análise Mobile:
|
||||
Touch target: Mais de 44pt garantido
|
||||
Operação com uma mão: Botões importantes posicionados na parte superior
|
||||
Suporte offline: Não implementado
|
||||
|
||||
Resultado da análise Performance:
|
||||
Exibição inicial: LCP 2.1 segundos (bom)
|
||||
Otimização de imagens: WebP não suportado
|
||||
Carregamento tardio: Não implementado
|
||||
|
||||
Recomendações integradas:
|
||||
1. Otimização mobile (operação com uma mão + suporte offline)
|
||||
2. Otimização de imagens (WebP + carregamento tardio)
|
||||
3. Melhoria da UI para tablet
|
||||
|
||||
Prioridade: Mobile > Performance > Frontend
|
||||
Período de implementação: 3-4 semanas
|
||||
```
|
||||
|
||||
### Padrões de Combinação Eficazes
|
||||
|
||||
### Foco em Segurança
|
||||
|
||||
```bash
|
||||
/multi-role security,architect
|
||||
"Design do sistema de autenticação"
|
||||
|
||||
/multi-role security,frontend
|
||||
"Segurança da tela de login"
|
||||
|
||||
/multi-role security,mobile
|
||||
"Proteção de dados do app mobile"
|
||||
```
|
||||
|
||||
### Foco em Performance
|
||||
|
||||
```bash
|
||||
/multi-role performance,architect
|
||||
"Design de escalabilidade"
|
||||
|
||||
/multi-role performance,frontend
|
||||
"Aceleração de páginas web"
|
||||
|
||||
/multi-role performance,mobile
|
||||
"Otimização de operação do app"
|
||||
```
|
||||
|
||||
### Foco na Experiência do Usuário
|
||||
|
||||
```bash
|
||||
/multi-role frontend,mobile
|
||||
"UI multiplataforma"
|
||||
|
||||
/multi-role frontend,performance
|
||||
"Equilíbrio entre UX e performance"
|
||||
|
||||
/multi-role mobile,performance
|
||||
"Otimização de UX mobile"
|
||||
```
|
||||
|
||||
### Análise Abrangente
|
||||
|
||||
```bash
|
||||
/multi-role architect,security,performance
|
||||
"Avaliação de todo o sistema"
|
||||
|
||||
/multi-role frontend,mobile,performance
|
||||
"Avaliação geral da experiência do usuário"
|
||||
|
||||
/multi-role security,performance,mobile
|
||||
"Diagnóstico geral do app mobile"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Combinação com análise de arquivos
|
||||
cat src/components/UserProfile.tsx
|
||||
/multi-role frontend,mobile
|
||||
"Avalie este componente de múltiplas perspectivas"
|
||||
|
||||
# Avaliação de documento de design
|
||||
cat architecture-design.md
|
||||
/multi-role architect,security,performance
|
||||
"Avalie este design em múltiplas áreas especializadas"
|
||||
|
||||
# Análise de erros
|
||||
cat performance-issues.log
|
||||
/multi-role performance,analyzer
|
||||
"Analise problemas de performance de múltiplos ângulos"
|
||||
```
|
||||
|
||||
### Diferenciação entre multi-role vs role-debate
|
||||
|
||||
### Quando usar multi-role
|
||||
|
||||
- Quer avaliação independente de cada área especializada
|
||||
- Quer elaborar plano de melhorias integrado
|
||||
- Quer organizar contradições e sobreposições
|
||||
- Quer decidir prioridade de implementação
|
||||
|
||||
### Quando usar role-debate
|
||||
|
||||
- Há trade-offs entre áreas especializadas
|
||||
- Opiniões podem se dividir na seleção técnica
|
||||
- Quer decidir política de design através de discussão
|
||||
- Quer ouvir discussão de diferentes perspectivas
|
||||
|
||||
### Execução Paralela de Subagentes (--agent)
|
||||
|
||||
Usando a opção `--agent`, cada role é executado em paralelo como subagente independente.
|
||||
|
||||
#### Promoção de Delegação Automática
|
||||
|
||||
Quando o campo description dos arquivos de role contém frases como as seguintes, uma delegação automática mais agressiva é habilitada no uso de `--agent`:
|
||||
|
||||
- "use PROACTIVELY"
|
||||
- "MUST BE USED"
|
||||
- Outras expressões de ênfase
|
||||
|
||||
#### Fluxo de Execução
|
||||
|
||||
```text
|
||||
Execução normal:
|
||||
Role 1 → Role 2 → Role 3 → Integração
|
||||
(Execução sequencial, cerca de 3-5 minutos)
|
||||
|
||||
Execução --agent:
|
||||
Role 1 ─┐
|
||||
Role 2 ─┼→ Integração
|
||||
Role 3 ─┘
|
||||
(Execução paralela, cerca de 1-2 minutos)
|
||||
```
|
||||
|
||||
#### Exemplos de Uso Eficaz
|
||||
|
||||
```bash
|
||||
# Avaliação geral de sistema em larga escala
|
||||
/multi-role architect,security,performance,qa --agent
|
||||
"Avaliação abrangente do novo sistema"
|
||||
|
||||
# Análise detalhada de múltiplas perspectivas
|
||||
/multi-role frontend,mobile,performance --agent
|
||||
"Análise de otimização UX de todas as telas"
|
||||
```
|
||||
|
||||
#### Comparação de Performance
|
||||
|
||||
| Número de Roles | Execução Normal | Execução --agent | Taxa de Redução |
|
||||
| --------------- | --------------- | ---------------- | --------------- |
|
||||
| 2 roles | 2-3 min | 1 min | 50% |
|
||||
| 3 roles | 3-5 min | 1-2 min | 60% |
|
||||
| 4 roles | 5-8 min | 2-3 min | 65% |
|
||||
|
||||
### Observações
|
||||
|
||||
- Execução simultânea de 3 ou mais roles pode resultar em saída longa
|
||||
- Análises complexas podem levar mais tempo de execução
|
||||
- Se surgirem recomendações mutuamente contraditórias, considere também role-debate
|
||||
- A decisão final deve ser tomada pelo usuário com base nos resultados integrados
|
||||
- **Ao usar --agent**: Usa mais recursos, mas é eficiente para análises em larga escala
|
||||
|
||||
### Detalhes de Configuração dos Roles
|
||||
|
||||
- As configurações detalhadas, o conhecimento especializado e as características de discussão de cada role são definidos em `.claude/agents/roles/`
|
||||
- Inclui práticas Evidence-First e contramedidas contra vieses cognitivos
|
||||
- Frases gatilho específicas de cada role ativam automaticamente o modo especializado
|
||||
134
commands/plan.md
Normal file
134
commands/plan.md
Normal file
@@ -0,0 +1,134 @@
|
||||
## Plan
|
||||
|
||||
Inicia o modo de planejamento pré-implementação para estabelecer estratégias detalhadas de implementação. Apoia desenvolvimento eficiente através do estabelecimento de planos estruturados antes da implementação do código.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Solicitar Plan Mode ao Claude
|
||||
"Faça um plano de implementação para [conteúdo da implementação]"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Plano de implementação de nova funcionalidade
|
||||
"Faça um plano de implementação para funcionalidade de autenticação de usuário"
|
||||
|
||||
# Plano de design de sistema
|
||||
"Faça um plano de implementação para divisão em microsserviços"
|
||||
|
||||
# Plano de refatoração
|
||||
"Faça um plano de refatoração do código legado"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Implementação de funcionalidade complexa
|
||||
"Faça um plano de implementação para funcionalidade de chat. Incluindo WebSocket, notificações em tempo real e gestão de histórico"
|
||||
|
||||
# Design de banco de dados
|
||||
"Faça um plano de design de banco de dados para site de e-commerce. Incluindo gestão de produtos, pedidos e usuários"
|
||||
|
||||
# Design de API
|
||||
"Faça um plano de implementação de API GraphQL. Incluindo autenticação, cache e limitação de taxa"
|
||||
|
||||
# Design de infraestrutura
|
||||
"Faça um plano de implementação de dockerização. Incluindo ambiente de desenvolvimento, ambiente de produção e CI/CD"
|
||||
```
|
||||
|
||||
### Características do Plan Mode
|
||||
|
||||
**Inicialização Automática**
|
||||
|
||||
- Plan Mode inicia automaticamente ao detectar tarefas de implementação
|
||||
- Pode ser iniciado explicitamente com palavras-chave como "faça plano de implementação"
|
||||
|
||||
**Especificação Estruturada**
|
||||
|
||||
- Definição de requisitos (User Stories e critérios de aceitação)
|
||||
- Documentos de design (arquitetura, design de dados, design de UI)
|
||||
- Plano de implementação (decomposição de tarefas, acompanhamento de progresso, garantia de qualidade)
|
||||
- Análise e contramedidas de riscos
|
||||
|
||||
**Processo de Aprovação**
|
||||
|
||||
- Apresentação do plano com ferramenta `exit_plan_mode`
|
||||
- **Importante**: Sempre aguardar aprovação explícita do usuário, independentemente do valor de retorno da ferramenta
|
||||
- É proibido iniciar implementação sem aprovação
|
||||
- É possível corrigir e ajustar o plano
|
||||
- Iniciar gestão de tarefas com TodoWrite apenas após aprovação
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Implementação de sistema complexo
|
||||
"Faça um plano de implementação de sistema de pagamento online. Incluindo integração com Stripe, segurança e tratamento de erros"
|
||||
|
||||
# Implementação de frontend
|
||||
"Faça um plano de implementação de dashboard React. Incluindo gestão de estado, design de componentes e testes"
|
||||
|
||||
# Implementação de backend
|
||||
"Faça um plano de implementação de RESTful API. Incluindo autenticação, validação e registro de logs"
|
||||
|
||||
# Implementação DevOps
|
||||
"Faça um plano de implementação de pipeline CI/CD. Incluindo automação de testes, deployment e monitoramento"
|
||||
```
|
||||
|
||||
### Workflow de 3 Fases
|
||||
|
||||
#### Fase 1: Requirements (Definição de Requisitos)
|
||||
|
||||
- **User Stories**: Clarificar propósito e valor das funcionalidades
|
||||
- **Critérios de Aceitação**: Definir condições de conclusão e padrões de qualidade
|
||||
- **Restrições e Pré-condições**: Organizar restrições técnicas e temporais
|
||||
- **Priorização**: Classificação em Must-have/Nice-to-have
|
||||
|
||||
#### Fase 2: Design
|
||||
|
||||
- **Design de Arquitetura**: Configuração do sistema e seleção de tecnologias
|
||||
- **Design de Dados**: Schema, especificações de API, fluxo de dados
|
||||
- **Design de UI/UX**: Configuração de telas e fluxo de operações
|
||||
- **Análise de Riscos**: Problemas potenciais e contramedidas
|
||||
|
||||
#### Fase 3: Implementation (Implementação)
|
||||
|
||||
- **Decomposição de Tarefas**: Subdivisão em unidades implementáveis
|
||||
- **Acompanhamento de Progresso**: Gestão de estado através de TodoWrite
|
||||
- **Garantia de Qualidade**: Estratégia de testes e métodos de verificação
|
||||
- **Processo de Aprovação**: Apresentação do plano com exit_plan_mode e espera por aprovação explícita
|
||||
|
||||
### Observações
|
||||
|
||||
**Escopo de Aplicação**
|
||||
|
||||
- Plan Mode é otimizado para tarefas complexas de implementação
|
||||
- Para correções simples ou mudanças de pequena escala, usar formato de implementação normal
|
||||
- Recomendado para trabalhos de 3 passos ou mais, ou desenvolvimento de novas funcionalidades
|
||||
|
||||
**Restrições Técnicas**
|
||||
|
||||
- Não confiar no valor de retorno da ferramenta `exit_plan_mode`
|
||||
- Julgamento do processo de aprovação pela manifestação explícita da vontade do usuário
|
||||
- Funcionalidade diferente do plan mode da CLI
|
||||
|
||||
**Atenção na Execução**
|
||||
|
||||
- Rigorosamente proibido iniciar implementação antes da aprovação
|
||||
- Sempre aguardar resposta do usuário após apresentação do plano
|
||||
- Apresentar meios alternativos em caso de erro
|
||||
|
||||
### Exemplo de Execução
|
||||
|
||||
```bash
|
||||
# Exemplo de uso
|
||||
"Faça um plano de implementação do sistema de gestão de usuários"
|
||||
|
||||
# Comportamento esperado
|
||||
# 1. Plan Mode inicia automaticamente
|
||||
# 2. Análise de requisitos e seleção de tecnologia
|
||||
# 3. Estruturação dos passos de implementação
|
||||
# 4. Apresentação do plano com exit_plan_mode
|
||||
# 5. Iniciar implementação após aprovação
|
||||
```
|
||||
460
commands/pr-auto-update.md
Normal file
460
commands/pr-auto-update.md
Normal file
@@ -0,0 +1,460 @@
|
||||
## PR Auto Update
|
||||
|
||||
## Visão Geral
|
||||
|
||||
Comando para atualizar automaticamente a descrição e rótulos de Pull Requests. Analisa as alterações do Git para gerar e definir descrições e rótulos apropriados.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
/pr-auto-update [opções] [número do PR]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--pr <número>` : Especifica o número do PR alvo (detecta automaticamente do branch atual se omitido)
|
||||
- `--description-only` : Atualiza apenas a descrição (não altera os rótulos)
|
||||
- `--labels-only` : Atualiza apenas os rótulos (não altera a descrição)
|
||||
- `--dry-run` : Não executa a atualização real, apenas exibe o conteúdo que seria gerado
|
||||
- `--lang <idioma>` : Especifica o idioma (pt, en)
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Atualiza automaticamente o PR do branch atual
|
||||
/pr-auto-update
|
||||
|
||||
# Atualiza um PR específico
|
||||
/pr-auto-update --pr 1234
|
||||
|
||||
# Atualiza apenas a descrição
|
||||
/pr-auto-update --description-only
|
||||
|
||||
# Confirmação com dry-run
|
||||
/pr-auto-update --dry-run
|
||||
```
|
||||
|
||||
## Detalhes da Funcionalidade
|
||||
|
||||
### 1. Detecção Automática de PR
|
||||
|
||||
Detecta automaticamente o PR correspondente do branch atual:
|
||||
|
||||
```bash
|
||||
# Busca PR do branch
|
||||
gh pr list --head $(git branch --show-current) --json number,title,url
|
||||
```
|
||||
|
||||
### 2. Análise do Conteúdo das Alterações
|
||||
|
||||
Coleta e analisa as seguintes informações:
|
||||
|
||||
- **Alterações de Arquivo**: Arquivos adicionados, removidos ou modificados
|
||||
- **Análise de Código**: Alterações em declarações import, definições de função e classe
|
||||
- **Testes**: Presença e conteúdo de arquivos de teste
|
||||
- **Documentação**: Atualizações de README e docs
|
||||
- **Configuração**: Alterações em package.json, pubspec.yaml, arquivos de configuração
|
||||
- **CI/CD**: Alterações em GitHub Actions e workflow
|
||||
|
||||
### 3. Geração Automática de Descrição
|
||||
|
||||
#### Prioridade do Processamento de Template
|
||||
|
||||
1. **Descrição de PR Existente**: **Segue completamente** o conteúdo já descrito
|
||||
2. **Template do Projeto**: Obtém estrutura de `.github/PULL_REQUEST_TEMPLATE.md`
|
||||
3. **Template Padrão**: Fallback caso os anteriores não existam
|
||||
|
||||
#### Regras de Preservação de Conteúdo Existente
|
||||
|
||||
**Importante**: Não altera o conteúdo existente
|
||||
|
||||
- Preserva seções já escritas
|
||||
- Complementa apenas seções vazias
|
||||
- Preserva comentários funcionais (como regras do Copilot review)
|
||||
|
||||
#### Uso do Template do Projeto
|
||||
|
||||
```bash
|
||||
# Analisa a estrutura de .github/PULL_REQUEST_TEMPLATE.md
|
||||
parse_template_structure() {
|
||||
local template_file="$1"
|
||||
|
||||
if [ -f "$template_file" ]; then
|
||||
# Extrai estrutura das seções
|
||||
grep -E '^##|^###' "$template_file"
|
||||
|
||||
# Identifica placeholders de comentário
|
||||
grep -E '<!--.*-->' "$template_file"
|
||||
|
||||
# Segue completamente a estrutura do template existente
|
||||
cat "$template_file"
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Configuração Automática de Rótulos
|
||||
|
||||
#### Mecanismo de Obtenção de Rótulos
|
||||
|
||||
**Ordem de Prioridade**:
|
||||
|
||||
1. **`.github/labels.yml`**: Obtém de definições de rótulos específicos do projeto
|
||||
2. **GitHub API**: Obtém rótulos existentes com `gh api repos/{OWNER}/{REPO}/labels --jq '.[].name'`
|
||||
|
||||
#### Regras de Determinação Automática
|
||||
|
||||
**Baseado em Padrões de Arquivo**:
|
||||
|
||||
- Documentação: `*.md`, `README`, `docs/` → rótulos contendo `documentation|docs|doc`
|
||||
- Teste: `test`, `spec` → rótulos contendo `test|testing`
|
||||
- CI/CD: `.github/`, `*.yml`, `Dockerfile` → rótulos contendo `ci|build|infra|ops`
|
||||
- Dependências: `package.json`, `pubspec.yaml`, `requirements.txt` → rótulos contendo `dependencies|deps`
|
||||
|
||||
**Baseado no Conteúdo das Alterações**:
|
||||
|
||||
- Correção de Bug: `fix|bug|error|crash|corrigir` → rótulos contendo `bug|fix`
|
||||
- Nova Funcionalidade: `feat|feature|add|implement|novo|adicionar` → rótulos contendo `feature|enhancement|feat`
|
||||
- Refatoração: `refactor|clean|refatorar|limpar` → rótulos contendo `refactor|cleanup|clean`
|
||||
- Performance: `performance|perf|optimize|otimizar|desempenho` → rótulos contendo `performance|perf`
|
||||
- Segurança: `security|secure|segurança|proteger` → rótulos contendo `security`
|
||||
|
||||
#### Restrições
|
||||
|
||||
- **Máximo 3**: Limite superior do número de rótulos selecionados automaticamente
|
||||
- **Apenas Rótulos Existentes**: Proibida a criação de novos rótulos
|
||||
- **Correspondência Parcial**: Determina se palavras-chave estão contidas no nome do rótulo
|
||||
|
||||
#### Exemplo de Uso Real
|
||||
|
||||
**Quando `.github/labels.yml` existe**:
|
||||
|
||||
```bash
|
||||
# Obtém automaticamente das definições de rótulo
|
||||
grep "^- name:" .github/labels.yml | sed "s/^- name: '\?\([^']*\)'\?/\1/"
|
||||
|
||||
# Exemplo: Usa sistema de rótulos específico do projeto
|
||||
```
|
||||
|
||||
**Quando obtém do GitHub API**:
|
||||
|
||||
```bash
|
||||
# Obtém lista de rótulos existentes
|
||||
gh api repos/{OWNER}/{REPO}/labels --jq '.[].name'
|
||||
|
||||
# Exemplo: Usa rótulos padrão como bug, enhancement, documentation
|
||||
```
|
||||
|
||||
### 5. Fluxo de Execução
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# 1. Detecção/Obtenção de PR
|
||||
detect_pr() {
|
||||
if [ -n "$PR_NUMBER" ]; then
|
||||
echo $PR_NUMBER
|
||||
else
|
||||
gh pr list --head $(git branch --show-current) --json number --jq '.[0].number'
|
||||
fi
|
||||
}
|
||||
|
||||
# 2. Análise do conteúdo das alterações
|
||||
analyze_changes() {
|
||||
local pr_number=$1
|
||||
|
||||
# Obtém alterações de arquivo
|
||||
gh pr diff $pr_number --name-only
|
||||
|
||||
# Análise do conteúdo
|
||||
gh pr diff $pr_number | head -1000
|
||||
}
|
||||
|
||||
# 3. Geração de descrição
|
||||
generate_description() {
|
||||
local pr_number=$1
|
||||
local changes=$2
|
||||
|
||||
# Obtém descrição atual do PR
|
||||
local current_body=$(gh pr view $pr_number --json body --jq -r .body)
|
||||
|
||||
# Usa conteúdo existente se houver
|
||||
if [ -n "$current_body" ]; then
|
||||
echo "$current_body"
|
||||
else
|
||||
# Gera novo do template
|
||||
local template_file=".github/PULL_REQUEST_TEMPLATE.md"
|
||||
if [ -f "$template_file" ]; then
|
||||
generate_from_template "$(cat "$template_file")" "$changes"
|
||||
else
|
||||
generate_from_template "" "$changes"
|
||||
fi
|
||||
fi
|
||||
}
|
||||
|
||||
# Geração a partir do template
|
||||
generate_from_template() {
|
||||
local template="$1"
|
||||
local changes="$2"
|
||||
|
||||
if [ -n "$template" ]; then
|
||||
# Usa template como está (preserva comentários HTML)
|
||||
echo "$template"
|
||||
else
|
||||
# Gera com formato padrão
|
||||
echo "## What does this change?"
|
||||
echo ""
|
||||
echo "$changes"
|
||||
fi
|
||||
}
|
||||
|
||||
# 4. Determinação de rótulos
|
||||
determine_labels() {
|
||||
local changes=$1
|
||||
local file_list=$2
|
||||
local pr_number=$3
|
||||
|
||||
# Obtém rótulos disponíveis
|
||||
local available_labels=()
|
||||
if [ -f ".github/labels.yml" ]; then
|
||||
# Extrai nomes de rótulo de labels.yml
|
||||
available_labels=($(grep "^- name:" .github/labels.yml | sed "s/^- name: '\?\([^']*\)'\?/\1/"))
|
||||
else
|
||||
# Obtém rótulos do GitHub API
|
||||
local repo_info=$(gh repo view --json owner,name)
|
||||
local owner=$(echo "$repo_info" | jq -r .owner.login)
|
||||
local repo=$(echo "$repo_info" | jq -r .name)
|
||||
available_labels=($(gh api "repos/$owner/$repo/labels" --jq '.[].name'))
|
||||
fi
|
||||
|
||||
local suggested_labels=()
|
||||
|
||||
# Correspondência de padrões genérica
|
||||
analyze_change_patterns "$file_list" "$changes" available_labels suggested_labels
|
||||
|
||||
# Limita a máximo 3
|
||||
echo "${suggested_labels[@]:0:3}"
|
||||
}
|
||||
|
||||
# Determina rótulos a partir de padrões de alteração
|
||||
analyze_change_patterns() {
|
||||
local file_list="$1"
|
||||
local changes="$2"
|
||||
local -n available_ref=$3
|
||||
local -n suggested_ref=$4
|
||||
|
||||
# Determinação por tipo de arquivo
|
||||
if echo "$file_list" | grep -q "\.md$\|README\|docs/"; then
|
||||
add_matching_label "documentation\|docs\|doc" available_ref suggested_ref
|
||||
fi
|
||||
|
||||
if echo "$file_list" | grep -q "test\|spec"; then
|
||||
add_matching_label "test\|testing" available_ref suggested_ref
|
||||
fi
|
||||
|
||||
# Determinação por conteúdo das alterações
|
||||
if echo "$changes" | grep -iq "fix\|bug\|error\|crash\|correção\|erro"; then
|
||||
add_matching_label "bug\|fix" available_ref suggested_ref
|
||||
fi
|
||||
|
||||
if echo "$changes" | grep -iq "feat\|feature\|add\|implement\|funcionalidade\|implementar"; then
|
||||
add_matching_label "feature\|enhancement\|feat" available_ref suggested_ref
|
||||
fi
|
||||
}
|
||||
|
||||
# Adiciona rótulo correspondente
|
||||
add_matching_label() {
|
||||
local pattern="$1"
|
||||
local -n available_ref=$2
|
||||
local -n suggested_ref=$3
|
||||
|
||||
# Pula se já tem 3
|
||||
if [ ${#suggested_ref[@]} -ge 3 ]; then
|
||||
return
|
||||
fi
|
||||
|
||||
# Adiciona primeiro rótulo que corresponde ao padrão
|
||||
for available_label in "${available_ref[@]}"; do
|
||||
if echo "$available_label" | grep -iq "$pattern"; then
|
||||
# Verifica duplicata
|
||||
local already_exists=false
|
||||
for existing in "${suggested_ref[@]}"; do
|
||||
if [ "$existing" = "$available_label" ]; then
|
||||
already_exists=true
|
||||
break
|
||||
fi
|
||||
done
|
||||
|
||||
if [ "$already_exists" = false ]; then
|
||||
suggested_ref+=("$available_label")
|
||||
return
|
||||
fi
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
# Mantém função antiga para compatibilidade
|
||||
find_and_add_label() {
|
||||
add_matching_label "$@"
|
||||
}
|
||||
|
||||
# 5. Atualização do PR
|
||||
update_pr() {
|
||||
local pr_number=$1
|
||||
local description="$2"
|
||||
local labels="$3"
|
||||
|
||||
if [ "$DRY_RUN" = "true" ]; then
|
||||
echo "=== DRY RUN ==="
|
||||
echo "Description:"
|
||||
echo "$description"
|
||||
echo "Labels: $labels"
|
||||
else
|
||||
# Obtém informações do repositório
|
||||
local repo_info=$(gh repo view --json owner,name)
|
||||
local owner=$(echo "$repo_info" | jq -r .owner.login)
|
||||
local repo=$(echo "$repo_info" | jq -r .name)
|
||||
|
||||
# Atualiza corpo usando GitHub API (preserva comentários HTML)
|
||||
# Processa escape JSON adequadamente
|
||||
local escaped_body=$(echo "$description" | jq -R -s .)
|
||||
gh api \
|
||||
--method PATCH \
|
||||
"/repos/$owner/$repo/pulls/$pr_number" \
|
||||
--field body="$description"
|
||||
|
||||
# Rótulos funcionam normalmente com comando gh
|
||||
if [ -n "$labels" ]; then
|
||||
gh pr edit $pr_number --add-label "$labels"
|
||||
fi
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
## Arquivo de Configuração (para expansão futura)
|
||||
|
||||
`~/.claude/pr-auto-update.config`:
|
||||
|
||||
```json
|
||||
{
|
||||
"language": "pt",
|
||||
"max_labels": 3
|
||||
}
|
||||
```
|
||||
|
||||
## Padrões Comuns
|
||||
|
||||
### Projeto Flutter
|
||||
|
||||
```markdown
|
||||
## What does this change?
|
||||
|
||||
Implementou {nome da funcionalidade}. Resolve {problema} do usuário.
|
||||
|
||||
### Principais alterações
|
||||
|
||||
- **Implementação de UI**: Criou nova {nome da tela}
|
||||
- **Gerenciamento de Estado**: Adicionou provedores Riverpod
|
||||
- **Integração com API**: Implementou queries e mutations GraphQL
|
||||
- **Testes**: Adicionou widget tests e unit tests
|
||||
|
||||
### Especificações Técnicas
|
||||
|
||||
- **Arquitetura**: {padrão utilizado}
|
||||
- **Dependências**: {pacotes adicionados}
|
||||
- **Performance**: {conteúdo de otimização}
|
||||
```
|
||||
|
||||
### Projeto Node.js
|
||||
|
||||
```markdown
|
||||
## What does this change?
|
||||
|
||||
Implementou endpoint {nome da API}. Corresponde a {caso de uso}.
|
||||
|
||||
### Principais alterações
|
||||
|
||||
- **Implementação de API**: Criou novo {endpoint}
|
||||
- **Validação**: Adicionou lógica de validação de requisição
|
||||
- **Banco de Dados**: Implementou operações para {nome da tabela}
|
||||
- **Testes**: Adicionou testes de integração e unit tests
|
||||
|
||||
### Segurança
|
||||
|
||||
- **Autenticação**: Verificação de token JWT
|
||||
- **Autorização**: Controle de acesso baseado em papel
|
||||
- **Validação de Entrada**: Contramedidas para injeção SQL
|
||||
```
|
||||
|
||||
### Melhoria de CI/CD
|
||||
|
||||
```markdown
|
||||
## What does this change?
|
||||
|
||||
Melhorou workflow do GitHub Actions. Realiza {efeito}.
|
||||
|
||||
### Conteúdo das melhorias
|
||||
|
||||
- **Performance**: Reduziu tempo de build em {tempo}
|
||||
- **Confiabilidade**: Fortaleceu tratamento de erro
|
||||
- **Segurança**: Melhorou gerenciamento de secrets
|
||||
|
||||
### Detalhes técnicos
|
||||
|
||||
- **Paralelização**: Execução paralela de {nome do job}
|
||||
- **Cache**: Otimizou estratégia de cache para {alvo do cache}
|
||||
- **Monitoramento**: Adicionou monitoramento de {métricas}
|
||||
```
|
||||
|
||||
## Observações
|
||||
|
||||
1. **Preservação Completa do Conteúdo Existente**:
|
||||
- **Não altera nem um caractere** do conteúdo já descrito
|
||||
- Complementa apenas partes de comentários vazias e placeholders
|
||||
- Respeita conteúdo escrito intencionalmente pelo usuário
|
||||
|
||||
2. **Prioridade do Template**:
|
||||
- Descrição de PR existente > `.github/PULL_REQUEST_TEMPLATE.md` > Padrão
|
||||
- Segue completamente estrutura de template específica do projeto
|
||||
|
||||
3. **Restrições de Rótulo**:
|
||||
- Usa prioritariamente `.github/labels.yml` se existir
|
||||
- Se não existir, obtém rótulos existentes do GitHub API
|
||||
- Proibida criação de novos rótulos
|
||||
- Seleciona automaticamente até máximo de 3
|
||||
|
||||
4. **Atualização Segura**:
|
||||
- Recomenda confirmação prévia com `--dry-run`
|
||||
- Exibe aviso para alterações contendo informações confidenciais
|
||||
- Salva descrição original como backup
|
||||
|
||||
5. **Manutenção da Consistência**:
|
||||
- Adequa-se ao estilo de PR existente do projeto
|
||||
- Unifica idioma (japonês/inglês)
|
||||
- Herda regras de rotulagem
|
||||
|
||||
## Solução de Problemas
|
||||
|
||||
### Problemas Comuns
|
||||
|
||||
1. **PR não encontrado**: Confirme associação entre nome do branch e PR
|
||||
2. **Erro de permissão**: Confirme estado de autenticação do GitHub CLI
|
||||
3. **Não consegue definir rótulo**: Confirme permissões do repositório
|
||||
4. **Comentários HTML são escapados**: Devido às especificações do GitHub CLI, `<!-- -->` é convertido para `<!-- -->`
|
||||
|
||||
### Problema de Escape de Comentários HTML do GitHub CLI
|
||||
|
||||
**Importante**: GitHub CLI (`gh pr edit`) escapa automaticamente comentários HTML. Além disso, strings inválidas como `EOF < /dev/null` podem ser misturadas devido ao processamento de redirecionamento do shell.
|
||||
|
||||
#### Soluções Fundamentais
|
||||
|
||||
1. **Uso da opção --field do GitHub API**: Usa `--field` para processamento adequado de escape
|
||||
2. **Simplificação do processamento Shell**: Evita processamento complexo de redirecionamento e pipe
|
||||
3. **Simplificação do processamento de template**: Elimina processamento de remoção de comentários HTML e preserva completamente
|
||||
4. **Processamento adequado de escape JSON**: Processa corretamente caracteres especiais
|
||||
|
||||
### Opções de Debug
|
||||
|
||||
```bash
|
||||
# Saída de log detalhado (adicionar durante implementação)
|
||||
/pr-auto-update --verbose
|
||||
```
|
||||
249
commands/pr-create.md
Normal file
249
commands/pr-create.md
Normal file
@@ -0,0 +1,249 @@
|
||||
## PR Create
|
||||
|
||||
Criação automática de PR baseada em análise de mudanças Git para um workflow eficiente de Pull Request.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Criação automática de PR por análise de mudanças
|
||||
git add . && git commit -m "feat: implementação da funcionalidade de autenticação do usuário"
|
||||
"Analise o conteúdo das mudanças e crie um Draft PR com descrições e rótulos apropriados"
|
||||
|
||||
# Atualização mantendo template existente
|
||||
cp .github/PULL_REQUEST_TEMPLATE.md pr_body.md
|
||||
"Mantenha completamente a estrutura do template e complemente o conteúdo das mudanças"
|
||||
|
||||
# Melhoria gradual da qualidade
|
||||
gh pr ready
|
||||
"Após confirmação da qualidade, altere para Ready for Review"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# 1. Criação de branch e commit
|
||||
git checkout main && git pull
|
||||
git checkout -b feat-user-profile
|
||||
git add . && git commit -m "feat: implementação da funcionalidade de perfil do usuário"
|
||||
git push -u origin feat-user-profile
|
||||
|
||||
# 2. Criação de PR
|
||||
"Crie um PR seguindo os seguintes passos:
|
||||
1. Confirme o conteúdo das mudanças com git diff --cached
|
||||
2. Crie a descrição usando .github/PULL_REQUEST_TEMPLATE.md
|
||||
3. Selecione até 3 rótulos apropriados baseados no conteúdo das mudanças
|
||||
4. Crie como Draft PR (mantenha comentários HTML)"
|
||||
|
||||
# 3. Tornar Ready após confirmação do CI
|
||||
"Quando o CI passar, altere o PR para Ready for Review"
|
||||
```
|
||||
|
||||
### Procedimento de Execução
|
||||
|
||||
#### 1. Criação de Branch
|
||||
|
||||
```bash
|
||||
# Regras de nomenclatura seguindo diretrizes: {type}-{subject}
|
||||
git checkout main
|
||||
git pull
|
||||
git checkout -b feat-user-authentication
|
||||
|
||||
# Confirmação de branch (exibe o nome da branch atual)
|
||||
git branch --show-current
|
||||
```
|
||||
|
||||
#### 2. Commit
|
||||
|
||||
```bash
|
||||
# Stage das mudanças
|
||||
git add .
|
||||
|
||||
# Mensagem de commit seguindo diretrizes
|
||||
git commit -m "feat: implementação da API de autenticação do usuário"
|
||||
```
|
||||
|
||||
#### 3. Push para Remote
|
||||
|
||||
```bash
|
||||
# Push inicial (configuração upstream)
|
||||
git push -u origin feat-user-authentication
|
||||
|
||||
# A partir da segunda vez
|
||||
git push
|
||||
```
|
||||
|
||||
#### 4. Criação de Draft PR por Análise Automática
|
||||
|
||||
**Step 1: Análise do Conteúdo das Mudanças**
|
||||
|
||||
```bash
|
||||
# Obtenção de mudanças nos arquivos (confirma mudanças em stage)
|
||||
git diff --cached --name-only
|
||||
|
||||
# Análise de conteúdo (máximo 1000 linhas)
|
||||
git diff --cached | head -1000
|
||||
```
|
||||
|
||||
**Step 2: Geração Automática de Descrição**
|
||||
|
||||
```bash
|
||||
# Ordem de prioridade no processamento de templates
|
||||
# 1. Descrição de PR existente (manter completamente)
|
||||
# 2. .github/PULL_REQUEST_TEMPLATE.md
|
||||
# 3. Template padrão
|
||||
|
||||
cp .github/PULL_REQUEST_TEMPLATE.md pr_body.md
|
||||
# Complementar apenas seções vazias mantendo comentários HTML e linhas separadoras
|
||||
```
|
||||
|
||||
**Step 3: Seleção Automática de Rótulos**
|
||||
|
||||
```bash
|
||||
# Obtenção de rótulos disponíveis (não interativo)
|
||||
"Obtenha os rótulos disponíveis de .github/labels.yml ou do repositório GitHub e selecione automaticamente rótulos apropriados baseados no conteúdo das mudanças"
|
||||
|
||||
# Seleção automática por correspondência de padrão (máximo 3)
|
||||
# - Documentação: *.md, docs/ → documentation|docs
|
||||
# - Teste: test, spec → test|testing
|
||||
# - Correção de bug: fix|bug → bug|fix
|
||||
# - Nova funcionalidade: feat|feature → feature|enhancement
|
||||
```
|
||||
|
||||
**Step 4: Criação de PR com GitHub API (Mantendo Comentários HTML)**
|
||||
|
||||
```bash
|
||||
# Criação de PR
|
||||
"Crie um Draft PR com as seguintes informações:
|
||||
- Título: geração automática a partir da mensagem de commit
|
||||
- Descrição: use .github/PULL_REQUEST_TEMPLATE.md e preencha adequadamente
|
||||
- Rótulos: seleção automática baseada no conteúdo das mudanças (máximo 3)
|
||||
- Branch base: main
|
||||
- Mantenha completamente os comentários HTML"
|
||||
```
|
||||
|
||||
**Método B: GitHub MCP (Fallback)**
|
||||
|
||||
```javascript
|
||||
// Criação de PR mantendo comentários HTML
|
||||
mcp_github_create_pull_request({
|
||||
owner: "organization",
|
||||
repo: "repository",
|
||||
base: "main",
|
||||
head: "feat-user-authentication",
|
||||
title: "feat: implementação da autenticação do usuário",
|
||||
body: prBodyContent, // conteúdo completo incluindo comentários HTML
|
||||
draft: true,
|
||||
maintainer_can_modify: true,
|
||||
});
|
||||
```
|
||||
|
||||
### Sistema de Seleção Automática de Rótulos
|
||||
|
||||
#### Determinação Baseada em Padrão de Arquivos
|
||||
|
||||
- **Documentação**: `*.md`, `README`, `docs/` → `documentation|docs|doc`
|
||||
- **Teste**: `test`, `spec` → `test|testing`
|
||||
- **CI/CD**: `.github/`, `*.yml`, `Dockerfile` → `ci|build|infra|ops`
|
||||
- **Dependências**: `package.json`, `pubspec.yaml` → `dependencies|deps`
|
||||
|
||||
#### Determinação Baseada em Conteúdo das Mudanças
|
||||
|
||||
- **Correção de bug**: `fix|bug|error|crash|corrigir` → `bug|fix`
|
||||
- **Nova funcionalidade**: `feat|feature|add|implement|novo|adicionar` → `feature|enhancement|feat`
|
||||
- **Refatoração**: `refactor|clean|refatorar|limpar` → `refactor|cleanup|clean`
|
||||
- **Performance**: `performance|perf|optimize` → `performance|perf`
|
||||
- **Segurança**: `security|secure` → `security`
|
||||
|
||||
#### Restrições
|
||||
|
||||
- **Máximo 3**: limite superior da seleção automática
|
||||
- **Apenas rótulos existentes**: criação de novos proibida
|
||||
- **Correspondência parcial**: determinação por inclusão de palavras-chave
|
||||
|
||||
### Diretrizes do Projeto
|
||||
|
||||
#### Postura Básica
|
||||
|
||||
1. **Sempre iniciar como Draft**: todos os PRs são criados no estado Draft
|
||||
2. **Melhoria gradual da qualidade**: Fase 1 (implementação básica) → Fase 2 (adição de testes) → Fase 3 (atualização de documentação)
|
||||
3. **Rótulos apropriados**: sempre adicionar até 3 tipos de rótulos
|
||||
4. **Uso de template**: sempre usar `.github/PULL_REQUEST_TEMPLATE.md`
|
||||
5. **Espaços em japonês**: sempre espaço em branco entre japonês e caracteres alfanuméricos
|
||||
|
||||
#### Regras de Nomenclatura de Branch
|
||||
|
||||
```text
|
||||
{type}-{subject}
|
||||
|
||||
Exemplos:
|
||||
- feat-user-profile
|
||||
- fix-login-error
|
||||
- refactor-api-client
|
||||
```
|
||||
|
||||
#### Mensagem de Commit
|
||||
|
||||
```text
|
||||
{type}: {description}
|
||||
|
||||
Exemplos:
|
||||
- feat: implementação da API de autenticação do usuário
|
||||
- fix: correção do erro de login
|
||||
- docs: atualização do README
|
||||
```
|
||||
|
||||
### Sistema de Processamento de Template
|
||||
|
||||
#### Ordem de Prioridade de Processamento
|
||||
|
||||
1. **Descrição de PR existente**: **seguir completamente** o conteúdo já descrito
|
||||
2. **Template do projeto**: manter estrutura `.github/PULL_REQUEST_TEMPLATE.md`
|
||||
3. **Template padrão**: quando os acima não existem
|
||||
|
||||
#### Regras de Manutenção de Conteúdo Existente
|
||||
|
||||
- **Não alterar nem um caractere**: conteúdo já descrito
|
||||
- **Complementar apenas seções vazias**: preencher partes de placeholder com conteúdo das mudanças
|
||||
- **Manter comentários funcionais**: manter `<!-- Copilot review rule -->`, etc.
|
||||
- **Manter comentários HTML**: manter completamente `<!-- ... -->`
|
||||
- **Manter linhas separadoras**: manter estruturas como `---`
|
||||
|
||||
#### Método para Manutenção de Comentários HTML
|
||||
|
||||
**Importante**: O GitHub CLI (`gh pr edit`) faz escape automático de comentários HTML, podendo resultar em strings inválidas como `EOF < /dev/null` durante o processamento do shell.
|
||||
|
||||
**Soluções fundamentais**:
|
||||
|
||||
1. **Usar opção --field da GitHub API**: manter comentários HTML com processamento de escape adequado
|
||||
2. **Simplificar processamento de template**: evitar processamento complexo de pipe e redirecionamento
|
||||
3. **Abordagem de manutenção completa**: abolir processamento de remoção de comentários HTML e manter template completamente
|
||||
|
||||
### Resposta a Comentários de Revisão
|
||||
|
||||
```bash
|
||||
# Re-commit após mudanças
|
||||
git add .
|
||||
git commit -m "fix: correções baseadas no feedback da revisão"
|
||||
git push
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
#### Importância da Manutenção de Comentários HTML
|
||||
|
||||
- **Limitações do GitHub CLI**: `gh pr edit` faz escape de comentários HTML, mistura strings inválidas
|
||||
- **Solução fundamental**: processamento de escape adequado com opção `--field` da GitHub API
|
||||
- **Manutenção completa do template**: abolir processamento de remoção de comentários HTML e manter estrutura completamente
|
||||
|
||||
#### Restrições da Automação
|
||||
|
||||
- **Proibição de novos rótulos**: não é possível criar rótulos fora da definição `.github/labels.yml`
|
||||
- **Máximo 3 rótulos**: limite superior da seleção automática
|
||||
- **Prioridade do conteúdo existente**: não alterar absolutamente nada do conteúdo escrito manualmente
|
||||
|
||||
#### Melhoria Gradual da Qualidade
|
||||
|
||||
- **Draft obrigatório**: todos os PRs iniciam como Draft
|
||||
- **Confirmação do CI**: confirmar estado com `gh pr checks`
|
||||
- **Transição para Ready**: `gh pr ready` após confirmação da qualidade
|
||||
- **Conformidade completa com template**: manter estrutura específica do projeto
|
||||
143
commands/pr-feedback.md
Normal file
143
commands/pr-feedback.md
Normal file
@@ -0,0 +1,143 @@
|
||||
## PR Feedback
|
||||
|
||||
Responde eficientemente aos comentários de review de Pull Request e busca resolução fundamental através da abordagem de 3 etapas para análise de erros.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Obtenção e análise de comentários de review
|
||||
gh pr view --comments
|
||||
"Classifique os comentários de review por prioridade e crie um plano de resposta"
|
||||
|
||||
# Análise detalhada de comentários relacionados a erros
|
||||
gh pr checks
|
||||
"Analise erros de CI com abordagem de 3 etapas e identifique a causa raiz"
|
||||
|
||||
# Verificação de qualidade após conclusão da correção
|
||||
npm test && npm run lint
|
||||
"A correção foi concluída, então verifique testes de regressão e qualidade do código"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Execução de classificação de comentários
|
||||
gh pr view 123 --comments | head -20
|
||||
"Classifique os comentários de review em must/imo/nits/q e determine a ordem de resposta"
|
||||
|
||||
# Coleta de informações de erro
|
||||
npm run build 2>&1 | tee error.log
|
||||
"Identifique a causa raiz do erro de build e proponha métodos adequados de correção"
|
||||
|
||||
# Verificação de implementação de correção
|
||||
git diff HEAD~1
|
||||
"Avalie se esta correção resolve adequadamente os pontos apontados no review"
|
||||
```
|
||||
|
||||
### Sistema de Classificação de Comentários
|
||||
|
||||
```text
|
||||
🔴 must: Correção obrigatória
|
||||
├─ Problemas de segurança
|
||||
├─ Bugs funcionais
|
||||
├─ Violação de princípios de design
|
||||
└─ Violação de convenções
|
||||
|
||||
🟡 imo: Propostas de melhoria
|
||||
├─ Métodos de implementação melhores
|
||||
├─ Melhoria de performance
|
||||
├─ Melhoria de legibilidade
|
||||
└─ Propostas de refatoração
|
||||
|
||||
🟢 nits: Pontos menores
|
||||
├─ Correção de typos
|
||||
├─ Ajuste de indentação
|
||||
├─ Adição de comentários
|
||||
└─ Pequenos ajustes de nomenclatura
|
||||
|
||||
🔵 q: Perguntas e confirmações
|
||||
├─ Confirmação de intenção de implementação
|
||||
├─ Esclarecimento de especificações
|
||||
├─ Contexto de decisões de design
|
||||
└─ Consideração de alternativas
|
||||
```
|
||||
|
||||
### Abordagem de 3 Etapas para Análise de Erros
|
||||
|
||||
#### Etapa 1: Coleta de Informações
|
||||
|
||||
**Execução obrigatória**
|
||||
|
||||
- Obtenção completa de mensagens de erro
|
||||
- Verificação de stack trace
|
||||
- Identificação de condições de reprodução
|
||||
|
||||
**Execução recomendada**
|
||||
|
||||
- Coleta de informações ambientais
|
||||
- Histórico de mudanças recentes
|
||||
- Verificação de logs relacionados
|
||||
|
||||
#### Etapa 2: Análise da Causa Raiz
|
||||
|
||||
- Aplicação da análise 5 Whys
|
||||
- Rastreamento de dependências
|
||||
- Verificação de diferenças ambientais
|
||||
- Criação de código de reprodução mínima
|
||||
|
||||
#### Etapa 3: Implementação de Soluções
|
||||
|
||||
- Tratamento imediato (hotfix)
|
||||
- Solução fundamental (correção essencial)
|
||||
- Medidas preventivas (prevenção de reincidência)
|
||||
|
||||
### Fluxo de Resposta
|
||||
|
||||
1. **Análise de comentários**: Classificação por prioridade
|
||||
2. **Plano de correção**: Determinação da ordem de resposta
|
||||
3. **Correção por etapas**: Critical → High → Medium → Low
|
||||
4. **Verificação de qualidade**: Teste, lint, build
|
||||
5. **Relatório de progresso**: Explicação específica do conteúdo das correções
|
||||
|
||||
### Verificação Após Correção
|
||||
|
||||
```bash
|
||||
# Verificação básica
|
||||
npm test
|
||||
npm run lint
|
||||
npm run build
|
||||
|
||||
# Teste de regressão
|
||||
npm run test:e2e
|
||||
|
||||
# Qualidade do código
|
||||
npm run test:coverage
|
||||
```
|
||||
|
||||
### Templates de Resposta
|
||||
|
||||
**Relatório de Conclusão de Correção**
|
||||
|
||||
```markdown
|
||||
@reviewer Obrigado pelo apontamento.
|
||||
Correção concluída:
|
||||
|
||||
- [Conteúdo específico da correção]
|
||||
- [Resultado do teste]
|
||||
- [Método de verificação]
|
||||
```
|
||||
|
||||
**Explicação de Decisão Técnica**
|
||||
|
||||
```markdown
|
||||
Contexto da implementação: [motivo]
|
||||
Alternativas consideradas: [opções e base de julgamento]
|
||||
Vantagens da solução adotada: [méritos]
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Conformidade com prioridades**: Responder na ordem Critical → High → Medium → Low
|
||||
- **Teste primeiro**: Confirmar teste de regressão antes da correção
|
||||
- **Relatório claro**: Descrever especificamente conteúdo da correção e método de verificação
|
||||
- **Diálogo construtivo**: Comunicação cortês baseada em fundamentos técnicos
|
||||
78
commands/pr-issue.md
Normal file
78
commands/pr-issue.md
Normal file
@@ -0,0 +1,78 @@
|
||||
## Issue List
|
||||
|
||||
Exibe a lista de Issues abertas do repositório atual com priorização.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Solicitar ao Claude
|
||||
"Exibir lista de Issues abertas com priorização"
|
||||
```
|
||||
|
||||
### Exemplo básico
|
||||
|
||||
```bash
|
||||
# Obtém informações do repositório
|
||||
gh repo view --json nameWithOwner | jq -r '.nameWithOwner'
|
||||
|
||||
# Obtém informações de Issues abertas e solicita ao Claude
|
||||
gh issue list --state open --json number,title,author,createdAt,updatedAt,labels,assignees,comments --limit 30
|
||||
|
||||
"Organize as Issues acima por prioridade e exiba incluindo um resumo de 2 linhas para cada Issue. Gere a URL usando o nome do repositório obtido acima"
|
||||
```
|
||||
|
||||
### Formato de exibição
|
||||
|
||||
```text
|
||||
Lista de Issues Abertas (ordenadas por prioridade)
|
||||
|
||||
### Alta Prioridade
|
||||
#número Título [rótulo] | autor | tempo decorrido desde abertura | número de comentários | responsável
|
||||
├─ 1ª linha do resumo
|
||||
└─ 2ª linha do resumo
|
||||
https://github.com/owner/repo/issues/número
|
||||
|
||||
### Prioridade Média
|
||||
(mesmo formato)
|
||||
|
||||
### Baixa Prioridade
|
||||
(mesmo formato)
|
||||
```
|
||||
|
||||
### Critérios de determinação de prioridade
|
||||
|
||||
**Alta Prioridade**
|
||||
|
||||
- Issues com rótulo `bug`
|
||||
- Issues com rótulo `critical` ou `urgent`
|
||||
- Issues com rótulo `security`
|
||||
|
||||
**Prioridade Média**
|
||||
|
||||
- Issues com rótulo `enhancement`
|
||||
- Issues com rótulo `feature`
|
||||
- Issues com responsável definido
|
||||
|
||||
**Baixa Prioridade**
|
||||
|
||||
- Issues com rótulo `documentation`
|
||||
- Issues com rótulo `good first issue`
|
||||
- Issues com rótulo `wontfix` ou `duplicate`
|
||||
|
||||
### Filtragem por rótulos
|
||||
|
||||
```bash
|
||||
# Obtém apenas Issues com rótulo específico
|
||||
gh issue list --state open --label "bug" --json number,title,author,createdAt,labels,comments --limit 30
|
||||
|
||||
# Filtragem com múltiplos rótulos (condição AND)
|
||||
gh issue list --state open --label "bug,high-priority" --json number,title,author,createdAt,labels,comments --limit 30
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- Requer GitHub CLI (`gh`)
|
||||
- Exibe apenas Issues no estado aberto
|
||||
- Exibe máximo de 30 Issues
|
||||
- Tempo decorrido é desde quando a Issue foi aberta
|
||||
- URL da Issue é gerada automaticamente a partir do nome real do repositório
|
||||
66
commands/pr-list.md
Normal file
66
commands/pr-list.md
Normal file
@@ -0,0 +1,66 @@
|
||||
## PR List
|
||||
|
||||
Exibe a lista de PRs abertos do repositório atual com priorização.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Solicitar ao Claude
|
||||
"Exibir lista de PRs abertos com priorização"
|
||||
```
|
||||
|
||||
### Exemplo básico
|
||||
|
||||
```bash
|
||||
# Obtém informações do repositório
|
||||
gh repo view --json nameWithOwner | jq -r '.nameWithOwner'
|
||||
|
||||
# Obtém informações de PRs abertos e solicita ao Claude
|
||||
gh pr list --state open --draft=false --json number,title,author,createdAt,additions,deletions,reviews --limit 30
|
||||
|
||||
"Organize os PRs acima por prioridade e exiba incluindo um resumo de 2 linhas para cada PR. Gere a URL usando o nome do repositório obtido acima"
|
||||
```
|
||||
|
||||
### Formato de exibição
|
||||
|
||||
```text
|
||||
Lista de PRs Abertos (ordenados por prioridade)
|
||||
|
||||
### Alta Prioridade
|
||||
#número Título [Draft/DNM] | autor | tempo decorrido desde abertura | número de Approved | +adições/-remoções
|
||||
├─ 1ª linha do resumo
|
||||
└─ 2ª linha do resumo
|
||||
https://github.com/owner/repo/pull/número
|
||||
|
||||
### Prioridade Média
|
||||
(mesmo formato)
|
||||
|
||||
### Baixa Prioridade
|
||||
(mesmo formato)
|
||||
```
|
||||
|
||||
### Critérios de determinação de prioridade
|
||||
|
||||
**Alta Prioridade**
|
||||
|
||||
- `fix:` Correção de bug
|
||||
- `release:` Trabalho de release
|
||||
|
||||
**Prioridade Média**
|
||||
|
||||
- `feat:` Nova funcionalidade
|
||||
- `update:` Melhoria de funcionalidade
|
||||
- Outros PRs normais
|
||||
|
||||
**Baixa Prioridade**
|
||||
|
||||
- PRs contendo DO NOT MERGE
|
||||
- Draft com PRs de `test:`, `build:`, `perf:`
|
||||
|
||||
### Observações
|
||||
|
||||
- Requer GitHub CLI (`gh`)
|
||||
- Exibe apenas PRs no estado aberto (exclui Draft)
|
||||
- Exibe máximo de 30 PRs
|
||||
- Tempo decorrido é desde quando o PR foi aberto
|
||||
- URL do PR é gerada automaticamente a partir do nome real do repositório
|
||||
173
commands/pr-review.md
Normal file
173
commands/pr-review.md
Normal file
@@ -0,0 +1,173 @@
|
||||
## PR Review
|
||||
|
||||
Revisão sistemática de Pull Request para garantir qualidade do código e sanidade da arquitetura.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Revisão abrangente de PR
|
||||
gh pr view 123 --comments
|
||||
"Revise sistematicamente este PR e forneça feedback dos pontos de vista de qualidade de código, segurança e arquitetura"
|
||||
|
||||
# Revisão focada em segurança
|
||||
gh pr diff 123
|
||||
"Revise com foco em riscos de segurança e vulnerabilidades"
|
||||
|
||||
# Revisão do ponto de vista da arquitetura
|
||||
gh pr checkout 123 && find . -name "*.js" | head -10
|
||||
"Avalie a arquitetura dos pontos de vista de separação de camadas, dependências e princípios SOLID"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Avaliação numérica da qualidade do código
|
||||
find . -name "*.js" -exec wc -l {} + | sort -rn | head -5
|
||||
"Avalie a complexidade do código, tamanho das funções e grau de duplicação e aponte pontos de melhoria"
|
||||
|
||||
# Verificação de vulnerabilidades de segurança
|
||||
grep -r "password\|secret\|token" . --include="*.js" | head -10
|
||||
"Verifique riscos de vazamento de informações confidenciais, hardcoding e bypass de autenticação"
|
||||
|
||||
# Detecção de violações de arquitetura
|
||||
grep -r "import.*from.*\.\./\.\." . --include="*.js"
|
||||
"Avalie problemas de violação de camadas, dependências circulares e acoplamento"
|
||||
```
|
||||
|
||||
### Sistema de Classificação de Comentários
|
||||
|
||||
```text
|
||||
🔴 critical.must: Problemas críticos
|
||||
├─ Vulnerabilidades de segurança
|
||||
├─ Problemas de integridade de dados
|
||||
└─ Risco de falha do sistema
|
||||
|
||||
🟡 high.imo: Melhorias de alta prioridade
|
||||
├─ Risco de mau funcionamento
|
||||
├─ Problemas de performance
|
||||
└─ Grande redução da manutenibilidade
|
||||
|
||||
🟢 medium.imo: Melhorias de prioridade média
|
||||
├─ Melhoria da legibilidade
|
||||
├─ Melhoria da estrutura do código
|
||||
└─ Melhoria da qualidade dos testes
|
||||
|
||||
🟢 low.nits: Observações menores
|
||||
├─ Padronização de estilo
|
||||
├─ Correção de typos
|
||||
└─ Adição de comentários
|
||||
|
||||
🔵 info.q: Perguntas e Fornecimento de informações
|
||||
├─ Confirmação de intenção da implementação
|
||||
├─ Contexto de decisões de design
|
||||
└─ Compartilhamento de melhores práticas
|
||||
```
|
||||
|
||||
### Pontos de Vista da Revisão
|
||||
|
||||
#### 1. Precisão do Código
|
||||
|
||||
- **Erros lógicos**: Valores limite, verificação Null, tratamento de exceções
|
||||
- **Integridade de dados**: Segurança de tipo, validação
|
||||
- **Tratamento de erros**: Abrangência, processamento adequado
|
||||
|
||||
#### 2. Segurança
|
||||
|
||||
- **Autenticação e Autorização**: Verificação adequada, gestão de permissões
|
||||
- **Validação de entrada**: Contramedidas SQL injection, XSS
|
||||
- **Informações confidenciais**: Proibição de output em logs, criptografia
|
||||
|
||||
#### 3. Performance
|
||||
|
||||
- **Algoritmos**: Complexidade temporal, eficiência de memória
|
||||
- **Banco de dados**: Consultas N+1, otimização de índices
|
||||
- **Recursos**: Vazamentos de memória, utilização de cache
|
||||
|
||||
#### 4. Arquitetura
|
||||
|
||||
- **Separação de camadas**: Direção de dependência, separação adequada
|
||||
- **Grau de acoplamento**: Baixo acoplamento, utilização de interfaces
|
||||
- **Princípios SOLID**: Responsabilidade única, aberto-fechado, inversão de dependência
|
||||
|
||||
### Fluxo de Revisão
|
||||
|
||||
1. **Verificação prévia**: Informações do PR, diferenças de mudanças, Issues relacionadas
|
||||
2. **Verificação sistemática**: Segurança → Precisão → Performance → Arquitetura
|
||||
3. **Feedback construtivo**: Propostas de melhoria específicas e exemplos de código
|
||||
4. **Follow-up**: Confirmação de correções, estado do CI, aprovação final
|
||||
|
||||
### Exemplos de Comentários Eficazes
|
||||
|
||||
#### Problemas de Segurança
|
||||
|
||||
**Formato:**
|
||||
|
||||
```text
|
||||
**critical.must.** [Descrição do problema]
|
||||
|
||||
[Proposta de correção específica]
|
||||
|
||||
[Explicação da necessidade]
|
||||
```
|
||||
|
||||
**Exemplo:**
|
||||
|
||||
```text
|
||||
**critical.must.** Senha está sendo armazenada em texto plano
|
||||
|
||||
// Proposta de correção
|
||||
const bcrypt = require('bcrypt');
|
||||
const hashedPassword = await bcrypt.hash(password, 12);
|
||||
|
||||
Hashing é obrigatório para prevenir riscos de segurança.
|
||||
```
|
||||
|
||||
#### Melhoria de Performance
|
||||
|
||||
**Formato:**
|
||||
|
||||
```text
|
||||
**high.imo.** [Descrição do problema]
|
||||
|
||||
[Proposta de melhoria específica]
|
||||
|
||||
[Explicação dos benefícios]
|
||||
```
|
||||
|
||||
**Exemplo:**
|
||||
|
||||
```text
|
||||
**high.imo.** Problema de consulta N+1 irá ocorrer
|
||||
|
||||
// Proposta de melhoria: Eager Loading
|
||||
const users = await User.findAll({ include: [Post] });
|
||||
|
||||
Pode reduzir drasticamente o número de consultas.
|
||||
```
|
||||
|
||||
#### Violação de Arquitetura
|
||||
|
||||
**Formato:**
|
||||
|
||||
```text
|
||||
**high.must.** [Descrição da violação]
|
||||
|
||||
[Explicação do problema arquitetural]
|
||||
[Proposta de solução]
|
||||
```
|
||||
|
||||
**Exemplo:**
|
||||
|
||||
```text
|
||||
**high.must.** Violação de camada está ocorrendo
|
||||
|
||||
A camada de domínio está dependendo diretamente da camada de infraestrutura.
|
||||
Introduza interfaces com o princípio de inversão de dependência.
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Tom construtivo**: Comunicação colaborativa, não agressiva
|
||||
- **Propostas específicas**: Apresentar soluções, não apenas apontar problemas
|
||||
- **Priorização**: Responder na ordem Critical → High → Medium → Low
|
||||
- **Melhoria contínua**: Transformar resultados de revisão em base de conhecimento
|
||||
305
commands/refactor.md
Normal file
305
commands/refactor.md
Normal file
@@ -0,0 +1,305 @@
|
||||
## Refactor
|
||||
|
||||
Realiza refatoração segura e gradual de código, avaliando quantitativamente a aderência aos princípios SOLID. Visualiza dívida técnica e clarifica as prioridades de melhoria.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Identificação de código complexo e planejamento de refatoração
|
||||
find . -name "*.js" -exec wc -l {} + | sort -rn | head -10
|
||||
"Refatorar arquivos grandes para reduzir complexidade"
|
||||
|
||||
# Detecção e unificação de código duplicado
|
||||
grep -r "function processUser" . --include="*.js"
|
||||
"Unificar funções duplicadas com Extract Method"
|
||||
|
||||
# Detecção de violações dos princípios SOLID
|
||||
grep -r "class.*Service" . --include="*.js" | head -10
|
||||
"Avaliar se essas classes seguem o princípio da responsabilidade única"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Detecção de métodos longos
|
||||
grep -A 50 "function" src/*.js | grep -B 50 -A 50 "return" | wc -l
|
||||
"Dividir métodos com mais de 50 linhas usando Extract Method"
|
||||
|
||||
# Complexidade de ramificação condicional
|
||||
grep -r "if.*if.*if" . --include="*.js"
|
||||
"Melhorar condicionais aninhadas com padrão Strategy"
|
||||
|
||||
# Detecção de code smells
|
||||
grep -r "TODO\|FIXME\|HACK" . --exclude-dir=node_modules
|
||||
"Resolver comentários que se tornaram dívida técnica"
|
||||
```
|
||||
|
||||
### Técnicas de Refatoração
|
||||
|
||||
#### Extract Method (Extração de Método)
|
||||
|
||||
```javascript
|
||||
// Antes: método extenso
|
||||
function processOrder(order) {
|
||||
// 50 linhas de processamento complexo
|
||||
}
|
||||
|
||||
// Depois: separação de responsabilidades
|
||||
function processOrder(order) {
|
||||
validateOrder(order);
|
||||
calculateTotal(order);
|
||||
saveOrder(order);
|
||||
}
|
||||
```
|
||||
|
||||
#### Replace Conditional with Polymorphism
|
||||
|
||||
```javascript
|
||||
// Antes: declaração switch
|
||||
function getPrice(user) {
|
||||
switch (user.type) {
|
||||
case "premium":
|
||||
return basePrice * 0.8;
|
||||
case "regular":
|
||||
return basePrice;
|
||||
}
|
||||
}
|
||||
|
||||
// Depois: padrão Strategy
|
||||
class PremiumPricing {
|
||||
calculate(basePrice) {
|
||||
return basePrice * 0.8;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Pontuação dos Princípios SOLID (0-100 pontos)
|
||||
|
||||
#### Critérios de Avaliação e Pontuação
|
||||
|
||||
```text
|
||||
S - Single Responsibility (20 pontos)
|
||||
├─ Número de responsabilidades da classe: 1 (20 pts) | 2 (15 pts) | 3 (10 pts) | 4+ (5 pts)
|
||||
├─ Número de métodos: <7 (+5 pts) | 7-15 (+3 pts) | >15 (0 pts)
|
||||
├─ Clareza do motivo de mudança: Clara (+5 pts) | Ambígua (0 pts)
|
||||
└─ Exemplo: UserService(autenticação+processamento de dados) = 10 pontos
|
||||
|
||||
O - Open/Closed (20 pontos)
|
||||
├─ Pontos de extensão: Strategy/Template Method (20 pts) | Apenas herança (10 pts) | Nenhum (5 pts)
|
||||
├─ Mudanças no código existente ao adicionar funcionalidades: Desnecessárias (+5 pts) | Mínimas (+3 pts) | Necessárias (0 pts)
|
||||
├─ Uso de interfaces: Apropriado (+5 pts) | Parcial (+3 pts) | Nenhum (0 pts)
|
||||
└─ Exemplo: PaymentProcessor(Strategy) = 20 pontos
|
||||
|
||||
L - Liskov Substitution (20 pontos)
|
||||
├─ Aderência ao contrato das classes derivadas: Completa (20 pts) | Parcial (10 pts) | Violação (0 pts)
|
||||
├─ Fortalecimento de pré-condições: Nenhum (+5 pts) | Presente (-5 pts)
|
||||
├─ Enfraquecimento de pós-condições: Nenhum (+5 pts) | Presente (-5 pts)
|
||||
└─ Exemplo: Square extends Rectangle = 0 pontos (violação)
|
||||
|
||||
I - Interface Segregation (20 pontos)
|
||||
├─ Tamanho da interface: 1-3 métodos (20 pts) | 4-7 (15 pts) | 8+ (5 pts)
|
||||
├─ Implementação de métodos não utilizados: Nenhum (+5 pts) | 1-2 (+2 pts) | 3+ (0 pts)
|
||||
├─ Clareza do papel: Papel único (+5 pts) | Múltiplos papéis (0 pts)
|
||||
└─ Exemplo: Separação Readable/Writable = 20 pontos
|
||||
|
||||
D - Dependency Inversion (20 pontos)
|
||||
├─ Direção da dependência: Apenas abstração (20 pts) | Mista (10 pts) | Apenas concreta (5 pts)
|
||||
├─ Uso de DI: Constructor Injection (+5 pts) | Setter (+3 pts) | Nenhum (0 pts)
|
||||
├─ Testabilidade: Mock possível (+5 pts) | Difícil (0 pts)
|
||||
└─ Exemplo: Repository Pattern = 20 pontos
|
||||
|
||||
Pontuação Total = S + O + L + I + D
|
||||
├─ 90-100 pontos: Excellent (Aderência completa ao SOLID)
|
||||
├─ 70-89 pontos: Good (Pequena margem para melhoria)
|
||||
├─ 50-69 pontos: Fair (Refatoração recomendada)
|
||||
├─ 30-49 pontos: Poor (Melhoria em grande escala necessária)
|
||||
└─ 0-29 pontos: Critical (Revisão de design obrigatória)
|
||||
```
|
||||
|
||||
### Quantificação da Dívida Técnica
|
||||
|
||||
#### Fórmula de Cálculo da Dívida
|
||||
|
||||
```text
|
||||
Dívida Técnica (tempo) = Pontuação de Complexidade × Escopo de Impacto × Dificuldade de Correção
|
||||
|
||||
Pontuação de Complexidade:
|
||||
├─ Complexidade ciclomática: 1-5(baixa) | 6-10(média) | 11-20(alta) | 21+(perigosa)
|
||||
├─ Complexidade cognitiva: Profundidade de aninhamento × Número de ramificações condicionais
|
||||
├─ Linhas de código: <50(1 pt) | 50-200(2 pts) | 200-500(3 pts) | 500+(5 pts)
|
||||
└─ Taxa de duplicação: 0-10%(1 pt) | 10-30%(2 pts) | 30-50%(3 pts) | 50%+(5 pts)
|
||||
|
||||
Escopo de Impacto:
|
||||
├─ Número de módulos dependentes: Dependência direta + Dependência indireta × 0.5
|
||||
├─ Frequência de uso: Número de chamadas API/dia
|
||||
├─ Importância do negócio: Critical(×3) | High(×2) | Medium(×1) | Low(×0.5)
|
||||
└─ Conhecimento da equipe: 1 pessoa entende(×3) | 2-3 pessoas(×2) | 4+ pessoas(×1)
|
||||
|
||||
Dificuldade de Correção:
|
||||
├─ Cobertura de testes: 0%(×3) | <50%(×2) | 50-80%(×1.5) | >80%(×1)
|
||||
├─ Documentação: Nenhuma(×2) | Insuficiente(×1.5) | Suficiente(×1)
|
||||
├─ Dependências: Acoplamento forte(×3) | Moderado(×2) | Fraco(×1)
|
||||
└─ Risco de mudança: Breaking Change(×3) | Consideração de compatibilidade(×2) | Seguro(×1)
|
||||
|
||||
Conversão de Custo:
|
||||
├─ Custo de tempo: Tempo de dívida × Salário por hora do desenvolvedor
|
||||
├─ Perda de oportunidade: Dias de atraso no desenvolvimento de novas funcionalidades × Impacto na receita diária
|
||||
├─ Custo de qualidade: Probabilidade de ocorrência de bug × Custo de correção × Frequência de ocorrência
|
||||
└─ Custo total: Tempo + Perda de oportunidade + Custo de qualidade
|
||||
```
|
||||
|
||||
#### Matriz de Prioridades
|
||||
|
||||
| Prioridade | Impacto | Custo de Correção | Prazo de Resposta | Exemplo Concreto | Ação Recomendada |
|
||||
| ----------------------------------- | ------- | ----------------- | ------------------ | ----------------------------------------------------------------------- | -------------------------------------------------------------- |
|
||||
| **Critical (Resposta Imediata)** | Alto | Baixo | Dentro de 1 semana | God Object, dependências circulares | Iniciar refatoração imediatamente |
|
||||
| **Important (Resposta Planejada)** | Alto | Alto | Dentro de 1 mês | Separação de responsabilidades em grande escala, mudanças arquiteturais | Incluir no planejamento de sprint |
|
||||
| **Watch (Objeto de Monitoramento)** | Baixo | Alto | Dentro de 3 meses | Processamento interno de alta complexidade | Monitoramento de métricas, resposta quando houver deterioração |
|
||||
| **Acceptable (Faixa Aceitável)** | Baixo | Baixo | Não necessário | Code smells menores | Resposta através de refatoração normal |
|
||||
|
||||
### Procedimento de Refatoração
|
||||
|
||||
1. **Análise e Medição Atual**
|
||||
- Medição de complexidade (ciclomática ・cognitiva)
|
||||
- Cálculo de pontuação SOLID (0-100 pontos)
|
||||
- Quantificação de dívida técnica (tempo/custo)
|
||||
- Criação de matriz de prioridades
|
||||
|
||||
2. **Execução Gradual**
|
||||
- Pequenos passos (unidades de 15-30 minutos)
|
||||
- Execução de testes após cada mudança
|
||||
- Commits frequentes
|
||||
- Medição contínua de pontuação SOLID
|
||||
|
||||
3. **Confirmação de Qualidade**
|
||||
- Manutenção de cobertura de testes
|
||||
- Medição de desempenho
|
||||
- Confirmação de redução de dívida técnica
|
||||
- Revisão de código
|
||||
|
||||
### Code Smells Comuns e Pontuação de Dívida
|
||||
|
||||
| Code Smell | Critério de Detecção | Pontuação de Dívida | Técnica de Melhoria |
|
||||
| ----------------------- | -------------------------------------- | ------------------- | ---------------------------- |
|
||||
| **God Object** | Responsabilidades >3, métodos >20 | Alta (15-20h) | Extract Class, aplicação SRP |
|
||||
| **Long Method** | Linhas >50, complexidade >10 | Média (5-10h) | Extract Method |
|
||||
| **Duplicate Code** | Taxa de duplicação >30% | Alta (10-15h) | Extract Method/Class |
|
||||
| **Large Class** | Linhas >300, métodos >15 | Alta (10-20h) | Extract Class |
|
||||
| **Long Parameter List** | Parâmetros >4 | Baixa (2-5h) | Parameter Object |
|
||||
| **Feature Envy** | Referências a outras classes >5 | Média (5-10h) | Move Method |
|
||||
| **Data Clumps** | Repetição do mesmo grupo de argumentos | Baixa (3-5h) | Extract Class |
|
||||
| **Primitive Obsession** | Uso excessivo de tipos primitivos | Média (5-8h) | Replace with Object |
|
||||
| **Switch Statements** | case >5 | Média (5-10h) | Strategy Pattern |
|
||||
| **Shotgun Surgery** | Locais de impacto na mudança >3 | Alta (10-15h) | Move Method/Field |
|
||||
|
||||
### Exemplo Prático: Avaliação de Pontuação SOLID
|
||||
|
||||
```javascript
|
||||
// Objeto de avaliação: classe UserService
|
||||
class UserService {
|
||||
constructor(db, cache, logger, emailService) { // 4 dependências
|
||||
this.db = db;
|
||||
this.cache = cache;
|
||||
this.logger = logger;
|
||||
this.emailService = emailService;
|
||||
}
|
||||
|
||||
// Responsabilidade 1: autenticação
|
||||
authenticate(username, password) { /* ... */ }
|
||||
refreshToken(token) { /* ... */ }
|
||||
|
||||
// Responsabilidade 2: gerenciamento de usuário
|
||||
createUser(data) { /* ... */ }
|
||||
updateUser(id, data) { /* ... */ }
|
||||
deleteUser(id) { /* ... */ }
|
||||
|
||||
// Responsabilidade 3: notificação
|
||||
sendWelcomeEmail(user) { /* ... */ }
|
||||
sendPasswordReset(email) { /* ... */ }
|
||||
}
|
||||
|
||||
// Resultado da avaliação de pontuação SOLID
|
||||
S: 10 pontos (3 responsabilidades: autenticação, CRUD, notificação)
|
||||
O: 5 pontos (sem pontos de extensão, implementação direta)
|
||||
L: 15 pontos (sem herança, não aplicável)
|
||||
I: 10 pontos (interface não segregada)
|
||||
D: 10 pontos (dependência de classe concreta)
|
||||
Total: 50 pontos (Fair - refatoração recomendada)
|
||||
|
||||
// Dívida técnica
|
||||
Complexidade: 15 (7 métodos, 3 responsabilidades)
|
||||
Escopo de impacto: 8 (autenticação usada em todas as funcionalidades)
|
||||
Dificuldade de correção: 2 (testes existentes, documentação insuficiente)
|
||||
Tempo de dívida: 15 × 8 × 2 = 240 horas
|
||||
Prioridade: Critical (sistema de autenticação requer resposta imediata)
|
||||
```
|
||||
|
||||
### Exemplo de Implementação Após Melhoria
|
||||
|
||||
```javascript
|
||||
// Após aplicação dos princípios SOLID (Pontuação: 90 pontos)
|
||||
|
||||
// S: responsabilidade única (20 pontos)
|
||||
class AuthenticationService {
|
||||
authenticate(credentials) { /* ... */ }
|
||||
refreshToken(token) { /* ... */ }
|
||||
}
|
||||
|
||||
// O: aberto/fechado (20 pontos)
|
||||
class UserRepository {
|
||||
constructor(storage) { // Strategy Pattern
|
||||
this.storage = storage;
|
||||
}
|
||||
save(user) { return this.storage.save(user); }
|
||||
}
|
||||
|
||||
// I: segregação de interface (20 pontos)
|
||||
interface Readable {
|
||||
find(id);
|
||||
findAll();
|
||||
}
|
||||
interface Writable {
|
||||
save(entity);
|
||||
delete(id);
|
||||
}
|
||||
|
||||
// D: inversão de dependência (20 pontos)
|
||||
class UserService {
|
||||
constructor(
|
||||
private auth: IAuthService,
|
||||
private repo: IUserRepository,
|
||||
private notifier: INotificationService
|
||||
) {}
|
||||
}
|
||||
|
||||
// Redução de dívida: 240 horas → 20 horas (redução de 92%)
|
||||
```
|
||||
|
||||
### Suporte de Automação
|
||||
|
||||
```bash
|
||||
# Medição de pontuação SOLID
|
||||
npx solid-analyzer src/ --output report.json
|
||||
|
||||
# Análise de complexidade
|
||||
npx complexity-report src/ --format json
|
||||
sonar-scanner -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
|
||||
|
||||
# Visualização de dívida técnica
|
||||
npx code-debt-analyzer --config .debt.yml
|
||||
|
||||
# Formatação de código
|
||||
npm run lint:fix
|
||||
prettier --write src/
|
||||
|
||||
# Execução de testes e cobertura
|
||||
npm test -- --coverage
|
||||
npm run test:mutation # teste de mutação
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- **Proibição de mudança funcional**: Não alterar comportamento externo
|
||||
- **Test First**: Adicionar testes antes da refatoração
|
||||
- **Abordagem gradual**: Não fazer grandes mudanças de uma só vez
|
||||
- **Verificação contínua**: Execução de testes em cada etapa
|
||||
571
commands/role-debate.md
Normal file
571
commands/role-debate.md
Normal file
@@ -0,0 +1,571 @@
|
||||
## Role Debate
|
||||
|
||||
Comando onde diferentes papéis especializados debatem, consideram trade-offs e derivam soluções ótimas.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/role-debate <papel 1>,<papel 2> [tópico]
|
||||
/role-debate <papel 1>,<papel 2>,<papel 3> [tópico]
|
||||
```
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# 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"
|
||||
```
|
||||
|
||||
### Princípios básicos do debate
|
||||
|
||||
#### Fundamentos do debate construtivo
|
||||
|
||||
- **Respeito mútuo**: Respeitar a especialização e perspectiva de outros papéis
|
||||
- **Baseado em fatos**: Debate baseado em dados e evidências, não em objeções emocionais
|
||||
- **Orientado à solução**: Buscar melhores soluções, não crítica pela crítica
|
||||
- **Foco na implementação**: Propostas considerando viabilidade, não apenas teorias ideais
|
||||
|
||||
#### Requisitos qualitativos da argumentação
|
||||
|
||||
- **Documentação oficial**: Referência a padrões, diretrizes e documentação oficial
|
||||
- **Casos de prova**: Citação específica de casos de sucesso e fracasso
|
||||
- **Avaliação quantitativa**: Comparação por números e indicadores sempre que possível
|
||||
- **Consideração temporal**: Avaliação de impactos de curto, médio e longo prazo
|
||||
|
||||
#### Ética do debate
|
||||
|
||||
- **Honestidade**: Reconhecer também os limites da própria área de especialização
|
||||
- **Abertura**: Flexibilidade para novas informações e perspectivas
|
||||
- **Transparência**: Clarificação de bases de julgamento e condições prévias
|
||||
- **Responsabilidade**: Mencionar também os riscos de implementação das propostas
|
||||
|
||||
### Processo de debate
|
||||
|
||||
### Fase 1: Declaração de posição inicial
|
||||
|
||||
Cada papel expressa opinião independentemente de perspectiva especializada
|
||||
|
||||
- Apresentação de proposta recomendada
|
||||
- Clarificação de padrões e documentos como base
|
||||
- Explicação de riscos e desafios previstos
|
||||
- Definição de indicadores de sucesso
|
||||
|
||||
### Fase 2: Debate mútuo e refutação
|
||||
|
||||
Debate cruzado entre papéis
|
||||
|
||||
- Objeções construtivas às propostas de outros papéis
|
||||
- Apontamento de perspectivas negligenciadas
|
||||
- Clarificação de trade-offs
|
||||
- Apresentação de alternativas
|
||||
|
||||
### Fase 3: Busca de pontos de compromisso
|
||||
|
||||
Busca por soluções implementáveis
|
||||
|
||||
- Avaliação de importância de cada perspectiva
|
||||
- Consideração de soluções Win-Win
|
||||
- Abordagem de implementação em fases
|
||||
- Consideração de medidas de redução de riscos
|
||||
|
||||
### Fase 4: Conclusão integrada
|
||||
|
||||
Determinação de recomendações finais
|
||||
|
||||
- Solução acordada
|
||||
- Roadmap de implementação
|
||||
- Indicadores de sucesso e métodos de medição
|
||||
- Pontos de revisão futura
|
||||
|
||||
### Exemplo de formato de saída
|
||||
|
||||
### Caso de debate entre 2 papéis
|
||||
|
||||
```text
|
||||
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
|
||||
```
|
||||
|
||||
### Caso de debate entre 3 papéis
|
||||
|
||||
```text
|
||||
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"
|
||||
```
|
||||
|
||||
### Padrões de debate eficazes
|
||||
|
||||
### Seleção tecnológica
|
||||
|
||||
```bash
|
||||
/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"
|
||||
```
|
||||
|
||||
### Decisões de design
|
||||
|
||||
```bash
|
||||
/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"
|
||||
```
|
||||
|
||||
### Problemas de trade-off
|
||||
|
||||
```bash
|
||||
/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"
|
||||
```
|
||||
|
||||
### Características de debate por papel
|
||||
|
||||
#### 🔒 Papel Security
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
#### ⚡ Papel Performance
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
#### 🏗️ Papel Architect
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
#### 🎨 Papel Frontend
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
#### 📱 Papel Mobile
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
#### 🔍 Papel Analyzer
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
### Template de condução do debate
|
||||
|
||||
#### Template da Fase 1: Declaração de posição
|
||||
|
||||
```text
|
||||
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]
|
||||
```
|
||||
|
||||
#### Template da Fase 2: Refutação
|
||||
|
||||
```text
|
||||
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]
|
||||
```
|
||||
|
||||
#### Template da Fase 3: Solução integrada
|
||||
|
||||
```text
|
||||
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]
|
||||
```
|
||||
|
||||
### Checklist de qualidade do debate
|
||||
|
||||
#### Qualidade da argumentação
|
||||
|
||||
- [ ] Há referência a documentos/padrões oficiais
|
||||
- [ ] Casos específicos e dados são apresentados
|
||||
- [ ] Suposições e fatos são claramente distinguidos
|
||||
- [ ] Fontes de informação são especificadas
|
||||
|
||||
#### Construtividade do debate
|
||||
|
||||
- [ ] Compreende corretamente a proposta do oponente
|
||||
- [ ] Contra-argumentos lógicos, não emocionais
|
||||
- [ ] Também apresenta propostas alternativas
|
||||
- [ ] Busca possibilidades Win-Win
|
||||
|
||||
#### Viabilidade de implementação
|
||||
|
||||
- [ ] Considera viabilidade técnica
|
||||
- [ ] Estima custos e prazos de implementação
|
||||
- [ ] Considera possibilidade de implementação em fases
|
||||
- [ ] Apresenta medidas de redução de riscos
|
||||
|
||||
#### Integração
|
||||
|
||||
- [ ] Considera impactos em outras áreas
|
||||
- [ ] Busca otimização global
|
||||
- [ ] Inclui perspectiva de longo prazo
|
||||
- [ ] Define indicadores de sucesso mensuráveis
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# 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"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- Debates podem levar tempo (tópicos complexos levam mais tempo)
|
||||
- Com 3 ou mais papéis, o debate pode se dispersar
|
||||
- A decisão final deve ser tomada pelo usuário com base nos resultados do debate
|
||||
- Para problemas de alta urgência, considere primeiro single role ou multi-role
|
||||
276
commands/role-help.md
Normal file
276
commands/role-help.md
Normal file
@@ -0,0 +1,276 @@
|
||||
## Role Help
|
||||
|
||||
Guia de seleção e sistema de ajuda para quando não souber qual papel usar.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/role-help # Guia geral de seleção de papéis
|
||||
/role-help <situação/problema> # Papel recomendado para situação específica
|
||||
/role-help compare <papel 1>,<papel 2> # Comparação de papéis
|
||||
```
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# Orientação geral
|
||||
/role-help
|
||||
→ Exibe lista de papéis disponíveis e suas características
|
||||
|
||||
# Recomendação por situação
|
||||
/role-help "Preocupado com a segurança da API"
|
||||
→ Recomendação do papel security e modo de uso
|
||||
|
||||
# Comparação de papéis
|
||||
/role-help compare frontend,mobile
|
||||
→ Diferenças entre frontend e mobile e como usar cada um
|
||||
```
|
||||
|
||||
### Guia de seleção de papéis por situação
|
||||
|
||||
### Relacionado à segurança
|
||||
|
||||
```text
|
||||
Use o papel security quando:
|
||||
✅ Implementação de login e autenticação
|
||||
✅ Verificação de vulnerabilidades de segurança da API
|
||||
✅ Criptografia de dados e proteção de privacidade
|
||||
✅ Verificação de compliance de segurança
|
||||
✅ Teste de invasão e penetração
|
||||
|
||||
Uso: /role security
|
||||
```
|
||||
|
||||
### 🏗️ Arquitetura e design
|
||||
|
||||
```text
|
||||
Use o papel architect quando:
|
||||
✅ Avaliação do design do sistema geral
|
||||
✅ Decisão entre microsserviços vs monólito
|
||||
✅ Design de banco de dados e seleção tecnológica
|
||||
✅ Considerações de escalabilidade e extensibilidade
|
||||
✅ Avaliação de dívida técnica e planos de melhoria
|
||||
|
||||
Uso: /role architect
|
||||
```
|
||||
|
||||
### ⚡ Problemas de performance
|
||||
|
||||
```text
|
||||
Use o papel performance quando:
|
||||
✅ Aplicação está lenta
|
||||
✅ Otimização de consultas ao banco de dados
|
||||
✅ Melhoria da velocidade de carregamento de páginas web
|
||||
✅ Otimização do uso de memória e CPU
|
||||
✅ Estratégias de scaling e balanceamento de carga
|
||||
|
||||
Uso: /role performance
|
||||
```
|
||||
|
||||
### 🔍 Investigação de causas de problemas
|
||||
|
||||
```text
|
||||
Use o papel analyzer quando:
|
||||
✅ Análise da causa raiz de bugs e erros
|
||||
✅ Investigação de causas de falhas do sistema
|
||||
✅ Análise estrutural de problemas complexos
|
||||
✅ Análise de dados e investigação estatística
|
||||
✅ Esclarecimento de por que este problema ocorreu
|
||||
|
||||
Uso: /role analyzer
|
||||
```
|
||||
|
||||
### 🎨 Frontend e UI/UX
|
||||
|
||||
```text
|
||||
Use o papel frontend quando:
|
||||
✅ Melhoria da interface do usuário
|
||||
✅ Suporte à acessibilidade
|
||||
✅ Design responsivo
|
||||
✅ Melhoria da usabilidade e facilidade de uso
|
||||
✅ Tecnologias gerais de frontend web
|
||||
|
||||
Uso: /role frontend
|
||||
```
|
||||
|
||||
### 📱 Desenvolvimento de aplicativos móveis
|
||||
|
||||
```text
|
||||
Use o papel mobile quando:
|
||||
✅ Otimização de apps iOS e Android
|
||||
✅ Design de UX específico para mobile
|
||||
✅ Otimização de interface touch
|
||||
✅ Suporte offline e funções de sincronização
|
||||
✅ Suporte para App Store e Google Play
|
||||
|
||||
Uso: /role mobile
|
||||
```
|
||||
|
||||
### 👀 Code review e qualidade
|
||||
|
||||
```text
|
||||
Use o papel reviewer quando:
|
||||
✅ Verificação da qualidade do código
|
||||
✅ Avaliação de legibilidade e manutenibilidade
|
||||
✅ Verificação de convenções de codificação
|
||||
✅ Propostas de refatoração
|
||||
✅ Review de PR e commits
|
||||
|
||||
Uso: /role reviewer
|
||||
```
|
||||
|
||||
### 🧪 Testes e garantia de qualidade
|
||||
|
||||
```text
|
||||
Use o papel qa quando:
|
||||
✅ Planejamento de estratégias de teste
|
||||
✅ Avaliação de cobertura de teste
|
||||
✅ Política de implementação de testes automatizados
|
||||
✅ Estratégias de prevenção de bugs e melhoria da qualidade
|
||||
✅ Automação de testes em CI/CD
|
||||
|
||||
Uso: /role qa
|
||||
```
|
||||
|
||||
### Quando múltiplos papéis são necessários
|
||||
|
||||
### 🔄 multi-role (análise paralela)
|
||||
|
||||
```text
|
||||
Use multi-role quando:
|
||||
✅ Quiser avaliação de múltiplas perspectivas especializadas
|
||||
✅ Quiser criar plano de melhoria integrado
|
||||
✅ Quiser comparar avaliações de cada área
|
||||
✅ Quiser organizar contradições e duplicações
|
||||
|
||||
Exemplo: /multi-role security,performance
|
||||
```
|
||||
|
||||
### 🗣️ role-debate (debate)
|
||||
|
||||
```text
|
||||
Use role-debate quando:
|
||||
✅ Há trade-offs entre áreas especializadas
|
||||
✅ Opiniões se dividem na seleção tecnológica
|
||||
✅ Quiser decidir diretrizes de design por debate
|
||||
✅ Quiser ouvir debates de diferentes perspectivas
|
||||
|
||||
Exemplo: /role-debate security,performance
|
||||
```
|
||||
|
||||
### 🤖 smart-review (sugestão automática)
|
||||
|
||||
```text
|
||||
Use smart-review quando:
|
||||
✅ Não souber qual papel usar
|
||||
✅ Quiser conhecer a abordagem ideal para a situação atual
|
||||
✅ Quiser escolher entre múltiplas opções
|
||||
✅ For iniciante e estiver em dúvida
|
||||
|
||||
Exemplo: /smart-review
|
||||
```
|
||||
|
||||
### Tabela de comparação de papéis
|
||||
|
||||
### Relacionados à segurança
|
||||
|
||||
| Papel | Uso principal | Área forte | Área fraca |
|
||||
| -------- | -------------------------------- | ------------------------------------------ | ---------------------------------------- |
|
||||
| security | Vulnerabilidades e contramedidas | Análise de ameaças, design de autenticação | UX, performance |
|
||||
| analyzer | Análise da causa raiz | Análise lógica, coleta de evidências | Medidas preventivas, planejamento futuro |
|
||||
|
||||
### Relacionados ao design
|
||||
|
||||
| Papel | Uso principal | Área forte | Área fraca |
|
||||
| --------- | ------------------- | --------------------------------------------- | ------------------------------------------------ |
|
||||
| architect | Design de sistema | Perspectiva de longo prazo, otimização global | Implementação detalhada, soluções de curto prazo |
|
||||
| reviewer | Qualidade do código | Nível de implementação, manutenibilidade | Requisitos de negócio, UX |
|
||||
|
||||
### Relacionados à performance
|
||||
|
||||
| Papel | Uso principal | Área forte | Área fraca |
|
||||
| ----------- | ----------------------- | ----------------- | ------------------- |
|
||||
| performance | Aceleração e otimização | Medição, gargalos | Segurança, UX |
|
||||
| qa | Garantia de qualidade | Teste, automação | Design, arquitetura |
|
||||
|
||||
### Relacionados à experiência do usuário
|
||||
|
||||
| Papel | Uso principal | Área forte | Área fraca |
|
||||
| -------- | ------------- | ----------------------- | ------------- |
|
||||
| frontend | Web UI/UX | Browser, acessibilidade | Servidor, DB |
|
||||
| mobile | Mobile UX | Touch, suporte offline | Servidor, Web |
|
||||
|
||||
### Fluxograma para quando estiver em dúvida
|
||||
|
||||
```text
|
||||
Qual é a natureza do problema?
|
||||
├─ Relacionado à segurança → security
|
||||
├─ Problema de performance → performance
|
||||
├─ Investigação de bug/falha → analyzer
|
||||
├─ Melhoria de UI/UX → frontend ou mobile
|
||||
├─ Design/arquitetura → architect
|
||||
├─ Qualidade do código → reviewer
|
||||
├─ Relacionado a testes → qa
|
||||
└─ Complexo/composto → smart-review para sugestão
|
||||
|
||||
Abrange múltiplas áreas?
|
||||
├─ Quero análise integrada → multi-role
|
||||
├─ Debate/trade-offs → role-debate
|
||||
└─ Em dúvida sobre decisão → smart-review
|
||||
```
|
||||
|
||||
### Perguntas frequentes
|
||||
|
||||
### Q: Qual a diferença entre frontend e mobile?
|
||||
|
||||
```text
|
||||
A:
|
||||
frontend: Foco em navegador web, HTML/CSS/JavaScript
|
||||
mobile: Foco em app móvel, nativo iOS/Android, React Native etc.
|
||||
|
||||
Para casos relacionados a ambos, recomenda-se multi-role frontend,mobile
|
||||
```
|
||||
|
||||
### Q: Como distinguir security e analyzer?
|
||||
|
||||
```text
|
||||
A:
|
||||
security: Prevenção de ataques e ameaças, design de segurança
|
||||
analyzer: Análise de causas de problemas já ocorridos, investigação
|
||||
|
||||
Para investigação de incidentes de segurança: multi-role security,analyzer
|
||||
```
|
||||
|
||||
### Q: Qual a diferença entre architect e performance?
|
||||
|
||||
```text
|
||||
A:
|
||||
architect: Design de longo prazo do sistema geral, extensibilidade
|
||||
performance: Melhoria específica de velocidade e eficiência
|
||||
|
||||
Para design de performance de sistemas de grande escala: multi-role architect,performance
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Combinação com explicação da situação
|
||||
/role-help
|
||||
"O carregamento da página do app React está lento e usuários estão reclamando"
|
||||
|
||||
# Combinação com conteúdo de arquivo
|
||||
cat problem-description.md
|
||||
/role-help
|
||||
"Recomende o papel ideal para este problema"
|
||||
|
||||
# Quando estiver em dúvida sobre opções específicas
|
||||
/role-help compare security,performance
|
||||
"Qual papel é adequado para o problema de tempo de validade do token JWT?"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- Problemas complexos são mais eficazes com combinação de múltiplos papéis
|
||||
- Para casos de alta urgência, responda rapidamente com single role
|
||||
- Quando estiver em dúvida, recomendamos receber sugestão automática com smart-review
|
||||
- A decisão final deve ser tomada pelo usuário considerando a natureza do problema
|
||||
367
commands/role.md
Normal file
367
commands/role.md
Normal file
@@ -0,0 +1,367 @@
|
||||
## Role
|
||||
|
||||
Alterna para uma função (role) específica para executar análises e trabalhos especializados.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
/role <nome_do_role> [--agent|-a]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--agent` ou `-a` : Execução independente como subagente (recomendado para análises em larga escala)
|
||||
- Quando esta opção é usada, caso a descrição do role contenha frases de promoção de delegação automática (como "use PROACTIVELY"), uma delegação automática mais agressiva será habilitada
|
||||
|
||||
### Roles Disponíveis
|
||||
|
||||
#### Roles de Análise Especializada (Integração Evidence-First)
|
||||
|
||||
- `security` : Especialista em auditoria de segurança (OWASP Top 10, Modelagem de ameaças, Princípios Zero Trust e Correspondência CVE)
|
||||
- `performance` : Especialista em otimização de performance (Core Web Vitals, Modelo RAIL, Otimização gradual e Análise ROI)
|
||||
- `analyzer` : Especialista em análise de causa raiz (5 Whys, Pensamento sistêmico, Orientação por hipóteses e Contramedidas para vieses cognitivos)
|
||||
- `frontend` : Especialista em Frontend/UI/UX (WCAG 2.1, Design System e Design centrado no usuário)
|
||||
- `mobile` : Especialista em desenvolvimento mobile (iOS HIG, Android Material Design e Estratégia multiplataforma)
|
||||
- `backend` : Especialista em backend e servidor (design RESTful, escalabilidade e otimização de bancos de dados)
|
||||
|
||||
#### Roles de Suporte ao Desenvolvimento
|
||||
|
||||
- `reviewer` : Especialista em revisão de código (Legibilidade, Manutenibilidade, Performance e Propostas de refatoração)
|
||||
- `architect` : Arquiteto de sistemas (Design Evidence-First, Análise MECE e Arquitetura evolutiva)
|
||||
- `qa` : Engenheiro de testes (Cobertura de testes, Estratégia E2E/integração/unitária e Propostas de automação)
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Alternar para modo de auditoria de segurança (normal)
|
||||
/role security
|
||||
"Verifique as vulnerabilidades de segurança deste projeto"
|
||||
|
||||
# Executar auditoria de segurança com subagente (análise em larga escala)
|
||||
/role security --agent
|
||||
"Execute uma auditoria de segurança de todo o projeto"
|
||||
|
||||
# Alternar para modo de revisão de código
|
||||
/role reviewer
|
||||
"Revise as mudanças recentes e aponte pontos de melhoria"
|
||||
|
||||
# Alternar para modo de otimização de performance
|
||||
/role performance
|
||||
"Analise os gargalos da aplicação"
|
||||
|
||||
# Alternar para modo de análise de causa raiz
|
||||
/role analyzer
|
||||
"Investigue a causa raiz desta falha"
|
||||
|
||||
# Alternar para modo especializado em frontend
|
||||
/role frontend
|
||||
"Avalie os pontos de melhoria de UI/UX"
|
||||
|
||||
# Alternar para modo especializado em desenvolvimento mobile
|
||||
/role mobile
|
||||
"Avalie a otimização mobile desta aplicação"
|
||||
|
||||
# Voltar ao modo normal
|
||||
/role default
|
||||
"Retornando ao Claude normal"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise especializada em segurança
|
||||
/role security
|
||||
cat app.js
|
||||
"Analise detalhadamente os riscos potenciais de segurança neste código"
|
||||
|
||||
# Avaliação do ponto de vista da arquitetura
|
||||
/role architect
|
||||
ls -la src/
|
||||
"Apresente os problemas da estrutura atual e propostas de melhoria"
|
||||
|
||||
# Elaboração de estratégia de testes
|
||||
/role qa
|
||||
"Proponha a estratégia de testes ideal para este projeto"
|
||||
```
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Análise com múltiplos roles
|
||||
/role security
|
||||
"Primeiro, verificação do ponto de vista de segurança"
|
||||
git diff HEAD~1
|
||||
|
||||
/role reviewer
|
||||
"Em seguida, revisão da qualidade geral do código"
|
||||
|
||||
/role architect
|
||||
"Por último, avaliação do ponto de vista da arquitetura"
|
||||
|
||||
# Formato de saída específico do role
|
||||
/role security
|
||||
Resultado da análise de segurança
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Vulnerabilidade: SQL Injection
|
||||
Gravidade: High
|
||||
Local aplicável: db.js:42
|
||||
Proposta de correção: Usar queries parametrizadas
|
||||
```
|
||||
|
||||
### Funcionalidade de Integração Evidence-First
|
||||
|
||||
#### Filosofia Central
|
||||
|
||||
Cada role adota a abordagem **Evidence-First (baseada em evidências)** e realiza análises e propostas baseadas em **métodos comprovados, diretrizes oficiais e dados objetivos** em vez de especulações.
|
||||
|
||||
#### Características Comuns
|
||||
|
||||
- **Conformidade com documentação oficial**: Referência prioritária a diretrizes oficiais autoritativas de cada área
|
||||
- **Análise MECE**: Decomposição sistemática de problemas sem lacunas nem sobreposições
|
||||
- **Avaliação multifacetada**: Múltiplas perspectivas: técnica, negócios, operacional e usuário
|
||||
- **Contramedidas para vieses cognitivos**: Mecanismo de eliminação de viés de confirmação, etc.
|
||||
- **Características de discussão**: Postura de discussão especializada específica do role
|
||||
|
||||
### Detalhes dos Roles de Análise Especializada
|
||||
|
||||
#### security (Especialista em auditoria de segurança)
|
||||
|
||||
**Auditoria de segurança baseada em evidências**
|
||||
|
||||
- Avaliação sistemática por OWASP Top 10, Testing Guide e SAMM
|
||||
- Verificação de vulnerabilidades conhecidas por correspondência com banco de dados CVE e NVD
|
||||
- Modelagem de ameaças por STRIDE, Attack Tree e PASTA
|
||||
- Avaliação de design por princípios Zero Trust e privilégios mínimos
|
||||
|
||||
**Formato de relatório especializado**
|
||||
|
||||
```text
|
||||
Resultado da auditoria de segurança baseada em evidências
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Conformidade OWASP Top 10: XX% / Correspondência CVE: Concluída
|
||||
Modelagem de ameaças: Análise STRIDE concluída
|
||||
```
|
||||
|
||||
#### performance (Especialista em otimização de performance)
|
||||
|
||||
**Otimização de performance Evidence-First**
|
||||
|
||||
- Conformidade com Core Web Vitals (LCP, FID e CLS) e modelo RAIL
|
||||
- Implementação de recomendações do Google PageSpeed Insights
|
||||
- Processo de otimização gradual (medição → análise → priorização → implementação)
|
||||
- Avaliação quantitativa do custo-benefício por análise ROI
|
||||
|
||||
**Formato de relatório especializado**
|
||||
|
||||
```text
|
||||
Análise de performance Evidence-First
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Core Web Vitals: LCP[XXXms] FID[XXXms] CLS[X.XX]
|
||||
Performance Budget: XX% / Análise ROI: XX% previsão de melhoria
|
||||
```
|
||||
|
||||
#### analyzer (Especialista em análise de causa raiz)
|
||||
|
||||
**Análise de causa raiz Evidence-First**
|
||||
|
||||
- Método 5 Whys + α (incluindo consideração de contraprovas)
|
||||
- Análise estrutural por pensamento sistêmico (princípios de Peter Senge)
|
||||
- Contramedidas para vieses cognitivos (eliminação de viés de confirmação, ancoragem, etc.)
|
||||
- Análise orientada por hipóteses rigorosa (verificação paralela de múltiplas hipóteses)
|
||||
|
||||
**Formato de relatório especializado**
|
||||
|
||||
```text
|
||||
Análise de causa raiz Evidence-First
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Confiabilidade da análise: Alta / Contramedidas para viés: Implementadas
|
||||
Matriz de verificação de hipóteses: XX% de confiança
|
||||
```
|
||||
|
||||
#### frontend (Especialista em Frontend/UI/UX)
|
||||
|
||||
**Desenvolvimento frontend Evidence-First**
|
||||
|
||||
- Conformidade com acessibilidade WCAG 2.1
|
||||
- Conformidade com diretrizes oficiais Material Design e iOS HIG
|
||||
- Aplicação de padrões de design centrado no usuário e design system
|
||||
- Verificação por testes A/B e análise de comportamento do usuário
|
||||
|
||||
### Detalhes dos Roles de Suporte ao Desenvolvimento
|
||||
|
||||
#### reviewer (Especialista em revisão de código)
|
||||
|
||||
- Avaliação multifacetada de legibilidade, manutenibilidade e performance
|
||||
- Verificação de conformidade com convenções de codificação e propostas de refatoração
|
||||
- Confirmação transversal de segurança e acessibilidade
|
||||
|
||||
#### architect (Arquiteto de sistemas)
|
||||
|
||||
- Princípios de design Evidence-First e pensamento gradual por análise MECE
|
||||
- Arquitetura evolutiva e avaliação de múltiplas perspectivas (técnica, negócios, operacional e usuário)
|
||||
- Referência a padrões arquiteturais oficiais e melhores práticas
|
||||
|
||||
#### qa (Engenheiro de testes)
|
||||
|
||||
- Análise de cobertura de testes e estratégia de testes E2E/integração/unitários
|
||||
- Propostas de automação de testes e design de métricas de qualidade
|
||||
|
||||
#### mobile (Especialista em desenvolvimento mobile)
|
||||
|
||||
- Conformidade com diretrizes oficiais iOS HIG e Android Material Design
|
||||
- Estratégia multiplataforma e design Touch-First
|
||||
- Diretrizes de revisão da loja e otimização de UX específica para mobile
|
||||
|
||||
#### backend (Especialista em Backend e Servidor)
|
||||
|
||||
- Design de APIs RESTful/GraphQL, Domain-Driven Design e Clean Architecture
|
||||
- Escalabilidade, tolerância a falhas e otimização de desempenho
|
||||
- Otimização de bancos de dados, estratégias de cache e aumento de confiabilidade
|
||||
|
||||
### Características de Discussão Específicas dos Roles
|
||||
|
||||
Cada role possui postura de discussão única, fonte de argumentos e pontos fortes de acordo com sua área de especialização.
|
||||
|
||||
#### Características de discussão do role security
|
||||
|
||||
- **Postura**: Abordagem conservadora, priorização da minimização de riscos e suposição do pior caso
|
||||
- **Argumentos**: Diretrizes OWASP, framework NIST e casos reais de ataques
|
||||
- **Pontos fortes**: Precisão na avaliação de riscos, conhecimento profundo dos requisitos regulamentares e compreensão abrangente de métodos de ataque
|
||||
- **Cuidados**: Conservadorismo excessivo, falta de consideração com UX e subestimação dos custos de implementação
|
||||
|
||||
#### Características de discussão do role performance
|
||||
|
||||
- **Postura**: Decisões orientadas por dados, priorização da eficiência, priorização da experiência do usuário e melhoria contínua
|
||||
- **Argumentos**: Core Web Vitals, resultados de benchmark, dados de comportamento do usuário e padrões da indústria
|
||||
- **Pontos fortes**: Capacidade de avaliação quantitativa, precisão na identificação de gargalos e análise ROI
|
||||
- **Cuidados**: Subestimação da segurança, falta de consideração com manutenibilidade e foco excessivo em medições
|
||||
|
||||
#### Características de discussão do role analyzer
|
||||
|
||||
- **Postura**: Priorização de evidências, verificação de hipóteses, pensamento estrutural e eliminação de vieses
|
||||
- **Argumentos**: Dados de medição real, métodos estatísticos, teoria do pensamento sistêmico e pesquisa sobre vieses cognitivos
|
||||
- **Pontos fortes**: Capacidade de análise lógica, objetividade na avaliação de evidências e capacidade de descobrir problemas estruturais
|
||||
- **Cuidados**: Paralisia de análise, perfeccionismo, onipotência dos dados e ceticismo excessivo
|
||||
|
||||
#### Características de discussão do role frontend
|
||||
|
||||
- **Postura**: Centrado no usuário, priorização da acessibilidade, conformidade com princípios de design e priorização do valor da experiência
|
||||
- **Argumentos**: Pesquisa UX, padrões de acessibilidade, design system e testes de usabilidade
|
||||
- **Pontos fortes**: Perspectiva do usuário, princípios de design, acessibilidade e design de experiência
|
||||
- **Cuidados**: Subestimação de restrições técnicas, falta de consideração com performance e complexidade de implementação
|
||||
|
||||
### Efeitos da Colaboração Multi-Role
|
||||
|
||||
A combinação de roles com diferentes características de discussão permite análise equilibrada:
|
||||
|
||||
#### Padrões Típicos de Colaboração
|
||||
|
||||
- **security + frontend**: Equilíbrio entre segurança e usabilidade
|
||||
- **performance + security**: Compatibilidade entre velocidade e segurança
|
||||
- **analyzer + architect**: Integração de análise de problemas e design estrutural
|
||||
- **reviewer + qa**: Colaboração entre qualidade de código e estratégia de testes
|
||||
|
||||
## Funcionalidades Avançadas dos Roles
|
||||
|
||||
### Seleção Inteligente de Roles
|
||||
|
||||
- `/smart-review` : Proposta automática de roles por análise do projeto
|
||||
- `/role-help` : Guia de seleção do role ideal conforme a situação
|
||||
|
||||
### Colaboração Multi-Role
|
||||
|
||||
- `/multi-role <role1>,<role2>` : Análise simultânea de múltiplos roles
|
||||
- `/role-debate <role1>,<role2>` : Discussão entre roles
|
||||
|
||||
### Exemplos de Uso
|
||||
|
||||
#### Proposta Automática de Role
|
||||
|
||||
```bash
|
||||
/smart-review
|
||||
→ Analisa a situação atual e propõe o role ideal
|
||||
|
||||
/smart-review src/auth/
|
||||
→ Recomenda role security a partir de arquivos relacionados à autenticação
|
||||
```
|
||||
|
||||
#### Análise com Múltiplos Roles
|
||||
|
||||
```bash
|
||||
/multi-role security,performance
|
||||
"Avalie esta API de múltiplas perspectivas"
|
||||
→ Análise integrada dos pontos de vista de segurança e performance
|
||||
|
||||
/role-debate frontend,security
|
||||
"Discutam sobre UX da autenticação de dois fatores"
|
||||
→ Discussão dos pontos de vista de usabilidade e segurança
|
||||
```
|
||||
|
||||
#### Quando em Dúvida na Seleção de Role
|
||||
|
||||
```bash
|
||||
/role-help "API está lenta e também há preocupações com segurança"
|
||||
→ Propõe abordagem apropriada (multi-role ou debate)
|
||||
|
||||
/role-help compare frontend,mobile
|
||||
→ Diferenças e uso adequado dos roles frontend e mobile
|
||||
```
|
||||
|
||||
## Observações
|
||||
|
||||
### Sobre o Comportamento dos Roles
|
||||
|
||||
- Ao alternar roles, o **comportamento, prioridades, métodos de análise e formato de relatório** do Claude se especializa
|
||||
- Cada role adota **abordagem Evidence-First** aplicando prioritariamente diretrizes oficiais e métodos comprovados
|
||||
- Use `default` para retornar ao modo normal (especialização do role é cancelada)
|
||||
- Os roles são válidos apenas dentro da sessão atual
|
||||
|
||||
### Métodos de Utilização Eficaz
|
||||
|
||||
- **Problemas simples**: Análise especializada com role único é suficiente
|
||||
- **Problemas complexos**: multi-role ou role-debate são eficazes para análise multifacetada
|
||||
- **Em caso de dúvida**: Utilize smart-review ou role-help
|
||||
- **Melhoria contínua**: Mesmo com o mesmo role, a precisão da análise melhora com novas evidências e métodos
|
||||
|
||||
### Funcionalidade de Subagente (opção --agent)
|
||||
|
||||
Quando análises em larga escala ou processamento especializado independente são necessários, você pode executar roles como subagentes usando a opção `--agent`.
|
||||
|
||||
#### Vantagens
|
||||
|
||||
- **Contexto independente**: Não interfere na conversa principal
|
||||
- **Execução paralela**: Possível executar múltiplas análises simultaneamente
|
||||
- **Especialização**: Análises mais profundas e relatórios detalhados
|
||||
- **Promoção da delegação automática**: Quando a descrição do role contém "use PROACTIVELY" ou "MUST BE USED", uma delegação automática mais agressiva é habilitada
|
||||
|
||||
#### Cenários de Uso Recomendados
|
||||
|
||||
```bash
|
||||
# Segurança: Verificação de todos os itens OWASP, correspondência CVE
|
||||
/role security --agent
|
||||
"Auditoria de segurança de toda a base de código"
|
||||
|
||||
# Analisador: Análise de causa raiz de logs volumosos
|
||||
/role analyzer --agent
|
||||
"Analise os logs de erro da última semana"
|
||||
|
||||
# Revisor: Revisão detalhada de PR em larga escala
|
||||
/role reviewer --agent
|
||||
"Revise as 1000 linhas de mudanças do PR #500"
|
||||
```
|
||||
|
||||
#### Role Normal vs Subagente
|
||||
|
||||
| Situação | Recomendado | Comando |
|
||||
| ----------------------- | ----------- | ------------------------ |
|
||||
| Verificação simples | Role normal | `/role security` |
|
||||
| Análise em larga escala | Subagente | `/role security --agent` |
|
||||
| Trabalho interativo | Role normal | `/role frontend` |
|
||||
| Auditoria independente | Subagente | `/role qa --agent` |
|
||||
|
||||
### Detalhes da Configuração dos Roles
|
||||
|
||||
- Configurações detalhadas, conhecimento especializado e características de discussão de cada role são definidas no diretório `.claude/agents/roles/`
|
||||
- Inclui métodos Evidence-First e contramedidas para vieses cognitivos
|
||||
- Modo especializado é ativado automaticamente por frases-gatilho específicas do role
|
||||
- Os arquivos reais dos roles são compostos por conteúdo especializado de mais de 200 linhas
|
||||
103
commands/screenshot.md
Normal file
103
commands/screenshot.md
Normal file
@@ -0,0 +1,103 @@
|
||||
## Screenshot
|
||||
|
||||
Captura screenshots no macOS e analisa as imagens.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
/screenshot [opções]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- nenhuma : Seleciona janela (Claude confirma as opções)
|
||||
- `--window` : Especifica e captura janela
|
||||
- `--full` : Captura tela inteira
|
||||
- `--crop` : Seleciona região para captura
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Captura janela e analisa
|
||||
/screenshot --window
|
||||
"Analise a tela capturada"
|
||||
|
||||
# Seleciona região e analisa
|
||||
/screenshot --crop
|
||||
"Descreva o conteúdo da região selecionada"
|
||||
|
||||
# Captura tela inteira e analisa
|
||||
/screenshot --full
|
||||
"Analise a composição de toda a tela"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Sem problema específico - análise da situação
|
||||
/screenshot --crop
|
||||
(Claude automaticamente analisa o conteúdo da tela e descreve elementos e composição)
|
||||
|
||||
# Análise de problemas de UI/UX
|
||||
/screenshot --window
|
||||
"Proponha pontos problemáticos desta UI e sugestões de melhoria"
|
||||
|
||||
# Análise de erros
|
||||
/screenshot --window
|
||||
"Ensine a causa e método de resolução desta mensagem de erro"
|
||||
|
||||
# Revisão de design
|
||||
/screenshot --full
|
||||
"Avalie este design do ponto de vista de UX"
|
||||
|
||||
# Análise de código
|
||||
/screenshot --crop
|
||||
"Aponte os problemas deste código"
|
||||
|
||||
# Análise de visualização de dados
|
||||
/screenshot --crop
|
||||
"Analise as tendências que podem ser lidas deste gráfico"
|
||||
```
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Análise de múltiplas perspectivas
|
||||
/screenshot --window
|
||||
"Analise esta tela sobre o seguinte:
|
||||
1. Consistência da UI
|
||||
2. Problemas de acessibilidade
|
||||
3. Propostas de melhoria"
|
||||
|
||||
# Múltiplas capturas para análise comparativa
|
||||
/screenshot --window
|
||||
# (salva imagem do before)
|
||||
# Faz mudanças
|
||||
/screenshot --window
|
||||
# (salva imagem do after)
|
||||
"Compare as imagens before e after, analise mudanças e efeitos de melhoria"
|
||||
|
||||
# Foco em elemento específico
|
||||
/screenshot --crop
|
||||
"Avalie se o design do botão selecionado está em harmonia com outros elementos"
|
||||
```
|
||||
|
||||
### Itens Proibidos
|
||||
|
||||
- **É proibido dizer "capturei" sem ter capturado screenshot**
|
||||
- **É proibido tentar analisar arquivos de imagem inexistentes**
|
||||
- **O comando `/screenshot` não realiza captura real de screenshot**
|
||||
|
||||
### Observações
|
||||
|
||||
- Quando nenhuma opção é especificada, apresente as seguintes escolhas:
|
||||
|
||||
```
|
||||
"Qual método usar para capturar screenshot?
|
||||
1. Selecionar janela (--window) → screencapture -W
|
||||
2. Tela inteira (--full) → screencapture -x
|
||||
3. Selecionar região (--crop) → screencapture -i"
|
||||
```
|
||||
|
||||
- Inicie a análise de imagem após o usuário executar o comando screencapture
|
||||
- Ao especificar problemas ou pontos de vista específicos, é possível uma análise mais focada
|
||||
66
commands/search-gemini.md
Normal file
66
commands/search-gemini.md
Normal file
@@ -0,0 +1,66 @@
|
||||
## Gemini Web Search
|
||||
|
||||
Executa busca na Web usando Gemini CLI para obter informações mais recentes.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Busca na Web via Gemini CLI (obrigatório)
|
||||
gemini --prompt "WebSearch: <consulta de busca>"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Usar Gemini CLI
|
||||
gemini --prompt "WebSearch: React 19 novas funcionalidades"
|
||||
gemini --prompt "WebSearch: TypeError Cannot read property of undefined método de resolução"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Busca e resumo de documentação
|
||||
gemini --prompt "WebSearch: Next.js 14 App Router documentação oficial"
|
||||
"Resuma os resultados da busca e explique as principais funcionalidades"
|
||||
|
||||
# Investigação de erros
|
||||
cat error.log
|
||||
gemini --prompt "WebSearch: [mensagem de erro] método de resolução"
|
||||
"Proponha o método de resolução mais adequado dos resultados da busca"
|
||||
|
||||
# Comparação técnica
|
||||
gemini --prompt "WebSearch: Rust vs Go performance benchmark 2024"
|
||||
"Resuma as diferenças de performance dos resultados da busca"
|
||||
```
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Coleta de informações de múltiplas fontes
|
||||
gemini --prompt "WebSearch: GraphQL best practices 2024 multiple sources"
|
||||
"Compile informações de múltiplas fontes confiáveis dos resultados da busca"
|
||||
|
||||
# Investigação de mudanças cronológicas
|
||||
gemini --prompt "WebSearch: JavaScript ES2015 ES2016 ES2017 ES2018 ES2019 ES2020 ES2021 ES2022 ES2023 ES2024 features"
|
||||
"Resuma as principais mudanças de cada versão em ordem cronológica"
|
||||
|
||||
# Busca restrita a domínio específico
|
||||
gemini --prompt "WebSearch: site:github.com Rust WebAssembly projects stars:>1000"
|
||||
"Liste 10 projetos em ordem de número de estrelas"
|
||||
|
||||
# Informações mais recentes de segurança
|
||||
gemini --prompt "WebSearch: CVE-2024 Node.js vulnerabilities"
|
||||
"Resuma o impacto e contramedidas das vulnerabilidades encontradas"
|
||||
```
|
||||
|
||||
### Itens Proibidos
|
||||
|
||||
- **É proibido usar a ferramenta WebSearch integrada do Claude**
|
||||
- Quando busca na Web for necessária, sempre usar `gemini --prompt "WebSearch: ..."`
|
||||
|
||||
### Observações
|
||||
|
||||
- **Quando Gemini CLI estiver disponível, sempre usar `gemini --prompt "WebSearch: ..."`**
|
||||
- Os resultados de busca na Web nem sempre são os mais recentes
|
||||
- É recomendado confirmar informações importantes na documentação oficial ou fontes confiáveis
|
||||
1137
commands/semantic-commit.md
Normal file
1137
commands/semantic-commit.md
Normal file
File diff suppressed because it is too large
Load Diff
90
commands/sequential-thinking.md
Normal file
90
commands/sequential-thinking.md
Normal file
@@ -0,0 +1,90 @@
|
||||
## Sequential Thinking
|
||||
|
||||
Resolve problemas complexos gradualmente através de processo de pensamento dinâmico e iterativo. Abordagem flexível que permite mudanças de direção e revisões no meio do pensamento.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Solicitar pensamento sequencial ao Claude
|
||||
"Considere [questão] usando sequential-thinking"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Design de algoritmos
|
||||
"Projete estratégia eficiente de cache usando sequential-thinking"
|
||||
|
||||
# Resolução de problemas
|
||||
"Resolva problemas de performance do banco de dados usando sequential-thinking"
|
||||
|
||||
# Consideração de design
|
||||
"Considere design de sistema de notificações em tempo real usando sequential-thinking"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Política de implementação complexa
|
||||
"Considere política de implementação do sistema de autenticação usando sequential-thinking. Considerando OAuth2, JWT e gerenciamento de sessão"
|
||||
|
||||
# Análise de causa de bugs
|
||||
"Analise a causa do vazamento de memória usando sequential-thinking. Inclua revisão de código e resultados de profiling"
|
||||
|
||||
# Estratégia de refatoração
|
||||
cat src/complex_module.js
|
||||
"Elabore estratégia de refatoração deste módulo usando sequential-thinking"
|
||||
|
||||
# Seleção técnica
|
||||
"Analise escolha de framework frontend usando sequential-thinking. Considerando requisitos e restrições do projeto"
|
||||
```
|
||||
|
||||
### Processo de Pensamento
|
||||
|
||||
1. **Análise inicial** - Compreensão e decomposição básica do problema
|
||||
2. **Geração de hipóteses** - Estabelece hipóteses para soluções
|
||||
3. **Verificação e correção** - Verifica hipóteses e corrige conforme necessário
|
||||
4. **Ramificação e exploração** - Explora múltiplos caminhos de solução
|
||||
5. **Integração e conclusão** - Deduz solução ótima
|
||||
|
||||
### Características
|
||||
|
||||
- **Ajuste dinâmico** - Possível mudar direção no meio do pensamento
|
||||
- **Verificação de hipóteses** - Ciclo de estabelecer e verificar hipóteses
|
||||
- **Pensamento ramificado** - Explora múltiplos caminhos de pensamento simultaneamente
|
||||
- **Refinamento gradual** - Refina gradualmente as soluções
|
||||
- **Flexibilidade** - Mudança de política baseada em novas informações
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Design complexo de sistema
|
||||
"Considere design de microsserviços para site de e-commerce usando sequential-thinking. Inclua integração de processamento de pedidos, gerenciamento de estoque e pagamento"
|
||||
|
||||
# Design de segurança
|
||||
"Considere design de segurança de API usando sequential-thinking. Inclua autenticação, autorização, rate limiting e log de auditoria"
|
||||
|
||||
# Otimização de performance
|
||||
"Considere otimização de processamento de dados em larga escala usando sequential-thinking. Considerando uso de memória, velocidade de processamento e escalabilidade"
|
||||
|
||||
# Gerenciamento de dependências
|
||||
"Considere estratégia de gerenciamento de dependências de monorepo usando sequential-thinking. Inclua tempo de build, deploy e execução de testes"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
sequential-thinking é ideal para problemas complexos que requerem aprofundar gradualmente o pensamento. Para perguntas simples ou quando há respostas claras, use o formato de pergunta normal.
|
||||
|
||||
### Exemplo de Execução
|
||||
|
||||
```bash
|
||||
# Exemplo de uso
|
||||
"Considere design de schema GraphQL usando sequential-thinking"
|
||||
|
||||
# Comportamento esperado
|
||||
# 1. Análise inicial: Analisa requisitos básicos do schema GraphQL
|
||||
# 2. Geração de hipóteses: Considera múltiplos padrões de design
|
||||
# 3. Verificação: Verifica vantagens e desvantagens de cada padrão
|
||||
# 4. Ramificação: Explora novas abordagens conforme necessário
|
||||
# 5. Integração: Propõe design ótimo do schema
|
||||
```
|
||||
59
commands/show-plan.md
Normal file
59
commands/show-plan.md
Normal file
@@ -0,0 +1,59 @@
|
||||
## Show Plan
|
||||
|
||||
Exibe planos em execução ou executados na sessão atual.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
/show-plan
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Confirmar plano atual
|
||||
/show-plan
|
||||
"Exibir plano em execução"
|
||||
|
||||
# Quando não há plano
|
||||
/show-plan
|
||||
"Não há planos na sessão atual"
|
||||
```
|
||||
|
||||
### Funcionalidades
|
||||
|
||||
- Detecta planos criados com exit_plan_mode
|
||||
- Explora títulos que contêm palavras-chave como plano de implementação, conteúdo de implementação, plano, etc.
|
||||
- Formata e exibe o conteúdo do plano
|
||||
- Notifica claramente quando não há planos
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Confirmar plano durante implementação
|
||||
"O que estava implementando mesmo?"
|
||||
/show-plan
|
||||
|
||||
# Durante execução de múltiplas tarefas
|
||||
"Deixe-me confirmar o plano atual novamente"
|
||||
/show-plan
|
||||
|
||||
# Retrospectiva após execução do plano
|
||||
"Mostre o conteúdo do plano que executei há pouco"
|
||||
/show-plan
|
||||
```
|
||||
|
||||
### Padrões de Detecção
|
||||
|
||||
Baseado no formato de planos gerados pelo exit_plan_mode, detecta os seguintes padrões:
|
||||
|
||||
- Títulos começando com `##` (contendo plano, Plan, etc.)
|
||||
- `### Conteúdo das mudanças`
|
||||
- `### Conteúdo da implementação`
|
||||
- `### Plano de implementação`
|
||||
- `### 1.` e outros títulos numerados
|
||||
|
||||
### Observações
|
||||
|
||||
- Exibe apenas planos da sessão atual (não inclui sessões passadas)
|
||||
- Prioriza a exibição do plano mais recente
|
||||
174
commands/smart-review.md
Normal file
174
commands/smart-review.md
Normal file
@@ -0,0 +1,174 @@
|
||||
## Smart Review
|
||||
|
||||
Comando que analisa a situação atual e sugere automaticamente o papel e abordagem ideais.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/smart-review # Analisa diretório atual
|
||||
/smart-review <arquivo/diretório> # Analisa alvo específico
|
||||
```
|
||||
|
||||
### Lógica de determinação automática
|
||||
|
||||
### Determinação por extensão de arquivo
|
||||
|
||||
- `package.json`, `*.tsx`, `*.jsx`, `*.css`, `*.scss` → **frontend**
|
||||
- `Dockerfile`, `docker-compose.yml`, `*.yaml` → **architect**
|
||||
- `*.test.js`, `*.spec.ts`, `test/`, `__tests__/` → **qa**
|
||||
- `*.rs`, `Cargo.toml`, `performance/` → **performance**
|
||||
|
||||
### Detecção de arquivos relacionados à segurança
|
||||
|
||||
- `auth.js`, `security.yml`, `.env`, `config/auth/` → **security**
|
||||
- `login.tsx`, `signup.js`, `jwt.js` → **security + frontend**
|
||||
- `api/auth/`, `middleware/auth/` → **security + architect**
|
||||
|
||||
### Padrões de determinação complexa
|
||||
|
||||
- `mobile/` + `*.swift`, `*.kt`, `react-native/` → **mobile**
|
||||
- `webpack.config.js`, `vite.config.js`, `large-dataset/` → **performance**
|
||||
- `components/` + `responsive.css` → **frontend + mobile**
|
||||
- `api/` + `auth/` → **security + architect**
|
||||
|
||||
### Análise de erros e problemas
|
||||
|
||||
- Stack trace, `error.log`, `crash.log` → **analyzer**
|
||||
- `memory leak`, `high CPU`, `slow query` → **performance + analyzer**
|
||||
- `SQL injection`, `XSS`, `CSRF` → **security + analyzer**
|
||||
|
||||
### Padrões de sugestão
|
||||
|
||||
### Sugestão de papel único
|
||||
|
||||
```bash
|
||||
$ /smart-review src/auth/login.js
|
||||
→ "Arquivo de autenticação detectado"
|
||||
→ "Recomenda-se análise com papel security"
|
||||
→ "Executar? [y]es / [n]o / [m]ore options"
|
||||
```
|
||||
|
||||
### Sugestão de múltiplos papéis
|
||||
|
||||
```bash
|
||||
$ /smart-review src/mobile/components/
|
||||
→ "📱🎨 Elementos mobile + frontend detectados"
|
||||
→ "Abordagem recomendada:"
|
||||
→ "[1] Papel mobile individual"
|
||||
→ "[2] Papel frontend individual"
|
||||
→ "[3] multi-role mobile,frontend"
|
||||
→ "[4] role-debate mobile,frontend"
|
||||
```
|
||||
|
||||
### Sugestão durante análise de problemas
|
||||
|
||||
```bash
|
||||
$ /smart-review error.log
|
||||
→ "⚠️ Log de erro detectado"
|
||||
→ "Iniciando análise de causa raiz com papel analyzer"
|
||||
→ "[Execução automática] /role analyzer"
|
||||
|
||||
$ /smart-review slow-api.log
|
||||
→ "🐌 Problema de performance detectado"
|
||||
→ "Recomendado: [1]/role performance [2]/role-debate performance,analyzer"
|
||||
```
|
||||
|
||||
### Sugestão para decisões de design complexas
|
||||
|
||||
```bash
|
||||
$ /smart-review architecture-design.md
|
||||
→ "🏗️🔒⚡ Elementos arquitetura + segurança + performance detectados"
|
||||
→ "Para decisão de design complexa, recomenda-se formato de debate"
|
||||
→ "[Recomendado] /role-debate architect,security,performance"
|
||||
→ "[Alternativo] /multi-role architect,security,performance"
|
||||
```
|
||||
|
||||
### Detalhes da lógica de sugestão
|
||||
|
||||
### Determinação de prioridade
|
||||
|
||||
1. **Security** - Relacionado à autenticação, autorização, criptografia é máxima prioridade
|
||||
2. **Critical Errors** - Parada do sistema, perda de dados é urgente
|
||||
3. **Architecture** - Mudanças de grande escala, seleção tecnológica requer consideração cuidadosa
|
||||
4. **Performance** - Conecta diretamente à experiência do usuário
|
||||
5. **Frontend/Mobile** - Melhorias de UI/UX
|
||||
6. **QA** - Relacionado à garantia de qualidade e testes
|
||||
|
||||
### Condições para recomendação de debate
|
||||
|
||||
- Quando 3 ou mais papéis estão relacionados
|
||||
- Quando há trade-off entre segurança vs performance
|
||||
- Quando inclui mudanças arquiteturais significativas
|
||||
- Quando afeta tanto mobile quanto web
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# Analisa diretório atual
|
||||
/smart-review
|
||||
"Sugira o papel e abordagem ideais"
|
||||
|
||||
# Analisa arquivo específico
|
||||
/smart-review src/auth/login.js
|
||||
"Sugira o método de revisão ideal para este arquivo"
|
||||
|
||||
# Analisa log de erro
|
||||
/smart-review error.log
|
||||
"Sugira a abordagem ideal para resolver este erro"
|
||||
```
|
||||
|
||||
### Exemplos práticos
|
||||
|
||||
### Análise do projeto inteiro
|
||||
|
||||
```bash
|
||||
$ /smart-review
|
||||
→ "📊 Analisando projeto..."
|
||||
→ "Projeto React + TypeScript detectado"
|
||||
→ "Confirmada funcionalidade de autenticação + API + suporte móvel"
|
||||
→ ""
|
||||
→ "💡 Workflow recomendado:"
|
||||
→ "1. Verificação do sistema de autenticação com security"
|
||||
→ "2. Avaliação de UI/UX com frontend"
|
||||
→ "3. Verificação de otimização móvel com mobile"
|
||||
→ "4. Revisão do design geral com architect"
|
||||
→ ""
|
||||
→ "Executar automaticamente? [y]es / [s]elect role / [c]ustom"
|
||||
```
|
||||
|
||||
### Análise de problema específico
|
||||
|
||||
```bash
|
||||
$ /smart-review "Como configurar o tempo de validade do JWT"
|
||||
→ "🤔 Decisão de design técnico detectada"
|
||||
→ "É um problema que requer múltiplas perspectivas especializadas"
|
||||
→ ""
|
||||
→ "Abordagem recomendada:"
|
||||
→ "/role-debate security,performance,frontend"
|
||||
→ "Motivo: Importante o equilíbrio entre segurança, performance e UX"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise combinada com conteúdo do arquivo
|
||||
cat src/auth/middleware.js
|
||||
/smart-review
|
||||
"Analise incluindo o conteúdo deste arquivo sob perspectiva de segurança"
|
||||
|
||||
# Análise combinada com erro
|
||||
npm run build 2>&1 | tee build-error.log
|
||||
/smart-review build-error.log
|
||||
"Sugira método de resolução para erro de build"
|
||||
|
||||
# Consulta de design
|
||||
/smart-review
|
||||
"Debata se devemos escolher React Native ou Progressive Web App"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- As sugestões são informações de referência. A decisão final deve ser tomada pelo usuário
|
||||
- Para problemas complexos, recomenda-se formato de debate (role-debate)
|
||||
- Para problemas simples, single role é suficiente na maioria dos casos
|
||||
- Para questões relacionadas à segurança, sempre se recomenda verificação com papel especializado
|
||||
559
commands/spec.md
Normal file
559
commands/spec.md
Normal file
@@ -0,0 +1,559 @@
|
||||
## Spec
|
||||
|
||||
**"Dar estrutura antes de escrever código"** - Totalmente em conformidade com o spec-driven development de Kiro
|
||||
|
||||
Diferente das ferramentas tradicionais de geração de código, realiza o desenvolvimento orientado por especificações de Kiro focado em dar estrutura ao caos do desenvolvimento. A partir de uma entrada mínima de requisitos, expande gradualmente desde especificações detalhadas de nível de product manager até design implementável, garantindo qualidade consistente do **protótipo ao ambiente de produção**.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Solicitar Spec Mode ao Claude (entrada mínima de requisitos)
|
||||
"Crie spec de [descrição da funcionalidade]"
|
||||
|
||||
# Expansão gradual estilo Kiro:
|
||||
# 1. Requisitos simples → Geração automática de user stories detalhadas
|
||||
# 2. Descrição estruturada de requisitos usando notação EARS
|
||||
# 3. Refinamento de especificações através de diálogo gradual
|
||||
# 4. Geração de 3 arquivos independentes:
|
||||
# - requirements.md: Definição de requisitos usando notação EARS
|
||||
# - design.md: Design incluindo diagramas Mermaid e interfaces TypeScript
|
||||
# - tasks.md: Plano de implementação com aplicação automática de boas práticas
|
||||
```
|
||||
|
||||
### Efeitos Comprovados (Resultados do Kiro)
|
||||
|
||||
**Aplicativo de compartilhamento seguro de arquivos em 2 dias**
|
||||
|
||||
```bash
|
||||
"Crie spec de sistema de compartilhamento de arquivos (com suporte a criptografia)"
|
||||
→ Aplicativo de compartilhamento de arquivos criptografados de nível de produção concluído em 2 dias
|
||||
→ Aplicação automática de boas práticas de segurança
|
||||
→ Sem necessidade de prompts adicionais
|
||||
```
|
||||
|
||||
**Desenvolvimento de jogo em uma noite (iniciante)**
|
||||
|
||||
```bash
|
||||
"Crie spec de jogo de quebra-cabeça 2D"
|
||||
→ Desenvolvedor de código aberto sem experiência em desenvolvimento de jogos
|
||||
→ Criação de jogo concluída em uma noite
|
||||
→ Kiro cuidou da lógica de implementação, desenvolvedor se concentrou na criatividade
|
||||
```
|
||||
|
||||
**Protótipo→Produção em um fim de semana**
|
||||
|
||||
```bash
|
||||
"Crie spec de sistema de gerenciamento de produtos para site de e-commerce"
|
||||
→ Do conceito ao protótipo funcional em um fim de semana
|
||||
→ Qualidade consistente do protótipo ao ambiente de produção
|
||||
→ Abordagem estruturada através de spec-driven development
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Criação de spec para nova funcionalidade (entrada mínima)
|
||||
"Sistema de avaliação de produtos
|
||||
- Funcionalidade de avaliação por estrelas
|
||||
- Postagem de comentários
|
||||
- Upload de imagens"
|
||||
|
||||
# Criação de spec para funcionalidade de sistema
|
||||
"Autenticação de usuário
|
||||
- Suporte OAuth
|
||||
- Autenticação multifator"
|
||||
|
||||
# Criação de spec para funcionalidade de API
|
||||
"API de sistema de pagamento
|
||||
- Integração Stripe
|
||||
- Foco em segurança"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Spec de funcionalidade complexa
|
||||
"Crie spec de funcionalidade de chat. Inclua WebSocket, notificações em tempo real e gerenciamento de histórico"
|
||||
|
||||
# Spec de funcionalidade com integração de banco de dados
|
||||
"Crie spec de funcionalidade de gerenciamento de estoque para site de e-commerce. Inclua adição de produtos, atualização de estoque e funcionalidade de alertas"
|
||||
|
||||
# Spec de funcionalidade de frontend
|
||||
"Crie spec de dashboard React. Inclua exibição de gráficos, filtros e funcionalidade de exportação"
|
||||
|
||||
# Spec de funcionalidade de backend
|
||||
"Crie spec de API RESTful. Inclua autenticação, validação e registro de logs"
|
||||
```
|
||||
|
||||
### Características do Spec Mode
|
||||
|
||||
**Fluxo de Trabalho de Diálogo Gradual**
|
||||
|
||||
- Reprodução completa do diálogo gradual que é o valor original do Kiro
|
||||
- Refinamento colaborativo de especificações com o usuário em cada fase
|
||||
- Geração de arquivos após processo de esclarecimento de dúvidas, discussão de opções e aprovação
|
||||
|
||||
**Expansão Interativa em 3 Estágios**
|
||||
|
||||
- **Phase 1**: Requirements Discovery → Discussão → Aprovação → Geração de `requirements.md`
|
||||
- **Phase 2**: Design Exploration → Discussão → Aprovação → Geração de `design.md`
|
||||
- **Phase 3**: Implementation Planning → Discussão → Aprovação → Geração de `tasks.md`
|
||||
|
||||
**Especificação Dinâmica**
|
||||
|
||||
- Resolução de ambiguidades nos requisitos através de diálogo
|
||||
- Apresentação e discussão de opções técnicas
|
||||
- Explicação de trade-offs e confirmação de decisões
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Funcionalidade complexa de sistema
|
||||
"Crie spec de sistema de pagamento online. Inclua integração Stripe, segurança e tratamento de erros"
|
||||
|
||||
# Funcionalidade de frontend
|
||||
"Crie spec de componente React. Inclua gerenciamento de estado, design de propriedades e testes"
|
||||
|
||||
# Funcionalidade de backend
|
||||
"Crie spec de API GraphQL. Inclua design de schema, resolvers e autenticação"
|
||||
|
||||
# Funcionalidade DevOps
|
||||
"Crie spec de pipeline CI/CD. Inclua automação de testes, deployment e monitoramento"
|
||||
```
|
||||
|
||||
### Fluxo de Trabalho de Diálogo Gradual (Phase by Phase)
|
||||
|
||||
#### Phase 1: Requirements Discovery & Discussion
|
||||
|
||||
**1. Expansão automática a partir de entrada mínima (estilo Kiro)**
|
||||
|
||||
```text
|
||||
Usuário: "Sistema de gerenciamento de usuários
|
||||
- Funcionalidade de login
|
||||
- Edição de perfil
|
||||
- Permissões de administrador"
|
||||
|
||||
Claude: "Vou gerar user stories detalhadas a partir dos requisitos.
|
||||
Esta compreensão está correta?
|
||||
|
||||
User Stories geradas automaticamente:
|
||||
- Funcionalidade de registro e autenticação de usuários (suporte OAuth)
|
||||
- Funcionalidade de gerenciamento de perfil (avatar, configurações)
|
||||
- Funcionalidade de gerenciamento de permissões (RBAC)
|
||||
- Funcionalidade de reset de senha
|
||||
- Log de auditoria de segurança
|
||||
|
||||
Complementei os detalhes não explicitados. Há outras funcionalidades necessárias?"
|
||||
```
|
||||
|
||||
**2. Descrição estruturada de requisitos usando notação EARS**
|
||||
|
||||
```text
|
||||
Claude: "Vou estruturar os requisitos com a notação EARS do Kiro:
|
||||
|
||||
Definição de requisitos pela notação EARS:
|
||||
|
||||
WHEN o usuário tenta fazer login
|
||||
GIVEN que inseriu email e senha corretos
|
||||
THEN o sistema confirma a autenticação
|
||||
AND redireciona para o dashboard em caso de sucesso
|
||||
|
||||
WHILE o usuário está na tela de edição de perfil
|
||||
THE SYSTEM SHALL executar validação em tempo real
|
||||
AND exibir preview das mudanças
|
||||
|
||||
WHERE funcionalidades que requerem permissões de administrador
|
||||
IS há tentativa de acesso
|
||||
THE SYSTEM SHALL verificar o nível de permissão
|
||||
AND negar acesso se insuficiente"
|
||||
```
|
||||
|
||||
**3. Complementação automática de casos extremos e requisitos de segurança**
|
||||
|
||||
```text
|
||||
Claude: "Baseado nas boas práticas do Kiro, também considerei os seguintes casos:
|
||||
|
||||
Requisitos de segurança (complementação automática):
|
||||
- Proteção contra ataques de força bruta
|
||||
- Gerenciamento de sessão e timeout
|
||||
- Proteção CSRF e contramedidas XSS
|
||||
- Requisitos de força da senha
|
||||
|
||||
Casos extremos (detecção automática):
|
||||
- Limitação de login simultâneo
|
||||
- Funcionalidade de bloqueio de conta
|
||||
- Garantia de integridade durante migração de dados
|
||||
- Balanceamento de carga para grandes volumes de requisições
|
||||
|
||||
Estes requisitos são adequados?"
|
||||
```
|
||||
|
||||
**5. Conclusão e aprovação da Phase 1**
|
||||
|
||||
```text
|
||||
Claude: "Requirements Phase foi concluída.
|
||||
Posso gerar requirements.md?"
|
||||
→ "Próximo passo" → Geração de requirements.md
|
||||
```
|
||||
|
||||
#### Phase 2: Design Exploration & Discussion
|
||||
|
||||
**1. Análise de codebase + Proposta automática de design (estilo Kiro)**
|
||||
|
||||
```text
|
||||
Claude: "Vou analisar a codebase existente e propor a arquitetura ideal:
|
||||
|
||||
Resultado da análise da codebase:
|
||||
- Autenticação: JWT + Express.js (v4.18.x)
|
||||
- Banco de dados: PostgreSQL (v14+)
|
||||
- Frontend: React + TypeScript (v18+)
|
||||
- Padrões existentes: Repository pattern, separação de camada Service
|
||||
|
||||
Arquitetura recomendada pelo Kiro:
|
||||
- Conformidade com Clean Architecture
|
||||
- Elementos de Domain-Driven Design
|
||||
- Aplicação parcial do padrão CQRS
|
||||
- Boas práticas de segurança automatizadas
|
||||
|
||||
Proceder com este design?"
|
||||
```
|
||||
|
||||
**2. Design visual com diagramas Mermaid**
|
||||
|
||||
```text
|
||||
Claude: "Gerei automaticamente o design de sistema com diagrama Mermaid:
|
||||
|
||||
Diagrama de arquitetura gerado automaticamente:
|
||||
|
||||
graph TB
|
||||
Client[React Client] --> API[Express API Gateway]
|
||||
API --> Auth[Auth Service]
|
||||
API --> User[User Service]
|
||||
API --> Profile[Profile Service]
|
||||
|
||||
Auth --> AuthDB[(Auth Database)]
|
||||
User --> UserDB[(User Database)]
|
||||
Profile --> ProfileDB[(Profile Database)]
|
||||
|
||||
Auth --> JWT[JWT Service]
|
||||
Auth --> OAuth[OAuth Provider]
|
||||
|
||||
Também gerar diagrama de fluxo de dados?"
|
||||
```
|
||||
|
||||
**3. Geração automática de interfaces TypeScript**
|
||||
|
||||
```text
|
||||
Claude: "Vou gerar automaticamente interfaces TypeScript baseadas no design:
|
||||
|
||||
Interfaces TypeScript geradas automaticamente:
|
||||
|
||||
// Domain entities
|
||||
interface User {
|
||||
readonly id: UserId;
|
||||
readonly email: Email;
|
||||
readonly profile: UserProfile;
|
||||
readonly auth: AuthSettings;
|
||||
readonly permissions: Permission[];
|
||||
readonly createdAt: Date;
|
||||
readonly updatedAt: Date;
|
||||
}
|
||||
|
||||
interface UserProfile {
|
||||
readonly displayName: string;
|
||||
readonly avatar: AvatarUrl;
|
||||
readonly preferences: UserPreferences;
|
||||
}
|
||||
|
||||
interface AuthSettings {
|
||||
readonly passwordHash: PasswordHash;
|
||||
readonly mfaEnabled: boolean;
|
||||
readonly lastLoginAt: Date;
|
||||
readonly failedAttempts: number;
|
||||
}
|
||||
|
||||
// Use cases
|
||||
interface UserRepository {
|
||||
findById(id: UserId): Promise<User | null>;
|
||||
findByEmail(email: Email): Promise<User | null>;
|
||||
save(user: User): Promise<void>;
|
||||
}
|
||||
|
||||
interface AuthenticationService {
|
||||
authenticate(credentials: LoginCredentials): Promise<AuthResult>;
|
||||
refreshToken(token: RefreshToken): Promise<AccessToken>;
|
||||
}
|
||||
|
||||
Proceder com este design de interface?"
|
||||
```
|
||||
|
||||
**4. Conclusão e aprovação da Phase 2**
|
||||
|
||||
```text
|
||||
|
||||
Claude: "Design Phase foi concluída.
|
||||
Posso gerar design.md?"
|
||||
→ "Próximo passo" → Geração de design.md
|
||||
|
||||
```
|
||||
|
||||
#### Phase 3: Implementation Planning & Discussion
|
||||
|
||||
**1. Aplicação automática de boas práticas (estilo Kiro)**
|
||||
|
||||
```text
|
||||
|
||||
Claude: "Gerei plano de implementação com aplicação automática das boas práticas do Kiro:
|
||||
|
||||
Estratégia de implementação gerada automaticamente:
|
||||
|
||||
1. Desenvolvimento Security-First
|
||||
- Incorporação automática de contramedidas OWASP Top 10
|
||||
- Implementação automática de criptografia e hashing
|
||||
- Geração automática de testes de segurança
|
||||
|
||||
2. Aplicação forçada de Clean Architecture
|
||||
- Implementação automática de separação de camadas
|
||||
- Aplicação automática de inversão de dependência
|
||||
- Aplicação forçada de design testável
|
||||
|
||||
3. Otimização de performance
|
||||
- Implementação automática de estratégia de cache
|
||||
- Otimização de banco de dados
|
||||
- Utilização de processamento assíncrono
|
||||
|
||||
Proceder com esta abordagem?"
|
||||
|
||||
```
|
||||
|
||||
**2. Configuração automática de pontos de verificação de qualidade**
|
||||
|
||||
```text
|
||||
|
||||
Claude: "Configurei automaticamente pontos de verificação de qualidade para cada etapa de implementação:
|
||||
|
||||
Processo automático de garantia de qualidade:
|
||||
|
||||
Phase 3a: Implementação de Backend
|
||||
|
||||
- [ ] Scan de segurança (SAST/DAST)
|
||||
- [ ] Teste de especificação de API (conformidade OpenAPI)
|
||||
- [ ] Teste de performance (carga e resposta)
|
||||
- [ ] Scan de vulnerabilidades (dependências e CVE)
|
||||
|
||||
Phase 3b: Implementação de Frontend
|
||||
|
||||
- [ ] Teste de acessibilidade (WCAG 2.1 AA)
|
||||
- [ ] Teste de compatibilidade de navegadores
|
||||
- [ ] Verificação de design responsivo
|
||||
- [ ] Confirmação de cabeçalhos de segurança
|
||||
|
||||
Phase 3c: Integração e Deploy
|
||||
|
||||
- [ ] Suite de testes E2E
|
||||
- [ ] Configuração de pipeline CI/CD
|
||||
- [ ] Configuração de monitoramento e logs
|
||||
- [ ] Auditoria de segurança do ambiente de produção
|
||||
|
||||
Tudo será executado automaticamente. Há padrões de qualidade adicionais?"
|
||||
|
||||
```
|
||||
|
||||
**3. Análise automática de dependências e mitigação de riscos**
|
||||
|
||||
```text
|
||||
|
||||
Claude: "Analisei automaticamente a ordem de implementação e estratégias de mitigação de riscos:
|
||||
|
||||
Ordem de implementação otimizada:
|
||||
|
||||
Semana 1: Infraestrutura e base de segurança
|
||||
|
||||
- Design e criação de schema de banco de dados
|
||||
- Base de autenticação (JWT + gerenciamento de sessão)
|
||||
- Implementação de middleware de segurança
|
||||
- Endpoints básicos de API
|
||||
|
||||
Semana 2: Implementação de funcionalidades core
|
||||
|
||||
- Funcionalidade de gerenciamento de usuários
|
||||
- Funcionalidade de gerenciamento de perfil
|
||||
- Sistema de gerenciamento de permissões
|
||||
- Validação e tratamento de erros
|
||||
|
||||
Semana 3: Funcionalidades avançadas e otimização
|
||||
|
||||
- Implementação de autenticação multifator
|
||||
- Funcionalidade de log de auditoria
|
||||
- Otimização de performance
|
||||
- Integração com frontend
|
||||
|
||||
Estratégias de mitigação de riscos detectadas automaticamente:
|
||||
|
||||
- Autenticação multifator: Introdução gradual (SMS→Autenticação por app)
|
||||
- Gerenciamento de sessão: Configuração de cluster Redis
|
||||
- Acesso em massa: Rate limiting + Utilização de CDN
|
||||
- Integridade de dados: Reforço do gerenciamento de transações
|
||||
|
||||
Há problemas com este plano?"
|
||||
|
||||
```
|
||||
|
||||
**4. Conclusão e aprovação da Phase 3**
|
||||
|
||||
```text
|
||||
|
||||
Claude: "Implementation Planning Phase foi concluída.
|
||||
Posso gerar tasks.md?"
|
||||
→ "Próximo passo" → Geração de tasks.md
|
||||
|
||||
```
|
||||
|
||||
### Funcionalidades Específicas do Kiro
|
||||
|
||||
**Notação EARS (Easy Approach to Requirements Syntax)**
|
||||
|
||||
```text
|
||||
# Padrões padrão de notação EARS do Kiro
|
||||
|
||||
WHEN [situação / trigger]
|
||||
GIVEN [precondição]
|
||||
THEN [comportamento do sistema]
|
||||
AND [comportamento adicional]
|
||||
|
||||
WHILE [estado / processo]
|
||||
THE SYSTEM SHALL [comportamento obrigatório]
|
||||
AND [comportamento relacionado]
|
||||
|
||||
WHERE [funcionalidade / componente]
|
||||
IS [condição / estado]
|
||||
THE SYSTEM SHALL [comportamento correspondente]
|
||||
```
|
||||
|
||||
**Funcionalidades de geração automática**
|
||||
|
||||
- **Diagramas Mermaid**: Geração automática de diagramas de arquitetura e fluxo de dados
|
||||
- **Interfaces TypeScript**: Criação automática de definições de tipos baseadas no design
|
||||
- **Boas práticas**: Incorporação automática de contramedidas de segurança e performance
|
||||
- **Pontos de verificação de qualidade**: Configuração automática de padrões de qualidade por etapas
|
||||
|
||||
**Integração hooks**
|
||||
|
||||
- Verificação automática de qualidade ao salvar arquivos
|
||||
- Aplicação automática de padrões de código
|
||||
- Execução automática de scan de segurança
|
||||
- Verificação automática de contramedidas OWASP Top 10
|
||||
|
||||
**Garantia de qualidade protótipo→produção**
|
||||
|
||||
- Design consistente através de abordagem estruturada
|
||||
- Aplicação forçada de desenvolvimento Security-First
|
||||
- Aplicação automática de arquitetura escalável
|
||||
- Incorporação de gerenciamento contínuo de qualidade
|
||||
|
||||
### Observações
|
||||
|
||||
**Escopo de aplicação**
|
||||
|
||||
- Spec Mode é otimizado para implementação de funcionalidades
|
||||
- Para correções simples ou mudanças em pequena escala, use formato de implementação normal
|
||||
- Recomendado para desenvolvimento de novas funcionalidades ou modificações complexas
|
||||
|
||||
**Garantia de qualidade**
|
||||
|
||||
- Clarificação de critérios de conclusão para cada etapa
|
||||
- Revisão de design antes da implementação
|
||||
- Padrões de qualidade abrangentes incluindo testes e acessibilidade
|
||||
|
||||
**Cuidados na execução**
|
||||
|
||||
- Resolver ambiguidades nos requisitos antes de avançar para a etapa de design
|
||||
- Gerar tarefas de implementação após conclusão do design
|
||||
- Valorizar processo de aprovação em cada etapa
|
||||
|
||||
### Frases de Ativação e Controle
|
||||
|
||||
#### Controle de fluxo de trabalho gradual
|
||||
|
||||
**Triggers de início**
|
||||
|
||||
- "Crie spec de [nome da funcionalidade]"
|
||||
- "Quero desenvolver [nome da funcionalidade] orientado por spec"
|
||||
- "Projete [nome da funcionalidade] a partir de especificações"
|
||||
|
||||
**Controle de progressão de fases**
|
||||
|
||||
- **"Próximo passo"**: Conclui a fase atual e gera arquivo, avança para próxima fase
|
||||
- **"Modifique"**: Ajusta e melhora conteúdo dentro da fase atual
|
||||
- **"Refaça"**: Recomeça a fase atual do início
|
||||
- **"Explique detalhadamente"**: Apresenta explicações mais detalhadas ou opções
|
||||
- **"Pule"**: Pula a fase atual e vai para a próxima (não recomendado)
|
||||
|
||||
**Timing de geração de arquivos**
|
||||
|
||||
```text
|
||||
Conclusão Phase 1 → "Próximo passo" → Geração de requirements.md
|
||||
Conclusão Phase 2 → "Próximo passo" → Geração de design.md
|
||||
Conclusão Phase 3 → "Próximo passo" → Geração de tasks.md
|
||||
```
|
||||
|
||||
### Exemplo de Execução (Fluxo Gradual)
|
||||
|
||||
```bash
|
||||
# Exemplo de uso
|
||||
Usuário: "Crie spec de sistema de gerenciamento de usuários"
|
||||
|
||||
# Phase 1: Requirements Discovery
|
||||
Claude: [Início de confirmação e discussão de requisitos]
|
||||
Usuário: [Resposta, discussão, modificação]
|
||||
Claude: "Requirements Phase foi concluída. Posso avançar?"
|
||||
Usuário: "Próximo passo"
|
||||
→ Geração de requirements.md
|
||||
|
||||
# Phase 2: Design Exploration
|
||||
Claude: [Início de proposta e discussão de design]
|
||||
Usuário: [Discussão de escolhas técnicas / arquitetura]
|
||||
Claude: "Design Phase foi concluída. Posso avançar?"
|
||||
Usuário: "Próximo passo"
|
||||
→ Geração de design.md
|
||||
|
||||
# Phase 3: Implementation Planning
|
||||
Claude: [Início de discussão de plano de implementação]
|
||||
Usuário: [Discussão de prioridades, riscos, esforço]
|
||||
Claude: "Implementation Phase foi concluída. Posso avançar?"
|
||||
Usuário: "Próximo passo"
|
||||
→ Geração de tasks.md
|
||||
|
||||
# Conclusão
|
||||
Claude: "Preparação para spec-driven development concluída. Pode iniciar a implementação."
|
||||
```
|
||||
|
||||
### Diferenças com /plan
|
||||
|
||||
| Característica | /plan | /spec |
|
||||
| ----------------------- | -------------------------------- | ------------------------------------------------------------------------- |
|
||||
| Objetivo | Plano geral de implementação | Desenvolvimento orientado por especificação funcional |
|
||||
| Formato de saída | Documento de plano único | 3 arquivos independentes (requirements.md, design.md, tasks.md) |
|
||||
| Definição de requisitos | Organização básica de requisitos | Critérios de aceitação detalhados usando notação EARS |
|
||||
| Design | Foco em seleção técnica | Baseado em análise de codebase |
|
||||
| Implementação | Decomposição geral de tarefas | Sequência considerando dependências |
|
||||
| Garantia de qualidade | Estratégia básica de testes | Requisitos abrangentes de qualidade (testes, acessibilidade, performance) |
|
||||
| Sincronização | Plano estático | Atualização dinâmica de spec |
|
||||
|
||||
### Casos de Uso Recomendados
|
||||
|
||||
**Uso recomendado de spec**
|
||||
|
||||
- Desenvolvimento de novas funcionalidades
|
||||
- Modificações complexas de funcionalidades
|
||||
- Design de API
|
||||
- Design de banco de dados
|
||||
- Implementação de UI/UX
|
||||
|
||||
**Uso recomendado de plan**
|
||||
|
||||
- Design de sistema geral
|
||||
- Construção de infraestrutura
|
||||
- Refatoração
|
||||
- Seleção técnica
|
||||
- Mudanças de arquitetura
|
||||
186
commands/style-ai-writing.md
Normal file
186
commands/style-ai-writing.md
Normal file
@@ -0,0 +1,186 @@
|
||||
## AI Writing Check
|
||||
|
||||
Detecta padrões mecânicos de textos gerados por IA e propõe melhorias para um português mais natural.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
/ai-writing-check [opções]
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- nenhuma : Analisa o arquivo atual ou texto selecionado
|
||||
- `--file <path>` : Analisa arquivo específico
|
||||
- `--dir <path>` : Análise em lote de arquivos no diretório
|
||||
- `--severity <level>` : Nível de detecção (all/high/medium)
|
||||
- `--fix` : Corrige automaticamente padrões detectados
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# Verificar artificialidade de IA no arquivo
|
||||
cat README.md
|
||||
/ai-writing-check
|
||||
"Verifique a artificialidade de IA neste documento e apresente sugestões de melhoria"
|
||||
|
||||
# Análise de arquivo específico
|
||||
/ai-writing-check --file docs/guide.md
|
||||
"Detecte expressões que parecem IA e sugira correções para expressões naturais"
|
||||
|
||||
# Escaneamento de projeto inteiro
|
||||
/ai-writing-check --dir . --severity high
|
||||
"Reporte apenas problemas importantes de artificialidade de IA no projeto"
|
||||
```
|
||||
|
||||
### Padrões de detecção
|
||||
|
||||
#### 1. Padrões mecânicos de formato de lista
|
||||
|
||||
```markdown
|
||||
Exemplos detectados:
|
||||
|
||||
- **Importante**: Este é um item importante
|
||||
- Item concluído (com marca de verificação)
|
||||
- Tópico quente (com emoji de fogo)
|
||||
- Pronto para início (com emoji de foguete)
|
||||
|
||||
Exemplos melhorados:
|
||||
|
||||
- Item importante: Este é um item importante
|
||||
- Item concluído
|
||||
- Tópico em destaque
|
||||
- Pronto para início
|
||||
```
|
||||
|
||||
#### 2. Expressões exageradas e de hype
|
||||
|
||||
```markdown
|
||||
Exemplos detectados:
|
||||
Revolucionará a indústria com tecnologia revolucionária.
|
||||
Isso resolverá completamente o problema.
|
||||
Funciona como mágica.
|
||||
|
||||
Exemplos melhorados:
|
||||
Trará mudanças à indústria com tecnologia eficaz.
|
||||
Resolve muitos problemas.
|
||||
Funciona de forma fluida.
|
||||
```
|
||||
|
||||
#### 3. Padrões mecânicos de ênfase
|
||||
|
||||
```markdown
|
||||
Exemplos detectados:
|
||||
**Ideia**: Há uma nova proposta (com emoji de lâmpada)
|
||||
**Atenção**: Aviso importante (com emoji de alerta)
|
||||
|
||||
Exemplos melhorados:
|
||||
Ideia: Há uma nova proposta
|
||||
Observação: Aviso importante
|
||||
```
|
||||
|
||||
#### 4. Escrita técnica redundante
|
||||
|
||||
```markdown
|
||||
Exemplos detectados:
|
||||
Primeiro, vamos configurar as configurações.
|
||||
Você pode usar esta ferramenta.
|
||||
O desempenho melhora significativamente.
|
||||
|
||||
Exemplos melhorados:
|
||||
Primeiro, vamos configurar.
|
||||
Você pode usar esta ferramenta.
|
||||
O desempenho melhora 30%.
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise de artificialidade de IA do documento inteiro
|
||||
cat article.md
|
||||
/ai-writing-check
|
||||
"Analise sob os seguintes aspectos e apresente sugestões de melhoria:
|
||||
1. Detecção de expressões mecânicas
|
||||
2. Sugestões de correção para português natural
|
||||
3. Lista de melhorias por prioridade"
|
||||
|
||||
# Foco em padrões específicos
|
||||
/ai-writing-check --file blog.md
|
||||
"Foque especialmente em expressões exageradas e expressões redundantes para sugerir melhorias"
|
||||
|
||||
# Verificação em lote de múltiplos arquivos
|
||||
find . -name "*.md" -type f
|
||||
/ai-writing-check --dir docs/
|
||||
"Analise a artificialidade de IA de toda a documentação e crie resumo"
|
||||
```
|
||||
|
||||
### Exemplos detalhados
|
||||
|
||||
```bash
|
||||
# Comparação antes e depois das melhorias
|
||||
/ai-writing-check --file draft.md
|
||||
"Detecte expressões que parecem IA e apresente no seguinte formato:
|
||||
- Partes problemáticas (com número da linha)
|
||||
- Tipo e motivo do problema
|
||||
- Sugestão específica de melhoria
|
||||
- Efeito da melhoria"
|
||||
|
||||
# Modo de correção automática
|
||||
/ai-writing-check --file report.md --fix
|
||||
"Corrija automaticamente padrões detectados e relate resultados"
|
||||
|
||||
# Relatório de artificialidade de IA do projeto
|
||||
/ai-writing-check --dir . --severity all
|
||||
"Analise a artificialidade de IA de todo o projeto e forneça:
|
||||
1. Informações estatísticas (número de detecções por padrão)
|
||||
2. TOP 5 arquivos mais problemáticos
|
||||
3. Matrix de prioridade de melhoria
|
||||
4. Plano de melhoria em fases"
|
||||
```
|
||||
|
||||
### Exemplos de uso avançado
|
||||
|
||||
```bash
|
||||
# Aplicação de regras personalizadas
|
||||
/ai-writing-check --file spec.md
|
||||
"Verifique como especificação técnica com os seguintes critérios adicionais:
|
||||
- Expressões ambíguas (adequado, conforme necessário)
|
||||
- Falta de especificidade (rápido → valores numéricos específicos)
|
||||
- Uso inconsistente de terminologia"
|
||||
|
||||
# Verificação para integração CI/CD
|
||||
/ai-writing-check --dir docs/ --severity high
|
||||
"Gere resultados em formato executável pelo GitHub Actions:
|
||||
- Número de erros e nomes de arquivos
|
||||
- Números de linha que precisam de correção
|
||||
- Configuração de exit code"
|
||||
|
||||
# Verificação de conformidade com guia de estilo
|
||||
/ai-writing-check --file manual.md
|
||||
"Verificação adicional baseada no guia de estilo da empresa:
|
||||
- Uso de linguagem formal (unificação de tom formal)
|
||||
- Uso adequado de terminologia especializada
|
||||
- Consideração pelo leitor"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
- A determinação de artificialidade de IA varia conforme o contexto, então trate as sugestões como referência
|
||||
- Ajuste os critérios conforme o tipo de documento: documentos técnicos, blogs, manuais, etc.
|
||||
- Não é necessário aceitar todas as sugestões; selecione as apropriadas
|
||||
- A opção `--fix` corrige automaticamente padrões detectados
|
||||
|
||||
### Comportamento na execução do comando
|
||||
|
||||
Quando o comando `/ai-writing-check` é executado, Claude realiza os seguintes processos:
|
||||
|
||||
1. **Detecção de padrões**: Detecta padrões que parecem IA nos arquivos ou textos especificados
|
||||
2. **Sugestões específicas de correção**: Apresenta sugestões de correção com número de linha para cada problema
|
||||
3. **Modo --fix**: Corrige automaticamente padrões detectados e exibe resumo dos resultados
|
||||
4. **Geração de relatório**: Fornece número de detecções, prioridade de melhoria e comparação antes/depois
|
||||
|
||||
Claude lê o conteúdo real dos arquivos e executa análise baseada nas regras do textlint-rule-preset-ai-writing.
|
||||
|
||||
### Referência
|
||||
|
||||
Este comando foi criado com base no conjunto de regras do [textlint-rule-preset-ai-writing](https://github.com/textlint-ja/textlint-rule-preset-ai-writing). É um preset de regras textlint para detectar padrões mecânicos de textos gerados por IA e promover expressões mais naturais.
|
||||
223
commands/task.md
Normal file
223
commands/task.md
Normal file
@@ -0,0 +1,223 @@
|
||||
## Task
|
||||
|
||||
Inicia um agente especializado para executar autonomamente tarefas complexas de pesquisa, investigação e análise. Processamento de informações em larga escala combinando múltiplas ferramentas, priorizando eficiência contextual.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Solicitar Task ao Claude
|
||||
"Investigue [problema] usando Task"
|
||||
```
|
||||
|
||||
### Características do Task
|
||||
|
||||
**Execução Autônoma**
|
||||
|
||||
- Execução automática combinando múltiplas ferramentas
|
||||
- Coleta e análise de informações em etapas
|
||||
- Integração de resultados e relatórios estruturados
|
||||
|
||||
**Processamento Eficiente de Informações**
|
||||
|
||||
- Otimização do consumo de contexto
|
||||
- Busca e análise de arquivos em larga escala
|
||||
- Coleta de dados de fontes externas
|
||||
|
||||
**Garantia de Qualidade**
|
||||
|
||||
- Verificação da confiabilidade das fontes de informação
|
||||
- Validação de múltiplas perspectivas
|
||||
- Complementação automática de informações ausentes
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Investigação de codebase complexo
|
||||
"Investigue em quais arquivos esta funcionalidade está implementada usando Task"
|
||||
|
||||
# Busca em larga escala de arquivos
|
||||
"Identifique inconsistências nos arquivos de configuração usando Task"
|
||||
|
||||
# Coleta de informações externas
|
||||
"Investigue as tendências mais recentes de tecnologia IA usando Task"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise de problemas complexos
|
||||
"Analise a causa do vazamento de memória usando Task. Inclua resultados de profiling e logs"
|
||||
|
||||
# Investigação de dependências
|
||||
"Investigue vulnerabilidades neste pacote npm usando Task"
|
||||
|
||||
# Análise competitiva
|
||||
"Investigue as especificações da API de serviços concorrentes usando Task"
|
||||
|
||||
# Análise de arquitetura
|
||||
"Analise as dependências deste microsserviço usando Task"
|
||||
```
|
||||
|
||||
### Diferenciação de Outros Comandos
|
||||
|
||||
#### Task vs Outros Comandos
|
||||
|
||||
| Comando | Uso Principal | Método de Execução | Coleta de Informações |
|
||||
| ------------------- | ------------------------------------- | ---------------------- | ---------------------------------- |
|
||||
| **Task** | Investigação, Análise e Busca | Execução autônoma | Múltiplas fontes |
|
||||
| ultrathink | Pensamento e Julgamento profundo | Pensamento estruturado | Centrado em conhecimento existente |
|
||||
| sequential-thinking | Resolução de problemas e Design | Pensamento por etapas | Conforme necessário |
|
||||
| plan | Elaboração de planos de implementação | Processo de aprovação | Análise de requisitos |
|
||||
|
||||
#### Fluxograma de Decisão
|
||||
|
||||
```text
|
||||
Coleta de informações necessária?
|
||||
├─ Sim → Múltiplas fontes / Larga escala?
|
||||
│ ├─ Sim → **Task**
|
||||
│ └─ Não → Pergunta normal
|
||||
└─ Não → Pensamento profundo necessário?
|
||||
├─ Sim → ultrathink/sequential-thinking
|
||||
└─ Não → Pergunta normal
|
||||
```
|
||||
|
||||
### Casos Efetivos e Casos Desnecessários
|
||||
|
||||
**Casos Efetivos**
|
||||
|
||||
- Investigação de codebase complexo (dependências, análise de arquitetura)
|
||||
- Busca de arquivos em larga escala (padrões de implementação específicos, arquivos de configuração)
|
||||
- Coleta e organização de informações externas (tendências tecnológicas, investigação de bibliotecas)
|
||||
- Integração de informações de múltiplas fontes (análise de logs, análise de métricas)
|
||||
- Trabalho de investigação iterativo (auditoria de segurança, investigação de débito técnico)
|
||||
- Análise em larga escala evitando consumo de contexto
|
||||
|
||||
**Casos Desnecessários**
|
||||
|
||||
- Perguntas simples ou conteúdo que pode ser respondido com conhecimento existente
|
||||
- Trabalho pontual que se completa em pouco tempo
|
||||
- Trabalho que requer confirmação ou consulta interativa
|
||||
- Julgamento de implementação ou design (apropriado usar plan ou comandos de pensamento)
|
||||
|
||||
### Exemplos Detalhados por Categoria
|
||||
|
||||
#### Análise e Investigação de Sistema
|
||||
|
||||
```bash
|
||||
# Análise complexa de sistema
|
||||
"Identifique gargalos do site de e-commerce usando Task. Investigue todo o conjunto: banco de dados, API, frontend"
|
||||
|
||||
# Análise de arquitetura
|
||||
"Analise as dependências deste microsserviço usando Task. Inclua comunicação API e fluxo de dados"
|
||||
|
||||
# Investigação de débito técnico
|
||||
"Analise o débito técnico do código legado usando Task. Inclua prioridade de refatoração"
|
||||
```
|
||||
|
||||
#### Segurança e Conformidade
|
||||
|
||||
```bash
|
||||
# Auditoria de segurança
|
||||
"Investigue vulnerabilidades desta aplicação usando Task. Base no OWASP Top 10"
|
||||
|
||||
# Investigação de licenças
|
||||
"Investigue problemas de licença das dependências do projeto usando Task"
|
||||
|
||||
# Auditoria de arquivos de configuração
|
||||
"Identifique inconsistências nas configurações de segurança usando Task. Inclua diferenças entre ambientes"
|
||||
```
|
||||
|
||||
#### Performance e Otimização
|
||||
|
||||
```bash
|
||||
# Análise de performance
|
||||
"Identifique queries pesadas da aplicação usando Task. Inclua plano de execução e propostas de otimização"
|
||||
|
||||
# Investigação de uso de recursos
|
||||
"Investigue a causa do vazamento de memória usando Task. Inclua resultados de profiling e análise de código"
|
||||
|
||||
# Análise de tamanho de bundle
|
||||
"Investigue problemas de tamanho de bundle do frontend usando Task. Inclua propostas de otimização"
|
||||
```
|
||||
|
||||
#### Coleta de Informações Externas
|
||||
|
||||
```bash
|
||||
# Investigação de tendências tecnológicas
|
||||
"Investigue as tendências de frameworks JavaScript de 2024 usando Task"
|
||||
|
||||
# Análise competitiva
|
||||
"Investigue especificações da API de serviços concorrentes usando Task. Inclua tabela de comparação de funcionalidades"
|
||||
|
||||
# Avaliação de bibliotecas
|
||||
"Compare bibliotecas de gerenciamento de estado usando Task. Inclua performance e custo de aprendizado"
|
||||
```
|
||||
|
||||
### Fluxo de Execução e Garantia de Qualidade
|
||||
|
||||
#### Fluxo de Execução do Task
|
||||
|
||||
```text
|
||||
1. Análise inicial
|
||||
├─ Decomposição do problema e identificação do escopo da investigação
|
||||
├─ Seleção de ferramentas e fontes de informação necessárias
|
||||
└─ Elaboração do plano de execução
|
||||
|
||||
2. Coleta de informações
|
||||
├─ Busca de arquivos e Análise de código
|
||||
├─ Coleta de informações externas
|
||||
└─ Estruturação de dados
|
||||
|
||||
3. Análise e Integração
|
||||
├─ Análise de correlação das informações coletadas
|
||||
├─ Identificação de padrões e pontos problemáticos
|
||||
└─ Verificação de hipóteses
|
||||
|
||||
4. Relatório e Propostas
|
||||
├─ Estruturação de resultados
|
||||
├─ Criação de propostas de melhoria
|
||||
└─ Apresentação das próximas ações
|
||||
```
|
||||
|
||||
#### Garantia de Qualidade
|
||||
|
||||
- **Verificação de Confiabilidade das Fontes**: Verificação de fatos com múltiplas fontes
|
||||
- **Confirmação de Abrangência**: Verificação se não há lacunas no objeto de investigação
|
||||
- **Verificação de Consistência**: Confirmação de consistência de informações contraditórias
|
||||
- **Avaliação de Praticidade**: Avaliação da viabilidade e efetividade das propostas
|
||||
|
||||
### Tratamento de Erros e Restrições
|
||||
|
||||
#### Restrições Comuns
|
||||
|
||||
- **Limitações de uso de API externa**: Limitações de taxa ou erros de autenticação
|
||||
- **Limitações de processamento de arquivos de grande capacidade**: Restrições de memória ou timeout
|
||||
- **Problemas de permissão de acesso**: Restrições de acesso a arquivos ou diretórios
|
||||
|
||||
#### Tratamento em Caso de Erro
|
||||
|
||||
- **Relatório de resultados parciais**: Análise apenas com informações que puderam ser obtidas
|
||||
- **Proposta de métodos alternativos**: Métodos de investigação alternativos sob restrições
|
||||
- **Execução em etapas**: Execução dividida de tarefas de larga escala
|
||||
|
||||
### Observações
|
||||
|
||||
- Task é ideal para tarefas de investigação e análise complexas e autônomas
|
||||
- Para perguntas simples ou quando respostas imediatas são necessárias, use o formato de pergunta normal
|
||||
- Trate os resultados da investigação como informações de referência e sempre verifique julgamentos importantes
|
||||
- Ao coletar informações externas, preste atenção à atualidade e precisão das informações
|
||||
|
||||
### Exemplo de Execução
|
||||
|
||||
```bash
|
||||
# Exemplo de uso
|
||||
"Investigue problemas do esquema GraphQL usando Task"
|
||||
|
||||
# Comportamento esperado
|
||||
# 1. Agente especializado é iniciado
|
||||
# 2. Busca de arquivos relacionados ao GraphQL
|
||||
# 3. Análise de definições de esquema
|
||||
# 4. Comparação com melhores práticas
|
||||
# 5. Identificação de problemas e propostas de melhoria
|
||||
# 6. Criação de relatório estruturado
|
||||
```
|
||||
185
commands/tech-debt.md
Normal file
185
commands/tech-debt.md
Normal file
@@ -0,0 +1,185 @@
|
||||
## Tech Debt
|
||||
|
||||
Analisa quantitativamente a dívida técnica do projeto e visualiza as pontuações de saúde junto com o impacto na eficiência de desenvolvimento. Acompanha melhorias mediante análise de tendências, calcula custos temporais e cria um plano de melhoria priorizado.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Verificar configuração do projeto para analisar dívida técnica
|
||||
ls -la
|
||||
"Analisar a dívida técnica deste projeto e criar um plano de melhoria"
|
||||
```
|
||||
|
||||
### Painel de Saúde do Projeto
|
||||
|
||||
```text
|
||||
Pontuação de Saúde do Projeto: 72/100
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
📊 Pontuações por Categoria
|
||||
├─ Frescor das dependências: ████████░░ 82% (Atualizadas: 45/55)
|
||||
├─ Completude da documentação: ███░░░░░░░ 35% (Faltam README, docs API)
|
||||
├─ Cobertura de testes: ██████░░░░ 65% (Meta: 80%)
|
||||
├─ Segurança: ███████░░░ 78% (Vulnerabilidades: 2 Medium)
|
||||
├─ Arquitetura: ██████░░░░ 60% (Dependências circulares: 3 lugares)
|
||||
└─ Qualidade do código: ███████░░░ 70% (Complexidade alta: 12 arquivos)
|
||||
|
||||
📈 Tendências (últimos 30 dias)
|
||||
├─ Pontuação geral: 68 → 72 (+4) ↗️
|
||||
├─ Itens melhorados: 12 ✅
|
||||
├─ Nova dívida: 3 ⚠️
|
||||
├─ Dívida resolvida: 8 🎉
|
||||
└─ Velocidade de melhoria: +0.13/dia
|
||||
|
||||
⏱️ Impacto temporal da dívida
|
||||
├─ Desaceleração do desenvolvimento: -20% (desenvolvimento de novas funcionalidades leva 1.25x o tempo normal)
|
||||
├─ Tempo de correção de bugs: +15% (tempo médio de correção 2h → 2.3h)
|
||||
├─ Revisão de código: +30% (tempo adicional por complexidade)
|
||||
├─ Onboarding: +50% (tempo necessário para novos membros entenderem)
|
||||
└─ Tempo de atraso acumulado: Equivalente a 40 horas/semana
|
||||
|
||||
🎯 Efeitos esperados da melhoria (baseados em tempo)
|
||||
├─ Efeito imediato: Velocidade de desenvolvimento +10% (após 1 semana)
|
||||
├─ Efeito a curto prazo: Taxa de bugs -25% (após 1 mês)
|
||||
├─ Efeito a médio prazo: Velocidade de desenvolvimento +30% (após 3 meses)
|
||||
├─ Efeito a longo prazo: Tempo de manutenção -50% (após 6 meses)
|
||||
└─ ROI: Investimento 40 horas → Recuperação 120 horas (3 meses)
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Análise detalhada da pontuação de saúde
|
||||
find . -name "*.js" -o -name "*.ts" | xargs wc -l | sort -rn | head -10
|
||||
"Calcular a pontuação de saúde do projeto e avaliar por categorias"
|
||||
|
||||
# Análise de impacto de dívida de TODO/FIXME
|
||||
grep -r "TODO\|FIXME\|HACK\|XXX\|WORKAROUND" . --exclude-dir=node_modules --exclude-dir=.git
|
||||
"Avaliar estes TODOs por impacto de dívida (tempo×importância)"
|
||||
|
||||
# Verificação de saúde das dependências
|
||||
ls -la | grep -E "package.json|Cargo.toml|pubspec.yaml|go.mod|requirements.txt"
|
||||
"Calcular pontuação de frescor das dependências e analisar riscos e efeitos de atualizações"
|
||||
```
|
||||
|
||||
### Colaboração com Claude
|
||||
|
||||
```bash
|
||||
# Análise integral de dívida técnica
|
||||
ls -la && find . -name "*.md" -maxdepth 2 -exec head -20 {} \;
|
||||
"Analisar a dívida técnica deste projeto sob essas perspectivas:
|
||||
1. Qualidade do código (complexidade, duplicação, manutenibilidade)
|
||||
2. Saúde das dependências
|
||||
3. Riscos de segurança
|
||||
4. Problemas de desempenho
|
||||
5. Falta de cobertura de testes"
|
||||
|
||||
# Análise de dívida arquitetural
|
||||
find . -type d -name "src" -o -name "lib" -o -name "app" | head -10 | xargs ls -la
|
||||
"Identificar dívida técnica no nível arquitetural e propor um plano de refatoração"
|
||||
|
||||
# Plano de melhoria priorizado
|
||||
"Avaliar a dívida técnica segundo esses critérios e apresentar em formato de tabela:
|
||||
- Impacto (Alto/Médio/Baixo)
|
||||
- Custo de correção (tempo)
|
||||
- Risco técnico (possibilidade de falha do sistema, perda de dados)
|
||||
- Efeito de redução de tempo por melhoria
|
||||
- Momento recomendado de implementação"
|
||||
```
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Detecção automática do tipo de projeto e análise
|
||||
find . -maxdepth 2 -type f \( -name "package.json" -o -name "Cargo.toml" -o -name "pubspec.yaml" -o -name "go.mod" -o -name "pom.xml" \)
|
||||
"Baseado no tipo de projeto detectado, analisar:
|
||||
1. Dívida técnica específica da linguagem/framework
|
||||
2. Desvios das melhores práticas
|
||||
3. Oportunidades de modernização
|
||||
4. Estratégia de melhoria gradual"
|
||||
|
||||
# Análise de métricas de qualidade do código
|
||||
find . -type f -name "*" | grep -E "\.(js|ts|py|rs|go|dart|kotlin|swift|java)$" | wc -l
|
||||
"Analisar a qualidade do código do projeto e apresentar essas métricas:
|
||||
- Funções com alta complexidade ciclomática
|
||||
- Detecção de código duplicado
|
||||
- Arquivos/funções muito longos
|
||||
- Falta de tratamento de erro adequado"
|
||||
|
||||
# Detecção de dívida de segurança
|
||||
grep -r "password\|secret\|key\|token" . --exclude-dir=.git --exclude-dir=node_modules | grep -v ".env.example"
|
||||
"Detectar dívida técnica relacionada à segurança e propor prioridade de correção e contramedidas"
|
||||
|
||||
# Análise de falta de testes
|
||||
find . -type f \( -name "*test*" -o -name "*spec*" \) | wc -l && find . -type f -name "*.md" | xargs grep -l "test"
|
||||
"Analisar a dívida técnica de cobertura de testes e propor estratégia de testes"
|
||||
```
|
||||
|
||||
### Matriz de Prioridades da Dívida
|
||||
|
||||
```text
|
||||
Prioridade = (Impacto × Frequência) ÷ Custo de correção
|
||||
```
|
||||
|
||||
| Prioridade | Impacto no desenvolvimento | Custo de correção | Efeito de redução de tempo | Retorno do investimento | Prazo de resposta |
|
||||
| -------------------------- | -------------------------- | ----------------- | -------------------------- | ----------------------------- | ------------------ |
|
||||
| **[P0] Resposta imediata** | Alto | Baixo | > 5x | Investimento 1h→Redução 5h+ | Imediato |
|
||||
| **[P1] Esta semana** | Alto | Médio | 2-5x | Investimento 1h→Redução 2-5h | Dentro de 1 semana |
|
||||
| **[P2] Este mês** | Baixo | Alto | 1-2x | Investimento 1h→Redução 1-2h | Dentro de 1 mês |
|
||||
| **[P3] Este trimestre** | Baixo | Baixo | < 1x | Investimento=tempo de redução | Dentro de 3 meses |
|
||||
|
||||
### Critérios de Avaliação por Tipo de Dívida
|
||||
|
||||
| Tipo de dívida | Método de detecção | Impacto no desenvolvimento | Tempo de correção |
|
||||
| --------------------------------- | ----------------------------------------- | --------------------------------------------------- | ----------------- |
|
||||
| **Dívida arquitetural** | Dependências circulares, alto acoplamento | Grande escopo de impacto em mudanças, teste difícil | 40-80h |
|
||||
| **Dívida de segurança** | Scan CVE, OWASP | Risco de vulnerabilidades, conformidade | 8-40h |
|
||||
| **Dívida de desempenho** | N+1, vazamentos de memória | Aumento tempo de resposta, consumo de recursos | 16-40h |
|
||||
| **Dívida de testes** | Cobertura < 60% | Detecção tardia de bugs, qualidade instável | 20-60h |
|
||||
| **Dívida de documentação** | Falta README, docs API | Tempo de onboarding aumentado | 8-24h |
|
||||
| **Dívida de dependências** | Não atualizadas por 2+ anos | Risco de segurança, problemas de compatibilidade | 4-16h |
|
||||
| **Dívida de qualidade do código** | Complexidade > 10 | Tempo de compreensão/correção aumentado | 2-8h |
|
||||
|
||||
### Cálculo de Impacto da Dívida Técnica
|
||||
|
||||
```text
|
||||
Impacto = Σ(peso de cada elemento × valor medido)
|
||||
|
||||
📊 Indicadores de impacto mensuráveis:
|
||||
├─ Impacto na velocidade de desenvolvimento
|
||||
│ ├─ Tempo de compreensão do código: +X% (proporcional à complexidade)
|
||||
│ ├─ Escopo de impacto em mudanças: Y arquivos (medido por acoplamento)
|
||||
│ └─ Tempo de execução de testes: Z minutos (pipeline CI/CD)
|
||||
│
|
||||
├─ Impacto na qualidade
|
||||
│ ├─ Taxa de ocorrência de bugs: +25% a cada 10 de complexidade
|
||||
│ ├─ Tempo de revisão: linhas de código × coeficiente de complexidade
|
||||
│ └─ Risco por falta de testes: Alto risco se cobertura < 60%
|
||||
│
|
||||
└─ Impacto na eficiência da equipe
|
||||
├─ Tempo de onboarding: +100% por falta de documentação
|
||||
├─ Concentração de conhecimento: Atenção necessária se taxa de contribuidor único >80%
|
||||
└─ Locais de correção por duplicação de código: taxa de duplicação × frequência de mudança
|
||||
```
|
||||
|
||||
### Cálculo de ROI baseado em tempo
|
||||
|
||||
```text
|
||||
ROI = (tempo reduzido - tempo de investimento) ÷ tempo de investimento × 100
|
||||
|
||||
Exemplo: Resolução de dependências circulares
|
||||
├─ Tempo de investimento: 16 horas (refatoração)
|
||||
├─ Efeito de redução (mensal):
|
||||
│ ├─ Tempo de compilação: -10 min/dia × 20 dias = 200 min
|
||||
│ ├─ Tempo de debugging: -2 horas/semana × 4 semanas = 8 horas
|
||||
│ └─ Adição de novas funcionalidades: -30% redução de tempo = 12 horas
|
||||
├─ Tempo de redução mensal: 23.3 horas
|
||||
└─ ROI em 3 meses: (70 - 16) ÷ 16 × 100 = 337%
|
||||
```
|
||||
|
||||
### Notas
|
||||
|
||||
- Auto-detecta a linguagem e framework do projeto para realizar análises específicas
|
||||
- Avalia a pontuação de saúde em escala de 0-100 pontos, considerando saudável 70+ pontos e necessitando melhoria <50 pontos
|
||||
- Calcula custos temporais e efeitos de melhoria de forma específica, apoiando tomada de decisão baseada em dados
|
||||
- Para conversão monetária, especificar separadamente o salário médio por hora da equipe ou coeficientes específicos do projeto
|
||||
242
commands/token-efficient.md
Normal file
242
commands/token-efficient.md
Normal file
@@ -0,0 +1,242 @@
|
||||
# Modo Eficiência de Tokens
|
||||
|
||||
Reduz o uso de contexto nas respostas da IA em 30-50% através do modo de eficiência por compressão.
|
||||
|
||||
## Visão Geral
|
||||
|
||||
O Modo Eficiência de Tokens utiliza sistemas de símbolos visuais e abreviações para comprimir as respostas do Claude.
|
||||
**A qualidade do código gerado e o conteúdo permanecem inalterados**. Apenas o método de explicação é alterado.
|
||||
|
||||
## Como Usar
|
||||
|
||||
```bash
|
||||
# Ativar modo
|
||||
"Responda no Modo Eficiência de Tokens"
|
||||
"--uc mode"
|
||||
"Modo conciso"
|
||||
```
|
||||
|
||||
## Como Funciona
|
||||
|
||||
### 1. Sistema de Símbolos
|
||||
|
||||
#### Lógica e Fluxo
|
||||
|
||||
| Símbolo | Significado | Exemplo |
|
||||
| ------- | -------------------- | ------------------------------------ |
|
||||
| → | leva a, causa | `auth.js:45 → 🛡️ risco de segurança` |
|
||||
| ⇒ | converte para | `entrada ⇒ saida_validada` |
|
||||
| ← | reversão, voltar | `migration ← rollback` |
|
||||
| ⇄ | bidirecional | `sync ⇄ remoto` |
|
||||
| & | e, combinar | `🛡️ segurança & ⚡ performance` |
|
||||
| \| | ou, separador | `react\|vue\|angular` |
|
||||
| : | definir, especificar | `escopo: arquivo\|módulo` |
|
||||
| » | então, sequência | `build » test » deploy` |
|
||||
| ∴ | portanto | `testes ❌ ∴ código quebrado` |
|
||||
| ∵ | porque | `lento ∵ algoritmo O(n²)` |
|
||||
|
||||
#### Status e Progresso
|
||||
|
||||
| Símbolo | Significado | Uso |
|
||||
| ------- | ----------------- | ---------------------------- |
|
||||
| ✅ | completo, sucesso | Tarefa concluída normalmente |
|
||||
| ❌ | falhou, erro | Ação imediata necessária |
|
||||
| ⚠️ | aviso | Revisão recomendada |
|
||||
| 🔄 | em andamento | Atualmente ativo |
|
||||
| ⏳ | pendente | Agendado para depois |
|
||||
| 🚨 | urgente, crítico | Alta prioridade |
|
||||
|
||||
#### Domínios Técnicos
|
||||
|
||||
| Símbolo | Domínio | Uso |
|
||||
| ------- | -------------- | ------------------------- |
|
||||
| ⚡ | Performance | Velocidade, otimização |
|
||||
| 🔍 | Análise | Busca, investigação |
|
||||
| 🔧 | Configuração | Setup, ferramentas |
|
||||
| 🛡️ | Segurança | Proteção, segurança |
|
||||
| 📦 | Deploy | Pacote, bundle |
|
||||
| 🎨 | Design | UI, frontend |
|
||||
| 🏗️ | Arquitetura | Estrutura do sistema |
|
||||
| 🗄️ | Banco de Dados | Persistência de dados |
|
||||
| ⚙️ | Backend | Processamento do servidor |
|
||||
| 🧪 | Testes | Garantia de qualidade |
|
||||
|
||||
### 2. Sistema de Abreviações
|
||||
|
||||
#### Sistema e Arquitetura
|
||||
|
||||
- `cfg` → configuração
|
||||
- `impl` → implementação
|
||||
- `arq` → arquitetura
|
||||
- `perf` → performance
|
||||
- `ops` → operações
|
||||
- `env` → ambiente
|
||||
|
||||
#### Processo de Desenvolvimento
|
||||
|
||||
- `req` → requisitos
|
||||
- `deps` → dependências
|
||||
- `val` → validação
|
||||
- `auth` → autenticação
|
||||
- `docs` → documentação
|
||||
- `std` → padrões
|
||||
|
||||
#### Qualidade e Análise
|
||||
|
||||
- `qual` → qualidade
|
||||
- `seg` → segurança
|
||||
- `err` → erro
|
||||
- `rec` → recuperação
|
||||
- `sev` → severidade
|
||||
- `opt` → otimização
|
||||
|
||||
## Exemplos de Comparação
|
||||
|
||||
### Exemplo 1: Relatório de Erro
|
||||
|
||||
**Modo Normal (95 caracteres)**
|
||||
|
||||
```text
|
||||
Vulnerabilidade de segurança encontrada na função de validação do usuário na linha 45 do sistema auth.
|
||||
```
|
||||
|
||||
**Token Eficiente (44 caracteres)**
|
||||
|
||||
```text
|
||||
auth.js:45 → 🛡️ vuln seg na val() usuário
|
||||
```
|
||||
|
||||
### Exemplo 2: Status de Build
|
||||
|
||||
**Modo Normal (118 caracteres)**
|
||||
|
||||
```text
|
||||
Processo de build foi concluído com sucesso. Testes estão sendo executados atualmente, seguidos pelo deploy.
|
||||
```
|
||||
|
||||
**Token Eficiente (38 caracteres)**
|
||||
|
||||
```text
|
||||
build ✅ » teste 🔄 » deploy ⏳
|
||||
```
|
||||
|
||||
### Exemplo 3: Análise de Performance
|
||||
|
||||
**Modo Normal (105 caracteres)**
|
||||
|
||||
```text
|
||||
Análise de performance revelou processamento lento devido à complexidade do algoritmo O(n²).
|
||||
```
|
||||
|
||||
**Token Eficiente (46 caracteres)**
|
||||
|
||||
```text
|
||||
⚡ perf: lento ∵ O(n²) → otimizar para O(n)
|
||||
```
|
||||
|
||||
## Casos de Uso
|
||||
|
||||
### ✅ Cenários Efetivos
|
||||
|
||||
- **Sessões longas de debug**: Manter histórico eficientemente
|
||||
- **Revisões grandes de código**: Análise concisa de muitos arquivos
|
||||
- **Monitoramento CI/CD**: Atualizações de status em tempo real
|
||||
- **Relatórios de progresso de projeto**: Visão geral de múltiplos estados de tarefa
|
||||
- **Rastreamento de erros**: Representação visual de cadeias de problemas
|
||||
|
||||
### ❌ Cenários a Evitar
|
||||
|
||||
- Explicações para iniciantes
|
||||
- Criação de documentação detalhada
|
||||
- Definição de requisitos iniciais
|
||||
- Comunicação com stakeholders não-técnicos
|
||||
|
||||
## Exemplos de Implementação
|
||||
|
||||
### Sessão de Debug
|
||||
|
||||
```text
|
||||
[14:23] breakpoint → vars: {user: null, token: expirado}
|
||||
[14:24] step → auth.validate() ❌
|
||||
[14:25] check → token.exp < Date.now() ∴ expirado
|
||||
[14:26] fix → refresh() → ✅
|
||||
[14:27] continue → fluxo principal 🔄
|
||||
```
|
||||
|
||||
### Resultados de Análise de Arquivos
|
||||
|
||||
```text
|
||||
/src/auth/: 🛡️ problemas × 3
|
||||
/src/api/: ⚡ gargalo no handler()
|
||||
/src/db/: ✅ limpo
|
||||
/src/utils/: ⚠️ métodos deprecated
|
||||
/tests/: 🧪 cobertura 78%
|
||||
```
|
||||
|
||||
### Status do Projeto
|
||||
|
||||
```text
|
||||
Frontend: 🎨 ✅ 100%
|
||||
Backend: ⚙️ 🔄 75%
|
||||
Database: 🗄️ ✅ migrado
|
||||
Testes: 🧪 ⚠️ 68% (meta: 80%)
|
||||
Deploy: 📦 ⏳ agendado
|
||||
Segurança: 🛡️ 🚨 1 crítico
|
||||
```
|
||||
|
||||
## Opções de Configuração
|
||||
|
||||
```javascript
|
||||
// Níveis de compressão
|
||||
--uc; // Ultra Comprimido: Máxima compressão
|
||||
--mc; // Moderadamente Comprimido: Compressão média
|
||||
--lc; // Levemente Comprimido: Compressão leve
|
||||
|
||||
// Específico do domínio
|
||||
--dev; // Compressão focada em desenvolvimento
|
||||
--ops; // Compressão focada em operações
|
||||
--seg; // Compressão focada em segurança
|
||||
```
|
||||
|
||||
## Benefícios
|
||||
|
||||
1. **Economia de contexto**: Redução de 30-50% nos tokens
|
||||
2. **Compreensão visual**: Compreensão intuitiva através de símbolos
|
||||
3. **Densidade de informação**: Mais informação no mesmo espaço
|
||||
4. **Retenção de histórico**: Manter conversas mais longas no histórico
|
||||
5. **Reconhecimento de padrões**: Detecção mais fácil de problemas através de padrões visuais
|
||||
|
||||
## Observações
|
||||
|
||||
- Este modo apenas muda o **estilo de resposta da IA**
|
||||
- **Qualidade do código** permanece inalterada
|
||||
- Pode alternar com "explicar no modo normal" conforme necessário
|
||||
- Modo normal recomendado para iniciantes e usuários não-técnicos
|
||||
|
||||
## Exemplos de Comandos
|
||||
|
||||
```bash
|
||||
# Ativar
|
||||
"Modo Eficiência de Tokens ligado"
|
||||
"Responder de forma concisa"
|
||||
"Analisar com --uc"
|
||||
|
||||
# Desativar
|
||||
"Voltar ao modo normal"
|
||||
"Explicar em detalhes"
|
||||
"Modo Eficiência de Tokens desligado"
|
||||
```
|
||||
|
||||
## Impacto da Implementação
|
||||
|
||||
| Item | Impacto |
|
||||
| -------------------------- | -------------------- |
|
||||
| Qualidade do código gerado | Sem mudança ✅ |
|
||||
| Precisão da implementação | Sem mudança ✅ |
|
||||
| Funcionalidade | Sem mudança ✅ |
|
||||
| Método de explicação da IA | Comprimido 🔄 |
|
||||
| Uso de contexto | Redução de 30-50% ⚡ |
|
||||
|
||||
---
|
||||
|
||||
💡 **Dica Pro**: Para sessões de trabalho longas, comece com o modo normal para construir entendimento, depois mude para o Modo Eficiência de Tokens para otimizar a eficiência e retenção de contexto.
|
||||
65
commands/ultrathink.md
Normal file
65
commands/ultrathink.md
Normal file
@@ -0,0 +1,65 @@
|
||||
## Ultrathink
|
||||
|
||||
Executa processo de pensamento estruturado e gradual para questões complexas ou decisões importantes.
|
||||
|
||||
### Como usar
|
||||
|
||||
```bash
|
||||
# Solicitar pensamento profundo ao Claude
|
||||
"Considere [questão] usando ultrathink"
|
||||
```
|
||||
|
||||
### Exemplos Básicos
|
||||
|
||||
```bash
|
||||
# Consideração de design arquitetural
|
||||
"Considere se devemos escolher microsserviços ou monolito usando ultrathink"
|
||||
|
||||
# Análise de seleção técnica
|
||||
"Analise se Rust ou TypeScript é mais adequado para este projeto usando ultrathink"
|
||||
|
||||
# Aprofundamento na resolução de problemas
|
||||
"Considere as causas da baixa performance da aplicação e métodos de melhoria usando ultrathink"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Decisão de negócio
|
||||
"Considere a priorização de novas funcionalidades usando ultrathink. Do ponto de vista do valor para o usuário, custo de desenvolvimento e risco técnico"
|
||||
|
||||
# Design de sistema
|
||||
"Considere o design do sistema de autenticação usando ultrathink. Considerando segurança, escalabilidade e manutenibilidade"
|
||||
|
||||
# Análise de trade-offs
|
||||
"Analise a escolha entre GraphQL vs REST API usando ultrathink. Baseado nos requisitos do projeto"
|
||||
|
||||
# Estratégia de refatoração
|
||||
cat src/legacy_code.js
|
||||
"Elabore estratégia de refatoração deste código legado usando ultrathink"
|
||||
```
|
||||
|
||||
### Processo de Pensamento
|
||||
|
||||
1. **Decomposição do problema** - Decompõe a questão em componentes
|
||||
2. **Análise MECE** - Organiza sem lacunas nem sobreposições
|
||||
3. **Consideração de múltiplas perspectivas** - Analisa dos pontos de vista técnico, negócio e usuário
|
||||
4. **Confirmação interativa** - Confirma com usuário em pontos de decisão importantes
|
||||
5. **Proposta fundamentada** - Conclusão baseada em dados e lógica
|
||||
|
||||
### Exemplos Detalhados
|
||||
|
||||
```bash
|
||||
# Resolução de débito técnico complexo
|
||||
"Considere estratégia para modernizar sistema legado de 10 anos usando ultrathink. Inclua migração gradual, riscos e ROI"
|
||||
|
||||
# Questões organizacionais
|
||||
"Considere estratégia de scaling da equipe de desenvolvimento usando ultrathink. Assumindo expansão atual de 5 para 20 pessoas"
|
||||
|
||||
# Migração de banco de dados
|
||||
"Analise migração de PostgreSQL para DynamoDB usando ultrathink. Considerando custo, performance e aspectos operacionais"
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
ultrathink é ideal para questões que requerem tempo e reflexão profunda. Para perguntas simples ou quando respostas imediatas são necessárias, use o formato de pergunta normal.
|
||||
202
commands/update-dart-doc.md
Normal file
202
commands/update-dart-doc.md
Normal file
@@ -0,0 +1,202 @@
|
||||
## Update Dart Doc
|
||||
|
||||
Gerencia sistematicamente comentários DartDoc de arquivos Dart e mantém documentação em português de alta qualidade.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Executar adição nova e atualização simultaneamente
|
||||
"Adicione DartDoc a classes sem comentários e atualize comentários que não atendem aos critérios"
|
||||
|
||||
# Verificar arquivos alterados no PR
|
||||
"Verifique se há marcadores Claude no DartDoc dos arquivos alterados no PR #4308"
|
||||
|
||||
# Organizar documentação de diretório específico
|
||||
"Adicione DartDoc às classes Widget em packages/app/lib/ui/screen/"
|
||||
|
||||
# Executar sem marcador
|
||||
/update-dart-doc --marker false
|
||||
"Melhore o DartDoc do projeto existente (sem adicionar marcadores Claude)"
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--marker <true|false>` : Se deve adicionar marcadores Claude (padrão: true)
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# 1. Análise de arquivos alvo
|
||||
find . -name "*.dart" -not -path "*/.*" | grep -v "_test.dart" | grep -v "_vrt.dart"
|
||||
"Identifique classes com DartDoc insuficiente (0 linhas de comentário ou menos de 30 caracteres)"
|
||||
|
||||
# 2. Adição de documentação
|
||||
"Adicione comentários DartDoc contendo elementos essenciais às classes identificadas"
|
||||
|
||||
# 3. Verificação de marcador
|
||||
"Confirme que todos os DartDoc adicionados/atualizados possuem marcadores Claude"
|
||||
```
|
||||
|
||||
### Procedimento de execução
|
||||
|
||||
#### 1. Prioridade dos elementos alvo
|
||||
|
||||
1. 🔴 **Máxima prioridade**: Elementos sem comentários DartDoc (0 linhas de comentário)
|
||||
2. 🟡 **Próxima prioridade**: Elementos que não atendem aos critérios (menos de 30 caracteres ou falta elementos essenciais)
|
||||
3. 🟢 **Alvo de verificação**: Comentários existentes sem marcadores Claude
|
||||
|
||||
**Elementos alvo**:
|
||||
|
||||
- Class (todas as definições de classe)
|
||||
- Enum (tipos enumerados)
|
||||
- Extension (métodos de extensão)
|
||||
- Funções importantes (funções de nível superior, opcionais)
|
||||
|
||||
#### 2. Regras de escrita DartDoc
|
||||
|
||||
**Estrutura básica**:
|
||||
|
||||
```dart
|
||||
/// {Descrição resumida do elemento} (30-60 caracteres, obrigatório)
|
||||
///
|
||||
/// {Descrição detalhada} (função, contexto de uso, pontos de atenção obrigatórios, 50-200 caracteres)
|
||||
///
|
||||
/// Generated by Claude 🤖
|
||||
@Anotacao // Não alterar anotações existentes
|
||||
class NomeClasse {
|
||||
```
|
||||
|
||||
**Estilo de escrita**:
|
||||
|
||||
- Linguagem formal: "exibe", "é uma classe que gerencia"
|
||||
- Pontuação usa "." e ","
|
||||
- Espaço entre português e caracteres alfanuméricos
|
||||
- Termos técnicos em português: "estado de Authentication"
|
||||
- Cada linha dentro de 80 caracteres
|
||||
|
||||
#### 3. Exemplos de descrição por categoria de classe
|
||||
|
||||
**Classes de gerenciamento de estado (Riverpod)**:
|
||||
|
||||
```dart
|
||||
/// State que gerencia o estado de desativação de gestos de swipe horizontal.
|
||||
///
|
||||
/// Usado quando é necessário desativar swipe horizontal em telas específicas
|
||||
/// ou durante operações. Por exemplo, durante exibição de carrossel ou entrada específica.
|
||||
///
|
||||
/// Generated by Claude 🤖
|
||||
@Riverpod(keepAlive: true, dependencies: [])
|
||||
class HorizontalDragGestureIgnoreState extends _$HorizontalDragGestureIgnoreState {
|
||||
```
|
||||
|
||||
**Classes Widget**:
|
||||
|
||||
```dart
|
||||
/// Widget que exibe o perfil do usuário.
|
||||
///
|
||||
/// Organiza verticalmente imagem de avatar, nome de usuário e informações de status,
|
||||
/// fazendo transição para tela de detalhes do perfil ao tocar.
|
||||
///
|
||||
/// Generated by Claude 🤖
|
||||
class UserProfileWidget extends HookConsumerWidget {
|
||||
```
|
||||
|
||||
#### 4. Regras de preservação de conteúdo existente
|
||||
|
||||
1. **Quando comentário existente atende aos critérios**: Preservar como está (não adicionar novo)
|
||||
- Critérios: 30+ caracteres e contém elementos essenciais (resumo, detalhes, marcador)
|
||||
2. **Quando comentário existente não atende aos critérios**: Substituir completamente (não duplicar)
|
||||
3. **Quando não há comentário existente**: Adicionar novo comentário
|
||||
|
||||
**Informações importantes a preservar**:
|
||||
|
||||
- URLs e links: Referências começando com `See also:`
|
||||
- Comentários TODO: Formato `TODO(nome_usuario):`
|
||||
- Avisos: Alertas como `Atenção:` ou `Warning:`
|
||||
- Exemplos de uso: Código começando com `Exemplo:` ou `Example:`
|
||||
- Restrições técnicas: Descrições de performance ou limitações
|
||||
|
||||
### Gerenciamento de marcadores Claude
|
||||
|
||||
```bash
|
||||
# Formato do marcador
|
||||
/// Generated by Claude 🤖
|
||||
|
||||
# Verificação de marcador em arquivos alterados no PR
|
||||
gh pr diff 4308 --name-only | grep "\.dart$" | xargs grep -l "Generated by Claude"
|
||||
"Adicione marcadores aos arquivos sem marcador"
|
||||
```
|
||||
|
||||
### Lista de verificação de qualidade
|
||||
|
||||
- ✅ **Contagem de caracteres**: Respeitar rigorosamente resumo 30-60 caracteres, detalhes 50-200 caracteres
|
||||
- ✅ **Elementos essenciais**: Incluir obrigatoriamente 3 elementos: resumo, descrição detalhada, marcador Claude
|
||||
- ✅ **Completude**: Descrever função, contexto de uso, pontos de atenção
|
||||
- ✅ **Consistência**: Unificar estilo em linguagem formal
|
||||
- ✅ **Formatação**: Espaço entre português e inglês
|
||||
- ✅ **Precisão**: Analisar implementação e descrever apenas fatos
|
||||
- ✅ **Estrutura**: Preservar anotações, posicionar comentários acima
|
||||
- ✅ **Comprimento**: Cada linha dentro de 80 caracteres
|
||||
- ✅ **Marcador**: Adicionar obrigatoriamente marcador para alterações feitas por Claude
|
||||
|
||||
### Observações
|
||||
|
||||
**🔴 Itens absolutamente proibidos**:
|
||||
|
||||
- ❌ Alterações de código além de comentários de documentação
|
||||
- ❌ Suposições sobre detalhes de implementação (descrever apenas fatos)
|
||||
- ❌ Mistura não natural de inglês e português
|
||||
- ❌ Remoção ou alteração de anotações existentes
|
||||
- ❌ Duplicação com comentários existentes
|
||||
- ❌ Comentários abaixo do critério de caracteres em arquivos de teste (`*_test.dart`)
|
||||
- ❌ Comentários abaixo do critério de caracteres em arquivos VRT (`*_vrt.dart`)
|
||||
|
||||
**Análise estática e commit**:
|
||||
|
||||
```bash
|
||||
# Registro de resultados de execução
|
||||
ADDED_COMMENTS=0
|
||||
UPDATED_COMMENTS=0
|
||||
ERRORS=0
|
||||
|
||||
# Verificação após alteração
|
||||
melos analyze
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "🔴 Erro: Análise estática falhou"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Saída do resumo de execução
|
||||
echo "📊 Resultado da execução:"
|
||||
echo "- Comentários adicionados: $ADDED_COMMENTS itens"
|
||||
echo "- Comentários atualizados: $UPDATED_COMMENTS itens"
|
||||
echo "- Número de erros: $ERRORS itens"
|
||||
|
||||
# Exemplo de commit
|
||||
git commit -m "docs: adicionar e atualizar comentários DartDoc
|
||||
|
||||
- Adicionar DartDoc a classes, enum, extension que não atendem aos critérios
|
||||
- Atualizar comentários com menos de 30 caracteres conforme critérios
|
||||
- Adicionar marcadores Claude uniformemente
|
||||
|
||||
Resultado da execução:
|
||||
- Adicionados: $ADDED_COMMENTS itens
|
||||
- Atualizados: $UPDATED_COMMENTS itens
|
||||
|
||||
Generated by Claude 🤖"
|
||||
```
|
||||
|
||||
### Critérios de sucesso da execução
|
||||
|
||||
1. **Determinação de conclusão**: Sucesso quando atende a todos os seguintes
|
||||
- `melos analyze` PASSOU
|
||||
- Número de erros é 0
|
||||
- Todos os comentários adicionados/atualizados atendem aos critérios
|
||||
|
||||
2. **Sucesso parcial**: Nos seguintes casos
|
||||
- Número de erros menor que 5
|
||||
- 90% ou mais do total atende aos critérios
|
||||
|
||||
3. **Falha**: Nos seguintes casos
|
||||
- `melos analyze` FALHOU
|
||||
- Número de erros 5 ou mais
|
||||
306
commands/update-doc-string.md
Normal file
306
commands/update-doc-string.md
Normal file
@@ -0,0 +1,306 @@
|
||||
## Update Doc String
|
||||
|
||||
Gerencia sistematicamente docstrings/comentários multilíngues e mantém documentação de alta qualidade.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Executar com detecção automática de idioma
|
||||
"Adicione docstrings a classes e funções sem comentários e atualize comentários que não atendem aos critérios"
|
||||
|
||||
# Executar especificando idioma
|
||||
/update-doc-string --lang python
|
||||
"Atualize docstrings de arquivos Python em conformidade com PEP 257"
|
||||
|
||||
# Organizar documentação de diretório específico
|
||||
"Adicione JSDoc às funções em src/components/"
|
||||
```
|
||||
|
||||
### Opções
|
||||
|
||||
- `--lang <en|pt>` : Idioma de descrição da documentação (padrão: detecção automática dos comentários existentes, pt se não houver)
|
||||
- `--style <estilo>` : Especificar estilo de documentação (com padrões específicos por idioma)
|
||||
- `--marker <true|false>` : Se deve adicionar marcadores Claude (padrão: true)
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# 1. Análise de arquivos alvo (detecção automática da linguagem de programação)
|
||||
find . -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.dart" -o -name "*.go" -o -name "*.rs" \) | grep -v test
|
||||
"Identifique elementos com docstring insuficiente (0 linhas de comentário ou menos de 30 caracteres)"
|
||||
|
||||
# 2. Adição de documentação (detecção automática de idioma)
|
||||
"Adicione docstring com elementos essenciais específicos do idioma aos elementos identificados"
|
||||
# → Se houver japonês nos comentários existentes, escrever em japonês, senão em inglês
|
||||
|
||||
# 3. Adição de documentação (especificação explícita de inglês)
|
||||
/update-doc-string --lang en
|
||||
"Add docstrings with required elements to the identified elements"
|
||||
|
||||
# 4. Verificação de marcador
|
||||
"Confirme que todas as docstrings adicionadas/atualizadas possuem marcadores Claude"
|
||||
```
|
||||
|
||||
### Procedimento de execução
|
||||
|
||||
#### 1. Prioridade dos elementos alvo
|
||||
|
||||
1. 🔴 **Máxima prioridade**: Elementos sem docstring/comentários (0 linhas de comentário)
|
||||
2. 🟡 **Próxima prioridade**: Elementos que não atendem aos critérios (menos de 30 caracteres ou falta elementos essenciais)
|
||||
3. 🟢 **Alvo de verificação**: Comentários existentes sem marcadores Claude
|
||||
|
||||
**Elementos alvo (comum a todas as linguagens)**:
|
||||
|
||||
- Class/definições de classe
|
||||
- Function/funções e métodos
|
||||
- Module/módulos (Python, Go)
|
||||
- Enum/tipos enumerados
|
||||
- Interface/interfaces (TypeScript, Go)
|
||||
|
||||
#### 2. Regras de escrita por idioma
|
||||
|
||||
**Python (PEP 257)**:
|
||||
|
||||
```python
|
||||
# Versão em português (padrão)
|
||||
def calculate_total(items: List[Item]) -> float:
|
||||
"""Calcula o valor total de uma lista de itens. (30-60 caracteres)
|
||||
|
||||
Multiplica o preço e quantidade de cada item e retorna o total
|
||||
com impostos. Retorna 0.0 para listas vazias. (50-200 caracteres)
|
||||
|
||||
Args:
|
||||
items: Lista de itens para cálculo
|
||||
|
||||
Returns:
|
||||
Valor total com impostos
|
||||
|
||||
Generated by Claude 🤖
|
||||
"""
|
||||
|
||||
# Versão em inglês (--lang en)
|
||||
def calculate_total(items: List[Item]) -> float:
|
||||
"""Calculate the total amount for a list of items. (30-60 chars)
|
||||
|
||||
Multiplies the price and quantity of each item and returns
|
||||
the total with tax. Returns 0.0 for empty lists. (50-200 chars)
|
||||
|
||||
Args:
|
||||
items: List of items to calculate
|
||||
|
||||
Returns:
|
||||
Total amount with tax
|
||||
|
||||
Generated by Claude 🤖
|
||||
"""
|
||||
```
|
||||
|
||||
**JavaScript/TypeScript (JSDoc)**:
|
||||
|
||||
```javascript
|
||||
/**
|
||||
* Componente que exibe o perfil do usuário. (30-60 caracteres)
|
||||
*
|
||||
* Exibe imagem de avatar, nome de usuário e informações de status,
|
||||
* fazendo transição para tela de detalhes do perfil ao clicar. (50-200 caracteres)
|
||||
*
|
||||
* @param {Object} props - Propriedades do componente
|
||||
* @param {string} props.userId - ID do usuário
|
||||
* @param {boolean} [props.showStatus=true] - Flag de exibição de status
|
||||
* @returns {JSX.Element} Componente renderizado
|
||||
*
|
||||
* @generated by Claude 🤖
|
||||
*/
|
||||
const UserProfile = ({ userId, showStatus = true }) => {
|
||||
```
|
||||
|
||||
**Go**:
|
||||
|
||||
```go
|
||||
// CalculateTotal calcula o valor total de uma lista de itens. (30-60 caracteres)
|
||||
//
|
||||
// Multiplica o preço e quantidade de cada item e retorna o total
|
||||
// com impostos. Retorna 0.0 para slices vazios. (50-200 caracteres)
|
||||
//
|
||||
// Generated by Claude 🤖
|
||||
func CalculateTotal(items []Item) float64 {
|
||||
```
|
||||
|
||||
**Rust**:
|
||||
|
||||
```rust
|
||||
/// Calcula o valor total de uma lista de itens. (30-60 caracteres)
|
||||
///
|
||||
/// Multiplica o preço e quantidade de cada item e retorna o total
|
||||
/// com impostos. Retorna 0.0 para vetores vazios. (50-200 caracteres)
|
||||
///
|
||||
/// Generated by Claude 🤖
|
||||
pub fn calculate_total(items: &[Item]) -> f64 {
|
||||
```
|
||||
|
||||
**Dart (DartDoc)**:
|
||||
|
||||
```dart
|
||||
/// Widget que exibe o perfil do usuário. (30-60 caracteres)
|
||||
///
|
||||
/// Organiza verticalmente imagem de avatar, nome de usuário e informações de status,
|
||||
/// fazendo transição para tela de detalhes do perfil ao tocar. (50-200 caracteres)
|
||||
///
|
||||
/// Generated by Claude 🤖
|
||||
class UserProfileWidget extends StatelessWidget {
|
||||
```
|
||||
|
||||
#### 3. Regras de preservação de conteúdo existente
|
||||
|
||||
1. **Quando comentário existente atende aos critérios**: Preservar como está (não adicionar novo)
|
||||
- Critérios: 30+ caracteres e contém elementos essenciais (resumo, detalhes, marcador)
|
||||
2. **Quando comentário existente não atende aos critérios**: Substituir completamente (não duplicar)
|
||||
3. **Quando não há comentário existente**: Adicionar novo comentário
|
||||
|
||||
**Informações importantes a preservar**:
|
||||
|
||||
- URLs e links: `See also:`, `@see`, `Veja também:` etc.
|
||||
- Comentários TODO: Formatos `TODO:`, `FIXME:`, `XXX:`
|
||||
- Avisos: `Note:`, `Warning:`, `Atenção:` etc.
|
||||
- Exemplos de uso: `Example:`, `Exemplo:`, `# Examples` etc.
|
||||
- Descrições existentes de parâmetros e valores de retorno
|
||||
|
||||
### Configurações por idioma
|
||||
|
||||
```yaml
|
||||
# Configurações padrão por idioma
|
||||
languages:
|
||||
python:
|
||||
style: "google" # google, numpy, sphinx
|
||||
indent: 4
|
||||
quotes: '"""'
|
||||
|
||||
javascript:
|
||||
style: "jsdoc"
|
||||
indent: 2
|
||||
prefix: "/**"
|
||||
suffix: "*/"
|
||||
|
||||
typescript:
|
||||
style: "tsdoc"
|
||||
indent: 2
|
||||
prefix: "/**"
|
||||
suffix: "*/"
|
||||
|
||||
go:
|
||||
style: "godoc"
|
||||
indent: 0
|
||||
prefix: "//"
|
||||
|
||||
rust:
|
||||
style: "rustdoc"
|
||||
indent: 0
|
||||
prefix: "///"
|
||||
|
||||
dart:
|
||||
style: "dartdoc"
|
||||
indent: 0
|
||||
prefix: "///"
|
||||
```
|
||||
|
||||
### Lista de verificação de qualidade
|
||||
|
||||
- ✅ **Contagem de caracteres**: Respeitar rigorosamente resumo 30-60 caracteres, detalhes 50-200 caracteres
|
||||
- ✅ **Elementos essenciais**: Incluir obrigatoriamente 3 elementos: resumo, descrição detalhada, marcador Claude
|
||||
- ✅ **Completude**: Descrever função, contexto de uso, pontos de atenção
|
||||
- ✅ **Convenções da linguagem**: Conformidade com guias de estilo oficiais de cada linguagem
|
||||
- ✅ **Exceções**: Descrição de erros e exceções (quando aplicável)
|
||||
- ✅ **Precisão**: Analisar implementação e descrever apenas fatos
|
||||
|
||||
### Observações
|
||||
|
||||
**🔴 Itens absolutamente proibidos**:
|
||||
|
||||
- ❌ Alterações de código além de comentários de documentação
|
||||
- ❌ Suposições sobre detalhes de implementação (descrever apenas fatos)
|
||||
- ❌ Formatos que violam convenções da linguagem
|
||||
- ❌ Remoção ou alteração de anotações de tipo existentes
|
||||
- ❌ Duplicação com comentários existentes
|
||||
- ❌ Comentários abaixo do critério de caracteres em arquivos de teste
|
||||
|
||||
**Execução e verificação**:
|
||||
|
||||
```bash
|
||||
# Registro de resultados de execução
|
||||
ADDED_COMMENTS=0
|
||||
UPDATED_COMMENTS=0
|
||||
ERRORS=0
|
||||
|
||||
# Detecção automática de idioma dos comentários existentes
|
||||
# Se detectar padrões portugueses comuns → pt, senão en
|
||||
DOC_LANGUAGE="en" # padrão
|
||||
if grep -r 'ção\|ões\|agem\|ário\|ória\|ência\|português\|brasil' --include="*.py" --include="*.js" --include="*.ts" --include="*.dart" --include="*.go" --include="*.rs" . 2>/dev/null | head -n 1; then
|
||||
DOC_LANGUAGE="pt"
|
||||
fi
|
||||
|
||||
# Detecção automática de linguagem de programação e análise estática
|
||||
if [ -f "*.py" ]; then
|
||||
pylint --disable=all --enable=missing-docstring .
|
||||
elif [ -f "*.js" ] || [ -f "*.ts" ]; then
|
||||
eslint . --rule 'jsdoc/require-jsdoc: error'
|
||||
elif [ -f "*.go" ]; then
|
||||
golint ./...
|
||||
elif [ -f "*.rs" ]; then
|
||||
cargo doc --no-deps
|
||||
elif [ -f "*.dart" ]; then
|
||||
melos analyze
|
||||
fi
|
||||
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "🔴 Erro: Análise estática falhou"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Saída do resumo de execução
|
||||
echo "📊 Resultado da execução:"
|
||||
echo "- Idioma da documentação: $DOC_LANGUAGE"
|
||||
echo "- Comentários adicionados: $ADDED_COMMENTS itens"
|
||||
echo "- Comentários atualizados: $UPDATED_COMMENTS itens"
|
||||
echo "- Número de erros: $ERRORS itens"
|
||||
```
|
||||
|
||||
### Critérios de sucesso da execução
|
||||
|
||||
1. **Determinação de conclusão**: Sucesso quando atende a todos os seguintes
|
||||
- Análise estática específica da linguagem PASSOU
|
||||
- Número de erros é 0
|
||||
- Todos os comentários adicionados/atualizados atendem aos critérios
|
||||
|
||||
2. **Sucesso parcial**: Nos seguintes casos
|
||||
- Número de erros menor que 5
|
||||
- 90% ou mais do total atende aos critérios
|
||||
|
||||
3. **Falha**: Nos seguintes casos
|
||||
- Análise estática FALHOU
|
||||
- Número de erros 5 ou mais
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Análise de projeto inteiro (detecção automática de idioma)
|
||||
find . -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" \)
|
||||
/update-doc-string
|
||||
"Atualize as docstrings deste projeto seguindo as melhores práticas específicas de cada linguagem"
|
||||
# → Se houver japonês nos comentários existentes, executa em ja, senão en
|
||||
|
||||
# Execução explícita em inglês
|
||||
/update-doc-string --lang en
|
||||
"Update docstrings following language-specific best practices"
|
||||
|
||||
# Execução explícita em japonês
|
||||
/update-doc-string --lang pt
|
||||
"Atualize as docstrings deste projeto seguindo as melhores práticas específicas de cada linguagem"
|
||||
|
||||
# Execução sem marcador (detecção automática de idioma)
|
||||
/update-doc-string --marker false
|
||||
"Improve existing docstrings without adding Claude markers"
|
||||
|
||||
# Documentação em inglês, sem marcador
|
||||
/update-doc-string --lang en --marker false
|
||||
"Improve existing docstrings without adding Claude markers"
|
||||
```
|
||||
105
commands/update-flutter-deps.md
Normal file
105
commands/update-flutter-deps.md
Normal file
@@ -0,0 +1,105 @@
|
||||
## Flutter Dependencies Update
|
||||
|
||||
Atualiza com segurança as dependências de projetos Flutter.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Verificar estado das dependências e solicitar ao Claude
|
||||
flutter pub deps --style=compact
|
||||
"Atualize as dependências do pubspec.yaml para as versões mais recentes"
|
||||
```
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# Verificar dependências atuais
|
||||
cat pubspec.yaml
|
||||
"Analise as dependências deste projeto Flutter e me informe quais pacotes podem ser atualizados"
|
||||
|
||||
# Verificação após upgrade
|
||||
flutter pub upgrade --dry-run
|
||||
"Verifique se há mudanças disruptivas no conteúdo planejado para este upgrade"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Atualização abrangente de dependências
|
||||
cat pubspec.yaml
|
||||
"Analise as dependências do Flutter e execute o seguinte:
|
||||
1. Investigar as versões mais recentes de cada pacote
|
||||
2. Verificar presença de mudanças disruptivas
|
||||
3. Avaliar nível de risco (seguro/atenção/perigoso)
|
||||
4. Sugerir alterações de código necessárias
|
||||
5. Gerar pubspec.yaml atualizado"
|
||||
|
||||
# Atualização segura e gradual
|
||||
flutter pub outdated
|
||||
"Evitando atualizações de versão major, atualize apenas pacotes que podem ser atualizados com segurança"
|
||||
|
||||
# Análise de impacto de pacote específico
|
||||
"Informe o impacto e mudanças necessárias se atualizar o provider para a versão mais recente"
|
||||
```
|
||||
|
||||
### Exemplos detalhados
|
||||
|
||||
```bash
|
||||
# Análise detalhada incluindo Release Notes
|
||||
cat pubspec.yaml && flutter pub outdated
|
||||
"Analise as dependências e para cada pacote apresente:
|
||||
1. Versão atual → versão mais recente
|
||||
2. Avaliação de risco (seguro/atenção/perigoso)
|
||||
3. Principais alterações (do CHANGELOG)
|
||||
4. Correções de código necessárias
|
||||
em formato de tabela"
|
||||
|
||||
# Análise de migração para Null Safety
|
||||
cat pubspec.yaml
|
||||
"Identifique pacotes que não suportam Null Safety e crie um plano de migração"
|
||||
```
|
||||
|
||||
### Critérios de nível de risco
|
||||
|
||||
```text
|
||||
Seguro (🟢):
|
||||
- Atualização de versão de patch (1.2.3 → 1.2.4)
|
||||
- Apenas correções de bug
|
||||
- Garantia de compatibilidade retroativa
|
||||
|
||||
Atenção (🟡):
|
||||
- Atualização de versão minor (1.2.3 → 1.3.0)
|
||||
- Adição de novas funcionalidades
|
||||
- Avisos de descontinuação
|
||||
|
||||
Perigoso (🔴):
|
||||
- Atualização de versão major (1.2.3 → 2.0.0)
|
||||
- Mudanças disruptivas
|
||||
- Remoção/alteração de API
|
||||
```
|
||||
|
||||
### Execução da atualização
|
||||
|
||||
```bash
|
||||
# Criar backup
|
||||
cp pubspec.yaml pubspec.yaml.backup
|
||||
cp pubspec.lock pubspec.lock.backup
|
||||
|
||||
# Executar atualização
|
||||
flutter pub upgrade
|
||||
|
||||
# Verificação após atualização
|
||||
flutter analyze
|
||||
flutter test
|
||||
flutter pub deps --style=compact
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
Sempre realize verificação de funcionamento após a atualização. Em caso de problemas, restaure usando:
|
||||
|
||||
```bash
|
||||
cp pubspec.yaml.backup pubspec.yaml
|
||||
cp pubspec.lock.backup pubspec.lock
|
||||
flutter pub get
|
||||
```
|
||||
105
commands/update-node-deps.md
Normal file
105
commands/update-node-deps.md
Normal file
@@ -0,0 +1,105 @@
|
||||
## Node Dependencies Update
|
||||
|
||||
Atualiza com segurança as dependências de projetos Node.js.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Verificar estado das dependências e solicitar ao Claude
|
||||
npm outdated
|
||||
"Atualize as dependências do package.json para as versões mais recentes"
|
||||
```
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# Verificar dependências atuais
|
||||
cat package.json
|
||||
"Analise as dependências deste projeto Node.js e me informe quais pacotes podem ser atualizados"
|
||||
|
||||
# Verificar lista de possíveis atualizações
|
||||
npm outdated
|
||||
"Analise o nível de risco na atualização destes pacotes"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Atualização abrangente de dependências
|
||||
cat package.json
|
||||
"Analise as dependências do Node.js e execute o seguinte:
|
||||
1. Investigar as versões mais recentes de cada pacote
|
||||
2. Verificar presença de mudanças disruptivas
|
||||
3. Avaliar nível de risco (seguro/atenção/perigoso)
|
||||
4. Sugerir alterações de código necessárias
|
||||
5. Gerar package.json atualizado"
|
||||
|
||||
# Atualização segura e gradual
|
||||
npm outdated
|
||||
"Evitando atualizações de versão major, atualize apenas pacotes que podem ser atualizados com segurança"
|
||||
|
||||
# Análise de impacto de pacote específico
|
||||
"Informe o impacto e mudanças necessárias se atualizar o express para a versão mais recente"
|
||||
```
|
||||
|
||||
### Exemplos detalhados
|
||||
|
||||
```bash
|
||||
# Análise detalhada incluindo Release Notes
|
||||
cat package.json && npm outdated
|
||||
"Analise as dependências e para cada pacote apresente:
|
||||
1. Versão atual → versão mais recente
|
||||
2. Avaliação de risco (seguro/atenção/perigoso)
|
||||
3. Principais alterações (do CHANGELOG)
|
||||
4. Correções de código necessárias
|
||||
em formato de tabela"
|
||||
|
||||
# Consideração de definições de tipo para projetos TypeScript
|
||||
cat package.json tsconfig.json
|
||||
"Inclua também definições de tipo do TypeScript na atualização de dependências e crie plano de atualização que evite erros de tipo"
|
||||
```
|
||||
|
||||
### Critérios de nível de risco
|
||||
|
||||
```text
|
||||
Seguro (🟢):
|
||||
- Atualização de versão de patch (1.2.3 → 1.2.4)
|
||||
- Apenas correções de bug
|
||||
- Garantia de compatibilidade retroativa
|
||||
|
||||
Atenção (🟡):
|
||||
- Atualização de versão minor (1.2.3 → 1.3.0)
|
||||
- Adição de novas funcionalidades
|
||||
- Avisos de descontinuação
|
||||
|
||||
Perigoso (🔴):
|
||||
- Atualização de versão major (1.2.3 → 2.0.0)
|
||||
- Mudanças disruptivas
|
||||
- Remoção/alteração de API
|
||||
```
|
||||
|
||||
### Execução da atualização
|
||||
|
||||
```bash
|
||||
# Criar backup
|
||||
cp package.json package.json.backup
|
||||
cp package-lock.json package-lock.json.backup
|
||||
|
||||
# Executar atualização
|
||||
npm update
|
||||
|
||||
# Verificação após atualização
|
||||
npm test
|
||||
npm run build
|
||||
npm audit
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
Sempre realize verificação de funcionamento após a atualização. Em caso de problemas, restaure usando:
|
||||
|
||||
```bash
|
||||
cp package.json.backup package.json
|
||||
cp package-lock.json.backup package-lock.json
|
||||
npm install
|
||||
```
|
||||
107
commands/update-rust-deps.md
Normal file
107
commands/update-rust-deps.md
Normal file
@@ -0,0 +1,107 @@
|
||||
## Rust Dependencies Update
|
||||
|
||||
Atualiza com segurança as dependências de projetos Rust.
|
||||
|
||||
### Uso
|
||||
|
||||
```bash
|
||||
# Verificar estado das dependências e solicitar ao Claude
|
||||
cargo tree
|
||||
"Atualize as dependências do Cargo.toml para as versões mais recentes"
|
||||
```
|
||||
|
||||
### Exemplos básicos
|
||||
|
||||
```bash
|
||||
# Verificar dependências atuais
|
||||
cat Cargo.toml
|
||||
"Analise as dependências deste projeto Rust e me informe quais crates podem ser atualizados"
|
||||
|
||||
# Verificar lista de possíveis atualizações
|
||||
cargo update --dry-run
|
||||
"Analise o nível de risco na atualização destes crates"
|
||||
```
|
||||
|
||||
### Integração com Claude
|
||||
|
||||
```bash
|
||||
# Atualização abrangente de dependências
|
||||
cat Cargo.toml
|
||||
"Analise as dependências do Rust e execute o seguinte:
|
||||
1. Investigar as versões mais recentes de cada crate
|
||||
2. Verificar presença de mudanças disruptivas
|
||||
3. Avaliar nível de risco (seguro/atenção/perigoso)
|
||||
4. Sugerir alterações de código necessárias
|
||||
5. Gerar Cargo.toml atualizado"
|
||||
|
||||
# Atualização segura e gradual
|
||||
cargo tree
|
||||
"Evitando atualizações de versão major, atualize apenas crates que podem ser atualizados com segurança"
|
||||
|
||||
# Análise de impacto de crate específico
|
||||
"Informe o impacto e mudanças necessárias se atualizar o tokio para a versão mais recente"
|
||||
```
|
||||
|
||||
### Exemplos detalhados
|
||||
|
||||
```bash
|
||||
# Análise detalhada incluindo Release Notes
|
||||
cat Cargo.toml && cargo tree
|
||||
"Analise as dependências e para cada crate apresente:
|
||||
1. Versão atual → versão mais recente
|
||||
2. Avaliação de risco (seguro/atenção/perigoso)
|
||||
3. Principais alterações (do CHANGELOG)
|
||||
4. Mudanças em trait bounds
|
||||
5. Correções de código necessárias
|
||||
em formato de tabela"
|
||||
|
||||
# Análise de migração de runtime assíncrono
|
||||
cat Cargo.toml src/main.rs
|
||||
"Apresente todas as mudanças necessárias para migração de async-std para tokio, ou atualização de versão major do tokio"
|
||||
```
|
||||
|
||||
### Critérios de nível de risco
|
||||
|
||||
```text
|
||||
Seguro (🟢):
|
||||
- Atualização de versão de patch (0.1.2 → 0.1.3)
|
||||
- Apenas correções de bug
|
||||
- Garantia de compatibilidade retroativa
|
||||
|
||||
Atenção (🟡):
|
||||
- Atualização de versão minor (0.1.0 → 0.2.0)
|
||||
- Adição de novas funcionalidades
|
||||
- Avisos de descontinuação
|
||||
|
||||
Perigoso (🔴):
|
||||
- Atualização de versão major (0.x.y → 1.0.0, 1.x.y → 2.0.0)
|
||||
- Mudanças disruptivas
|
||||
- Remoção/alteração de API
|
||||
- Mudanças em trait bounds
|
||||
```
|
||||
|
||||
### Execução da atualização
|
||||
|
||||
```bash
|
||||
# Criar backup
|
||||
cp Cargo.toml Cargo.toml.backup
|
||||
cp Cargo.lock Cargo.lock.backup
|
||||
|
||||
# Executar atualização
|
||||
cargo update
|
||||
|
||||
# Verificação após atualização
|
||||
cargo check
|
||||
cargo test
|
||||
cargo clippy
|
||||
```
|
||||
|
||||
### Observações
|
||||
|
||||
Sempre realize verificação de funcionamento após a atualização. Em caso de problemas, restaure usando:
|
||||
|
||||
```bash
|
||||
cp Cargo.toml.backup Cargo.toml
|
||||
cp Cargo.lock.backup Cargo.lock
|
||||
cargo build
|
||||
```
|
||||
Reference in New Issue
Block a user