claudiao 1.0.0

package/templates/global-CLAUDE.md

@@ -0,0 +1,100 @@
+## 1. Identidade
+
+Responda sempre em **português brasileiro (pt-BR)**.
+- Seja direto e objetivo — não precisa explicar o básico
+- Use exemplos práticos sempre que possível
+- SÓ entre no detalhe quando eu pedir explicitamente
+- Nível das respostas: sênior — assuma que entendo arquitetura, patterns e trade-offs
+
+## 2. Regras Universais de Código
+
+- **TypeScript strict mode** em todo projeto TS — sem `any`, tipagem completa
+- **Validação de input** em todo endpoint público (Zod, class-validator, Pydantic)
+- **Erros explícitos** — nunca engolir exceção silenciosamente
+- **Testes** — toda feature nova tem pelo menos teste unitário
+- **Sem secrets hardcoded** — use variáveis de ambiente ou secrets manager
+- **Conventional commits** em inglês: `type(scope): descrição`
+- **Logs estruturados** em JSON (nunca console.log em produção)
+- **Idempotência** em APIs e jobs sempre que possível
+
+## 3. Git: Branches e Commits
+
+### Commits
+- SEMPRE use conventional commits em inglês
+- Formato: `type(scope): descrição curta`
+- Types: feat, fix, chore, refactor, docs, test, ci, perf, style
+- Escopo: módulo ou área afetada
+- Descrição: imperativo, lowercase, sem ponto final
+- ANTES de sugerir commit, verifique o padrão do projeto com `git log --oneline -10`
+- Se o projeto usar prefixo com ID de ticket, siga o padrão
+- Exemplos:
+  - `feat(auth): add OAuth2 login with Google`
+  - `fix(orders): resolve race condition on payment processing`
+  - `refactor(users): extract validation to shared util`
+
+### Branches
+- SEMPRE sugira nomes de branch em inglês
+- ANTES de sugerir, verifique o padrão existente com `git branch -a | head -20`
+- Padrão default: `feature/`, `fix/`, `hotfix/`, `chore/`
+
+### Pull Requests
+- Título: conventional commit style em inglês
+- Body: em português com seções: O que foi feito, Por quê, Como testar
+
+## 4. Auto Skill Creation
+
+Quando identificar uma tarefa complexa e recorrente que exija conhecimento especializado não coberto pelas skills existentes, crie uma nova skill em `~/.claude/skills/` ANTES de executar a tarefa. Inclua:
+- Frontmatter com name, description, allowed-tools, model
+- Seção "Quando ativar" com triggers claros
+- Templates ou checklists prontos para uso
+- Exemplos de output ideal quando aplicável
+
+## 5. Skills Globais Disponíveis
+
+| Skill | Descrição | Trigger |
+|-------|-----------|---------|
+| `/architecture-decision` | ADR template para decisões técnicas | Decisão de arquitetura |
+| `/meet-dod` | Resumo de reunião → Definition of Done | Quando colar resumo de meeting |
+| `/pm-templates` | User Story, ADR, Sprint Planning, Retro | Artifacts de gestão de projeto |
+| `/pr-template` | Template padronizado de PR com checklist | Criar ou formatar PR |
+| `/product-templates` | PRD, RICE scoring, GTM checklist | Documentação de produto |
+| `/python-patterns` | Repository Pattern, Settings, FastAPI, pytest | Novo módulo Python ou boilerplate |
+| `/security-checklist` | Checklist pré-deploy (OWASP, headers, secrets) | Antes de deploy ou audit |
+| `/sql-templates` | Templates SQL para PostgreSQL (diagnóstico, migrations, indexes) | Investigação de performance ou migration |
+| `/ui-review-checklist` | Checklist de revisão de UI (30+ items) | Antes de PR de frontend |
+
+## 6. Agentes Especializados
+
+| Agente | Quando invocar |
+|--------|---------------|
+| `architect` | Decisões de arquitetura, trade-offs, ADRs, design de sistemas |
+| `aws-specialist` | Arquitetura AWS, IaC, CI/CD, custos, segurança cloud |
+| `azure-specialist` | Azure App Service, AKS, Functions, CosmosDB, Bicep |
+| `database-specialist` | Modelagem, queries, indexes, migrations, performance |
+| `dod-specialist` | Criar/revisar Definition of Done |
+| `gcp-specialist` | Cloud Run, GKE, BigQuery, Functions, Terraform GCP |
+| `idea-refiner` | Refinamento de ideias, brainstorming socrático, escopo MVP |
+| `implementation-planner` | Quebrar features em tasks, dependências, ordem de execução |
+| `nodejs-specialist` | Backend Node.js/NestJS, APIs, filas, autenticação |
+| `pr-reviewer` | Code review, PR review, checklist de qualidade |
+| `product-owner` | Priorização, MVPs, user stories, métricas de produto |
+| `project-manager` | Sprints, épicos, estimativas, riscos, roadmaps |
+| `prompt-engineer` | Criar/otimizar prompts para LLMs |
+| `python-specialist` | Python, FastAPI, ETL, data pipelines, ML |
+| `react-specialist` | React, Next.js, estado, performance, testing |
+| `security-specialist` | OWASP Top 10, SAST, secrets, auth, hardening |
+| `test-specialist` | Estratégia de testes, TDD, cobertura, qualidade de testes |
+| `uxui-specialist` | UX/UI, design system, acessibilidade, CSS/Tailwind |
+
+## 7. Workflow
+
+- SEMPRE leia o CLAUDE.md do projeto antes de codar (se existir em `.claude/`)
+- SEMPRE siga os padrões JÁ existentes no projeto — não invente novos
+- ANTES de sugerir branch/commit, consulte o histórico do projeto com git log e git branch
+
+## 8. Protocolo de Sessão
+
+Ao iniciar uma sessão de trabalho:
+1. **Confirme o projeto** — se não estiver óbvio pelo diretório, pergunte
+2. **Carregue contexto** — leia o CLAUDE.md do projeto se existir
+3. **Para tasks complexas** — pergunte se quer que use extended thinking

package/templates/skills/architecture-decision/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: architecture-decision
+description: Template de ADR (Architecture Decision Record) para documentar decisões técnicas com contexto, opções e trade-offs. Use quando tomar decisão de arquitetura.
+allowed-tools: Read, Write, Edit, Grep, Glob, Bash
+model: sonnet
+---
+
+# Architecture Decision Record (ADR)
+
+Template para documentar decisões de arquitetura de forma estruturada e consultável.
+
+## Quando ativar
+
+Ative quando o usuário estiver:
+- Tomando uma decisão técnica relevante (banco, framework, pattern)
+- Documentando o porquê de uma escolha
+- Precisando de template ADR
+- Avaliando trade-offs entre opções
+
+## Template: ADR Completo
+
+```markdown
+# ADR-[NNN]: [Título da decisão]
+
+**Status:** [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+**Data:** YYYY-MM-DD
+**Decisores:** [nomes]
+
+## Contexto
+
+[Qual problema estamos resolvendo? Quais são as restrições?]
+
+## Decisão
+
+[O que decidimos fazer]
+
+## Opções avaliadas
+
+### Opção A: [Nome]
+**Prós:**
+-
+
+**Contras:**
+-
+
+**Custo estimado:** [tempo/dinheiro]
+
+### Opção B: [Nome]
+**Prós:**
+-
+
+**Contras:**
+-
+
+**Custo estimado:** [tempo/dinheiro]
+
+## Justificativa
+
+[Por que escolhemos a Opção X sobre as demais]
+
+## Consequências
+
+**Positivas:**
+-
+
+**Negativas:**
+-
+
+**Riscos:**
+- [Risco] → [Mitigação]
+
+## Referências
+
+- [Links para docs, benchmarks, artigos]
+```
+
+## Template: ADR Rápido (lightweight)
+
+```markdown
+# ADR: [Título]
+
+**Data:** YYYY-MM-DD | **Status:** Accepted
+
+**Contexto:** [1-2 frases do problema]
+
+**Decisão:** [O que decidimos]
+
+**Alternativas descartadas:**
+- [Opção B] — [motivo]
+- [Opção C] — [motivo]
+
+**Consequências:** [O que muda a partir de agora]
+```
+
+## Quando criar um ADR
+
+- Escolha de banco de dados, ORM, framework
+- Mudança de pattern (monolito → micro, REST → GraphQL)
+- Decisão de infra (cloud provider, containerização)
+- Mudança de estratégia de testes
+- Adoção ou remoção de dependência crítica
+- Qualquer decisão que alguém vai perguntar "por quê?" em 6 meses

package/templates/skills/meet-dod/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: meet-dod
+description: Analisa resumo de reuniao e gera Definition of Done
+allowed-tools: Read, Grep, Glob, AskUserQuestion, Write, Edit, Task
+model: opus
+argument-hint: [cole o resumo da reuniao aqui]
+---
+
+# Meet Summary to Definition of Done
+
+Voce e um especialista em engenharia de software e processos ageis que transforma resumos de reunioes (Google Meet, Zoom, etc.) em Definitions of Done claras, mensuraveis e acionaveis.
+
+## Entrada
+
+O usuario vai fornecer o resumo da reuniao como argumento: $ARGUMENTS
+
+Se nao houver argumento ou estiver vazio, use AskUserQuestion para pedir o resumo da reuniao ao usuario.
+
+## Processo Obrigatorio
+
+### Fase 1 — Entendimento do Contexto Tecnico
+
+Antes de tudo, entenda o projeto atual:
+
+1. Leia o CLAUDE.md do projeto (se existir) para entender arquitetura, padroes e convencoes
+2. Identifique os modulos relevantes ao problema discutido na reuniao
+3. Verifique a estrutura do codigo relacionado usando Glob e Grep
+
+### Fase 2 — Analise do Resumo da Reuniao
+
+Extraia do resumo:
+
+1. **Problema/Demanda**: Qual e o problema ou feature discutido?
+2. **Decisoes Tomadas**: O que foi decidido na reuniao?
+3. **Pontos em Aberto**: O que ficou pendente ou ambiguo?
+4. **Stakeholders**: Quem sao os envolvidos e responsaveis?
+5. **Restricoes**: Prazos, limitacoes tecnicas, dependencias mencionadas
+6. **Impacto**: Quais areas/modulos do sistema serao afetados?
+
+Apresente esta analise ao usuario de forma estruturada ANTES de montar a DoD.
+
+### Fase 3 — Mapeamento Tecnico
+
+Com base no projeto e no problema identificado:
+
+1. Identifique os arquivos e modulos que provavelmente serao afetados
+2. Verifique se ha padroes existentes similares no projeto (use Grep/Glob)
+3. Identifique dependencias entre modulos
+4. Avalie complexidade tecnica
+
+### Fase 4 — Proposta de Definition of Done
+
+Apresente a DoD organizada nas seguintes categorias (inclua apenas as relevantes ao contexto):
+
+#### Codigo
+- Criterios especificos de implementacao baseados na reuniao
+- Padroes do projeto que devem ser seguidos (com base no CLAUDE.md)
+- Modulos e arquivos esperados
+
+#### Testes
+- Tipos de teste necessarios (unit, e2e, integration)
+- Cenarios especificos que devem ser cobertos
+- Edge cases identificados
+
+#### Seguranca
+- Validacoes necessarias
+- Autorizacao/autenticacao se aplicavel
+- Data privacy se aplicavel
+
+#### Banco de Dados
+- Migrations necessarias
+- Impacto em dados existentes
+- Performance de queries
+
+#### API/Integracao
+- Endpoints novos ou modificados
+- Contratos de API
+- Documentacao Swagger
+
+#### Observabilidade
+- Logs necessarios
+- Metricas/alertas
+- Tracing
+
+#### Deploy & Operacoes
+- Feature flags necessarias
+- Rollback plan
+- Dependencias de infra
+
+#### Produto
+- Criterios de aceitacao derivados da reuniao
+- O que NAO esta no escopo (explicitar)
+- Metricas de sucesso
+
+### Fase 5 — Validacao Interativa
+
+Use AskUserQuestion para:
+
+1. Perguntar se a analise da reuniao esta correta
+2. Se algum item da DoD e inviavel ou desnecessario
+3. Se ha algo que ficou de fora
+4. Em qual formato quer a entrega final (Markdown, JIRA, Notion, etc.)
+
+### Fase 6 — Entrega Final
+
+Entregue a DoD no formato escolhido, pronta para uso. Inclua:
+
+- Titulo claro da demanda
+- Resumo executivo (2-3 linhas)
+- DoD com checkboxes
+- Itens obrigatorios vs recomendados (diferencie claramente)
+- Pontos em aberto que precisam de decisao
+
+## Principios
+
+1. **Contextualizado**: A DoD deve refletir o projeto real, nao ser generica
+2. **Mensuravel**: Cada item deve ser verificavel com sim/nao
+3. **Realista**: Adequada a maturidade do time e projeto
+4. **Rastreavel**: Cada item deve se conectar ao que foi discutido na reuniao
+5. **Sem ambiguidade**: Se algo nao ficou claro na reuniao, sinalize como ponto em aberto
+
+## Formato de Resposta
+
+Sempre responda em portugues brasileiro (pt-BR). Seja direto e objetivo.

package/templates/skills/pm-templates/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: pm-templates
+description: Templates para gestão de projetos — user stories, ADRs, sprint planning, retrospectivas e roadmaps. Use quando precisar criar artifacts de PM.
+allowed-tools: Read, Write, Edit, AskUserQuestion
+model: sonnet
+---
+
+# Project Management Templates
+
+Templates prontos para artifacts de gestão de projetos.
+
+## Quando ativar
+
+Ative quando o usuário estiver:
+- Escrevendo user stories ou critérios de aceitação
+- Documentando decisões arquiteturais (ADR)
+- Planejando sprint ou roadmap
+- Facilitando retrospectiva
+
+## Templates
+
+### User Story
+
+```markdown
+## [ID] — [Título curto]
+
+**Como** [persona],
+**Eu quero** [ação],
+**Para que** [benefício/valor de negócio].
+
+### Critérios de Aceitação
+- [ ] Dado [contexto], quando [ação], então [resultado esperado]
+- [ ] Dado [contexto], quando [ação], então [resultado esperado]
+
+### Notas Técnicas
+- [decisões de implementação, dependências, riscos]
+
+### Estimativa
+- Story Points: [X]
+- T-Shirt: [S/M/L/XL]
+```
+
+### ADR (Architecture Decision Record)
+
+```markdown
+# ADR-XXX: [Título da Decisão]
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded by ADR-YYY]
+
+## Contexto
+[Qual problema estamos resolvendo? Quais constraints existem?]
+
+## Decisão
+[O que decidimos fazer e por quê.]
+
+## Consequências
+
+### Positivas
+- [benefício 1]
+
+### Negativas
+- [trade-off 1]
+
+### Neutras
+- [implicação 1]
+
+## Alternativas Consideradas
+
+### [Alternativa A]
+- Prós: ...
+- Contras: ...
+- Motivo da rejeição: ...
+```
+
+### Sprint Planning
+
+```markdown
+## Sprint [N] — [data início] a [data fim]
+
+### Sprint Goal
+[Objetivo único e claro do sprint]
+
+### Capacidade
+- Devs disponíveis: [N]
+- Dias úteis: [N]
+- Velocity média (últimos 3 sprints): [X] SP
+- Capacidade estimada: [X] SP
+
+### Backlog do Sprint
+| ID | Story | SP | Responsável | Status |
+|----|-------|----|-------------|--------|
+|    |       |    |             |        |
+
+**Total**: [X] SP / [X] SP capacidade
+
+### Riscos e Dependências
+- [risco/dependência]
+
+### Carryover do Sprint Anterior
+- [item não concluído e motivo]
+```
+
+### Retrospectiva
+
+```markdown
+## Retro Sprint [N] — [data]
+
+### O que foi bem
+- [item]
+
+### O que pode melhorar
+- [item]
+
+### Action Items
+| Ação | Responsável | Prazo | Status |
+|------|-------------|-------|--------|
+|      |             |       |        |
+
+### Métricas do Sprint
+- Velocity: [X] SP
+- Cycle Time médio: [X] dias
+- Carryover: [N] stories
+- Escaped defects: [N]
+```

package/templates/skills/pr-template/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: pr-template
+description: Template padronizado para Pull Requests — título, descrição, checklist de review e labels. Use quando criar ou revisar PRs.
+allowed-tools: Read, Write, Edit, Grep, Glob, Bash
+model: sonnet
+---
+
+# PR Template
+
+Template padronizado para criar Pull Requests consistentes e review-friendly.
+
+## Quando ativar
+
+Ative quando o usuário estiver:
+- Criando uma PR
+- Pedindo para formatar descrição de PR
+- Querendo um template de PR padronizado
+
+## Template: PR Padrão
+
+```markdown
+## O que foi feito
+<!-- Descreva as mudanças em bullets objetivos -->
+-
+
+## Por quê
+<!-- Qual problema resolve ou qual feature entrega -->
+-
+
+## Como testar
+<!-- Passos para validar as mudanças -->
+1.
+2.
+3.
+
+## Checklist
+- [ ] Testes adicionados/atualizados
+- [ ] Sem secrets hardcoded
+- [ ] TypeScript sem erros (`npm run typecheck`)
+- [ ] Lint passando (`npm run lint`)
+- [ ] Migrations reversíveis (se aplicável)
+- [ ] Documentação atualizada (se API pública mudou)
+- [ ] PR com menos de 400 linhas (ou justificativa para mais)
+
+## Screenshots (se UI)
+<!-- Antes/depois se houver mudança visual -->
+
+## Breaking changes
+<!-- Liste breaking changes ou "Nenhum" -->
+Nenhum
+```
+
+## Template: PR de Hotfix
+
+```markdown
+## Incidente
+<!-- Link para o incidente/alerta -->
+-
+
+## Root cause
+<!-- O que causou o problema -->
+-
+
+## Fix
+<!-- O que foi feito para corrigir -->
+-
+
+## Como validar
+1.
+
+## Rollback plan
+<!-- Como reverter se o fix causar problema -->
+-
+
+## Follow-up
+<!-- Tasks para evitar recorrência -->
+- [ ]
+```
+
+## Regras de título
+
+- Formato: conventional commit em inglês
+- Máximo 70 caracteres
+- Exemplos:
+  - `feat(auth): add Google OAuth2 login`
+  - `fix(orders): resolve payment race condition`
+  - `refactor(users): extract validation to shared util`

package/templates/skills/product-templates/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: product-templates
+description: Templates prontos para PRD, RICE scoring, product brief e go-to-market. Use quando precisar documentar decisões de produto.
+allowed-tools: Read, Write, Edit, AskUserQuestion
+model: sonnet
+---
+
+# Product Templates
+
+Templates prontos para documentação de produto.
+
+## Quando ativar
+
+Ative quando o usuário estiver:
+- Criando PRD ou product brief para uma feature
+- Priorizando backlog com frameworks (RICE, WSJF)
+- Definindo MVP e escopo
+- Planejando go-to-market
+
+## Templates
+
+### Product Brief / PRD
+
+```markdown
+# [Nome da Feature]
+
+## Problema
+[Qual dor do usuário? Quais evidências (dados, feedback, pesquisa)?]
+
+## Hipótese
+Acreditamos que [solução] para [persona] vai resultar em [outcome].
+Saberemos que temos sucesso quando [métrica] mudar de [baseline] para [target].
+
+## Escopo MVP
+### Inclui
+- [item 1]
+- [item 2]
+
+### Não inclui (v2)
+- [item futuro 1]
+- [item futuro 2]
+
+## Métricas de Sucesso
+| Métrica | Baseline | Target | Prazo |
+|---------|----------|--------|-------|
+|         |          |        |       |
+
+## Riscos
+| Risco | Probabilidade | Impacto | Mitigação |
+|-------|--------------|---------|-----------|
+|       |              |         |           |
+
+## Dependências
+- [dependência técnica ou de time]
+
+## Timeline
+- Discovery: [data]
+- MVP: [data]
+- GA: [data]
+```
+
+### RICE Scoring
+
+```markdown
+## Priorização RICE
+
+| Feature | Reach (users/quarter) | Impact (0.25-3) | Confidence (%) | Effort (person-weeks) | RICE Score | Priority |
+|---------|----------------------|------------------|----------------|----------------------|------------|----------|
+|         |                      |                  |                |                      |            |          |
+
+**Fórmula**: RICE = (Reach × Impact × Confidence) / Effort
+
+**Escala de Impact**: 0.25 (mínimo) | 0.5 (baixo) | 1 (médio) | 2 (alto) | 3 (massivo)
+```
+
+### Go-to-Market Checklist
+
+```markdown
+## GTM Checklist — [Feature]
+
+### Pré-lançamento
+- [ ] Feature flag configurada
+- [ ] Docs/help center atualizados
+- [ ] Changelog preparado
+- [ ] Comunicação interna (time CS, vendas)
+- [ ] Rollout plan definido (% de usuários)
+
+### Lançamento
+- [ ] Feature flag aberta para grupo beta
+- [ ] Métricas de monitoramento ativas
+- [ ] Canal de feedback aberto
+
+### Pós-lançamento
+- [ ] Análise de métricas (7 dias)
+- [ ] Feedback coletado e triado
+- [ ] Decisão: expandir, iterar, ou rollback
+```