jarvis-ai-framework 2.1.1 → 3.2.0

package/skills/eng-platform/references/13-seguranca-fundamentos.md

@@ -0,0 +1,26 @@
+# 13. Fundamentos de Segurança da Informação
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Ter o mapa conceitual de segurança que sustenta todas as especializações. Complementa a skill 9.
+
+**Conhecimentos:** tríade CIA; risco: ativo, ameaça, vulnerabilidade, probabilidade, impacto; modelagem de ameaças (STRIDE, fronteiras de confiança); segurança de aplicações: ciclo seguro e classes de vulnerabilidade; arquitetura: defesa em profundidade, menor privilégio, falha segura, zero trust; identidade e acesso: autenticação, autorização, federação, privilégios; operações: logs, detecção, triagem; resposta a incidentes: conter, erradicar, recuperar, aprender; governança, risco e conformidade: controles, evidências, auditoria; engenharia de privacidade: minimização e privacidade por projeto; gestão de vulnerabilidades.
+
+**Princípios:**
+- Segurança é gestão de risco, não eliminação de ameaça.
+- Assuma violação: detectar e responder pesa tanto quanto prevenir.
+- Controle sem evidência não passa em auditoria; controle que trava o negócio é contornado.
+
+**Fora do escopo:** produtos, scanners, regras e exploits específicos; interpretação jurídica.
+
+**Pergunta-chave:** Quais são seus ativos mais valiosos, quem os ameaçaria e como você notaria o ataque?
+
+**Referências:**
+- NIST, *Cybersecurity Framework 2.0* (2024)
+- ISO/IEC 27001:2022 e 27002:2022
+- Anderson, *Security Engineering* (3ª ed.)
+- Shostack, *Threat Modeling: Designing for Security*
+- NIST SP 800-61 (resposta a incidentes) e SP 800-63 (identidade digital)
+- OWASP, *SAMM* e *Top 10*
+
+**Usam mais:** todas as funções de Security, DevSecOps, Architecture

package/skills/eng-platform/references/14-profiling-performance.md

@@ -0,0 +1,23 @@
+# 14. Profiling e Diagnóstico de Performance
+
+**Nível:** IMPORTANTE · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Encontrar onde o tempo e o recurso realmente vão, em vez de supor.
+
+**Conhecimentos:** profiling de CPU (amostragem vs. instrumentação, flame graphs, hotspots); profiling de memória (heap, alocação, vazamento, tuning de garbage collection); profiling de I/O (disco, rede, latência de query); profiling por ambiente (processo local, container, função serverless); correlação entre profile e trace distribuído; medir antes de otimizar; performance budget e detecção de regressão.
+
+**Princípios:**
+- Não otimiza o que não mediu; não promete o que não validou contra baseline.
+- O maior gargalo primeiro: otimização sem priorização por impacto é desperdício.
+- Profile em condição parecida com produção — ambiente sintético mente.
+
+**Fora do escopo:** sintaxe de um profiler específico (ex: pprof, async-profiler, clinic.js).
+
+**Pergunta-chave:** Qual é o maior gargalo agora, e quanto essa otimização vale antes de implementá-la?
+
+**Referências:**
+- Gregg, *Systems Performance* (2ª ed.)
+- Gregg, método USE
+- Beyer et al., *Site Reliability Engineering*, cap. 6
+
+**Usam mais:** SRE, DevOps, Platform Engineering, Systems Engineering

package/skills/eng-platform/references/15-testes-carga-chaos.md

@@ -0,0 +1,23 @@
+# 15. Testes de Carga e Chaos Engineering
+
+**Nível:** IMPORTANTE · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Descobrir o ponto de ruptura e o modo de falha antes que a produção descubra por você.
+
+**Conhecimentos:** testes de carga, estresse, pico e resistência (soak); planejamento de capacidade e ponto de ruptura; cenários realistas (dados e padrão de tráfego parecidos com produção); chaos engineering — injeção deliberada de falha (latência, erro, instância, zona); blast radius e critério de abortar; validar auto-scaling e failover sob carga real; portões de performance no pipeline (bloquear deploy por regressão).
+
+**Princípios:**
+- Nunca gerar carga ou injetar falha em produção sem aprovação, blast radius definido e plano de rollback.
+- Testar o que o usuário realmente faz, não um cenário sintético confortável.
+- O objetivo é aprender o modo de falha, não só confirmar que "funciona sob carga".
+
+**Fora do escopo:** sintaxe de uma ferramenta específica (ex: k6, Gatling, Chaos Mesh, Gremlin).
+
+**Pergunta-chave:** Se isso falhar exatamente como você está prestes a testar, qual é o raio de impacto e quem precisa saber?
+
+**Referências:**
+- Basiri et al., *Chaos Engineering* (Netflix, O'Reilly)
+- Beyer et al., *Site Reliability Engineering*, cap. sobre gestão de capacidade
+- Rosenthal & Jones, *Chaos Engineering: System Resiliency in Practice*
+
+**Usam mais:** SRE, DevOps, Platform Engineering, Infrastructure/Platform Architecture

package/skills/eng-platform/references/16-cache-multicamada.md

@@ -0,0 +1,22 @@
+# 16. Cache Multi-Camada
+
+**Nível:** IMPORTANTE · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Decidir onde, o quê e por quanto tempo cachear — e como invalidar sem servir dado velho como se fosse novo.
+
+**Conhecimentos:** camadas de cache (aplicação/in-memory, distribuído, banco de dados, CDN/edge, browser/cliente); trade-off de consistência vs. latência; estratégias de invalidação (TTL, write-through, write-behind, invalidação por evento); cache stampede e thundering herd; chave de cache e cardinalidade; cache de resultado de query vs. cache de objeto computado; medir hit rate antes de adicionar mais uma camada.
+
+**Princípios:**
+- Cache sem estratégia de invalidação é bug de dado velho esperando para acontecer.
+- Cada camada adicionada é mais um lugar onde o dado pode discordar da fonte — adicione só com ganho medido.
+- Dado sensível em cache segue a mesma política de acesso e expiração do dado original.
+
+**Fora do escopo:** sintaxe ou configuração de um produto específico (ex: Redis, Memcached, CloudFront).
+
+**Pergunta-chave:** Se este dado em cache estiver errado por 5 minutos, alguém percebe — e o que isso custa?
+
+**Referências:**
+- Kleppmann, *Designing Data-Intensive Applications*, cap. sobre caching e consistência
+- Documentação de padrões de cache da AWS/Cloudflare (cache-aside, write-through, write-behind)
+
+**Usam mais:** Platform Engineering, DevOps, Cloud Engineering, Infrastructure/Platform Architecture

package/skills/eng-platform/references/2-redes.md

@@ -0,0 +1,23 @@
+# 2. Redes
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Raciocinar sobre como pacotes e nomes chegam de A a B, e por que não chegam.
+
+**Conhecimentos:** modelos OSI e TCP/IP; IP, CIDR, sub-redes e roteamento; TCP (handshake, congestionamento) vs. UDP; DNS e resolução de nomes; HTTP e TLS (certificados, cadeia de confiança); NAT, firewalls e proxies; balanceamento L4/L7; VPN, segmentação e MTU; latência vs. largura de banda.
+
+**Princípios:**
+- A rede é não confiável: latência, perda e partição acontecem.
+- Segmente para limitar o raio de impacto.
+- DNS e certificados expirados estão por trás de muitos incidentes.
+
+**Fora do escopo:** configuração de equipamentos de um fornecedor específico.
+
+**Pergunta-chave:** Por que um nome resolve, mas a conexão não se estabelece?
+
+**Referências:**
+- Stevens, *TCP/IP Illustrated*, vol. 1
+- Kurose & Ross, *Computer Networking: A Top-Down Approach*
+- RFCs 791 (IP), 793 (TCP), 1035 (DNS), 8446 (TLS 1.3)
+
+**Usam mais:** Network, Cloud, Cloud Security, SRE

package/skills/eng-platform/references/3-cloud.md

@@ -0,0 +1,24 @@
+# 3. Computação em Nuvem
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Dominar o modelo operacional da nuvem, independentemente do provedor.
+
+**Conhecimentos:** características essenciais (autoatendimento, elasticidade, medição); IaaS, PaaS, SaaS e funções sob demanda; responsabilidade compartilhada; regiões, zonas e domínios de falha; contas/projetos e landing zone; redes virtuais; armazenamento de bloco, objeto e arquivo; multi-tenancy; portabilidade e lock-in; pilares de arquitetura bem projetada.
+
+**Princípios:**
+- Nuvem é modelo operacional, não só localização.
+- Governança começa na conta, antes da primeira carga.
+- Serviço gerenciado transfere operação, não responsabilidade.
+
+**Fora do escopo:** nomes de serviços, consoles e SDKs de um provedor.
+
+**Pergunta-chave:** Que parte da segurança continua sua num serviço totalmente gerenciado?
+
+**Referências:**
+- NIST SP 800-145, *The NIST Definition of Cloud Computing*
+- Pilares comuns dos frameworks Well-Architected dos grandes provedores
+- CNCF, *Cloud Native Definition*
+- Kleppmann, *Designing Data-Intensive Applications*
+
+**Usam mais:** Cloud, Cloud Security, Architecture, FinOps

package/skills/eng-platform/references/4-iac-automacao.md

@@ -0,0 +1,24 @@
+# 4. Infraestrutura como Código e Automação
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Tratar infraestrutura como software: versionada, revisada, testada e reproduzível.
+
+**Conhecimentos:** declarativo vs. imperativo; idempotência e convergência; estado desejado vs. real e drift; módulos reutilizáveis; imutabilidade (substituir, não consertar); ambientes efêmeros e paridade; gestão de estado e segredos; revisão por pull request, testes de infraestrutura, policy as code; GitOps; automação de runbooks.
+
+**Princípios:**
+- Tudo que se faz duas vezes se automatiza.
+- Git é a fonte da verdade; mudança manual é dívida.
+- Ambientes devem ser descartáveis e recriáveis.
+
+**Fora do escopo:** sintaxe de uma ferramenta de provisionamento ou de configuração.
+
+**Pergunta-chave:** Se o ambiente de produção sumisse hoje, em quanto tempo e com que confiança você o recria?
+
+**Referências:**
+- Morris, *Infrastructure as Code* (2ª ed.)
+- Humble & Farley, *Continuous Delivery*
+- OpenGitOps, *Principles* v1.0
+- Limoncelli et al., *The Practice of System and Network Administration*
+
+**Usam mais:** Automation, DevOps, Cloud, Platform

package/skills/eng-platform/references/5-containers-orquestracao.md

@@ -0,0 +1,25 @@
+# 5. Contêineres e Orquestração
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Compreender empacotamento isolado e orquestração declarativa de cargas.
+
+**Conhecimentos:** isolamento por namespaces e cgroups; imagem vs. contêiner e camadas; registries, assinatura e reprodutibilidade; stateless vs. stateful; scheduling e bin packing; descoberta de serviço; health checks e probes; requests e limits de recursos; autoscaling; laço de reconciliação (controladores/operators); configuração e segredos externalizados.
+
+**Princípios:**
+- Contêiner é processo isolado, não máquina virtual.
+- Orquestração é reconciliar estado desejado com o observado.
+- Aplicação deve ser descartável e reiniciável.
+
+**Fora do escopo:** comandos, manifestos e APIs de um orquestrador específico.
+
+**Pergunta-chave:** O que acontece com o estado de um contêiner quando ele é reagendado em outro nó?
+
+**Referências:**
+- Burns, *Designing Distributed Systems*
+- Verma et al., *Large-scale cluster management at Google with Borg* (EuroSys 2015)
+- NIST SP 800-190, *Application Container Security Guide*
+- Wiggins, *The Twelve-Factor App*
+- OCI Image & Runtime Specifications
+
+**Usam mais:** Platform, DevOps, Cloud, SRE

package/skills/eng-platform/references/6-cicd-entrega.md

@@ -0,0 +1,24 @@
+# 6. CI/CD e Entrega de Software
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Entregar mudanças pequenas, frequentes e seguras até a produção.
+
+**Conhecimentos:** integração contínua e trunk-based development; pipeline como código; build reprodutível e artefatos versionados; rolling, blue/green, canary; feature flags: deploy ≠ release; rollback vs. roll-forward; testes na pipeline; promoção entre ambientes; migrações de banco compatíveis; métricas DORA (lead time, frequência, falha de mudança, tempo de restauração).
+
+**Princípios:**
+- Lotes pequenos reduzem risco e facilitam diagnóstico.
+- O mesmo artefato percorre todos os ambientes.
+- Pipeline lenta ou instável é incidente de produtividade.
+
+**Fora do escopo:** sintaxe de um orquestrador de pipelines ou de uma plataforma de CI.
+
+**Pergunta-chave:** Como reverter uma mudança que já migrou o esquema do banco?
+
+**Referências:**
+- Humble & Farley, *Continuous Delivery*
+- Forsgren, Humble & Kim, *Accelerate*
+- Kim et al., *The DevOps Handbook* (2ª ed.)
+- DORA, *State of DevOps Report*
+
+**Usam mais:** DevOps, DevSecOps, Platform, DevEx

package/skills/eng-platform/references/7-observabilidade.md

@@ -0,0 +1,24 @@
+# 7. Observabilidade e Monitoramento
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Responder a perguntas novas sobre o sistema sem precisar alterá-lo.
+
+**Conhecimentos:** métricas, logs, traces e eventos; cardinalidade e custo; golden signals, RED e USE; SLI e SLO; alerta por sintoma, não por causa; alertas acionáveis vs. ruído; correlação por identificadores de contexto; amostragem e retenção; dashboards por pergunta; instrumentação padronizada.
+
+**Princípios:**
+- Alerta só se exige ação humana imediata.
+- Meça o que o usuário sente, não só o que a máquina faz.
+- Contexto compartilhado entre sinais vale mais que volume.
+
+**Fora do escopo:** configuração de uma ferramenta de coleta, armazenamento ou visualização.
+
+**Pergunta-chave:** O alerta das 3h indica uma ação humana imediata ou pode esperar?
+
+**Referências:**
+- Beyer et al., *Site Reliability Engineering*, cap. 6
+- Majors, Fong-Jones & Miranda, *Observability Engineering*
+- Gregg, método USE
+- Especificação OpenTelemetry
+
+**Usam mais:** SRE, DevOps, DevEx, Systems

package/skills/eng-platform/references/8-confiabilidade-sre.md

@@ -0,0 +1,24 @@
+# 8. Confiabilidade e Gestão de Incidentes
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Gerenciar confiabilidade como característica de produto, com metas explícitas.
+
+**Conhecimentos:** SLI, SLO e SLA; error budget e política associada; toil e automação; papéis, severidade e comunicação em incidentes; postmortem sem culpa; fatores contribuintes vs. causa raiz única; planejamento de capacidade; testes de caos e game days; on-call sustentável; revisão de prontidão para produção.
+
+**Princípios:**
+- 100% é a meta errada; defina quanta falha é aceitável.
+- Aprenda com o incidente sem buscar culpados.
+- Reduza toil antes de contratar mais operação.
+
+**Fora do escopo:** processos de uma empresa ou de uma ferramenta de incidentes.
+
+**Pergunta-chave:** O error budget acabou. O que muda na forma de entregar?
+
+**Referências:**
+- Beyer et al., *Site Reliability Engineering* (2016)
+- Beyer et al., *The Site Reliability Workbook* (2018)
+- Nygard, *Release It!* (2ª ed.)
+- Dekker, *The Field Guide to Understanding 'Human Error'*
+
+**Usam mais:** SRE, DevOps, Systems, Infrastructure

package/skills/eng-platform/references/9-seguranca-infra.md

@@ -0,0 +1,26 @@
+# 9. Segurança de Infraestrutura e DevSecOps
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Incorporar segurança como propriedade automatizada da plataforma, não como portão manual.
+
+**Conhecimentos:** menor privilégio e gestão de identidade e acesso; zero trust; segredos: armazenamento e rotação; criptografia em trânsito e em repouso; gestão de chaves; hardening e baselines; gestão de vulnerabilidades e patches; cadeia de suprimentos (SBOM, assinatura, proveniência); varreduras na pipeline (shift-left); logs de auditoria e detecção; conformidade como código; postura de segurança em nuvem.
+
+**Princípios:**
+- Defesa em profundidade; assuma que haverá violação.
+- Credencial de longa duração é passivo.
+- Controles automatizados e visíveis superam revisões manuais.
+
+**Fora do escopo:** regras e produtos de segurança de um fornecedor específico.
+
+**Pergunta-chave:** Um token da pipeline vazou. Qual é o alcance do dano e como você o limita?
+
+**Referências:**
+- NIST SP 800-207, *Zero Trust Architecture*
+- NIST SP 800-218, *SSDF*
+- SLSA Framework
+- NIST Cybersecurity Framework 2.0
+- CIS Benchmarks
+- OWASP DevSecOps Guideline
+
+**Usam mais:** DevSecOps, Cloud Security, Platform, Architecture

package/skills/eng-platform/references/especializacoes.md

@@ -0,0 +1,34 @@
+# Skill Base Platform & Infrastructure — Funções × Skills
+
+Cada função **parte da mesma base**; o que muda é o peso. Núcleo = domínio esperado; apoio = noção sólida (números = skills do INDEX).
+
+| Função | Núcleo (●) | Apoio (○) |
+|--------|-----------|-----------|
+| DevOps | 4·Infraestrutura como Código e Automação, 6·CI/CD e Entrega de Software, 7·Observabilidade e Monitoramento, 5·Contêineres e Orquestração | 1, 3, 8, 9, 11, 14, 15 |
+| SRE | 7·Observabilidade e Monitoramento, 8·Confiabilidade e Gestão de Incidentes, 10·Resiliência e Arquitetura de Infraestrutura, 1·Fundamentos de Sistemas | 2, 3, 4, 5, 6, 14, 15 |
+| Platform Engineering | 11·Plataforma como Produto e DevEx, 5·Contêineres e Orquestração, 4·Infraestrutura como Código e Automação, 6·CI/CD e Entrega de Software | 3, 7, 9, 12, 14, 16 |
+| Cloud Engineering | 3·Computação em Nuvem, 4·Infraestrutura como Código e Automação, 2·Redes, 5·Contêineres e Orquestração | 1, 6, 9, 10, 12, 14, 16 |
+| Performance Engineering | 14·Profiling e Diagnóstico de Performance, 15·Testes de Carga e Chaos Engineering, 16·Cache Multi-Camada, 7·Observabilidade e Monitoramento | 1, 3, 5, 6, 8 |
+| Infrastructure Engineering | 1·Fundamentos de Sistemas, 2·Redes, 4·Infraestrutura como Código e Automação, 10·Resiliência e Arquitetura de Infraestrutura | 3, 5, 7, 8 |
+| DevSecOps | 9·Segurança de Infraestrutura e DevSecOps, 6·CI/CD e Entrega de Software, 4·Infraestrutura como Código e Automação, 5·Contêineres e Orquestração | 3, 7, 8, 13 |
+| Cloud Security | 9·Segurança de Infraestrutura e DevSecOps, 3·Computação em Nuvem, 13·Fundamentos de Segurança da Informação, 2·Redes | 4, 5, 7, 10 |
+| Infrastructure / Platform Architecture | 10·Resiliência e Arquitetura de Infraestrutura, 3·Computação em Nuvem, 11·Plataforma como Produto e DevEx, 9·Segurança de Infraestrutura e DevSecOps | 2, 4, 5, 8, 12 |
+| Developer Experience (DevEx) | 11·Plataforma como Produto e DevEx, 6·CI/CD e Entrega de Software, 7·Observabilidade e Monitoramento | 4, 5, 8 |
+| Network Engineering | 2·Redes, 1·Fundamentos de Sistemas, 9·Segurança de Infraestrutura e DevSecOps, 10·Resiliência e Arquitetura de Infraestrutura | 3, 4, 7 |
+| Systems Engineering | 1·Fundamentos de Sistemas, 2·Redes, 10·Resiliência e Arquitetura de Infraestrutura, 7·Observabilidade e Monitoramento | 4, 8, 9 |
+| Infrastructure Automation | 4·Infraestrutura como Código e Automação, 6·CI/CD e Entrega de Software, 5·Contêineres e Orquestração, 1·Fundamentos de Sistemas | 3, 7, 9 |
+| FinOps | 12·FinOps e Gestão de Custos, 3·Computação em Nuvem, 7·Observabilidade e Monitoramento | 4, 5, 10, 11 |
+| Application Security | 13·Fundamentos de Segurança da Informação, 6·CI/CD e Entrega de Software, 9·Segurança de Infraestrutura e DevSecOps | 4, 5, 7 |
+| Security Engineering | 13·Fundamentos de Segurança da Informação, 9·Segurança de Infraestrutura e DevSecOps, 4·Infraestrutura como Código e Automação, 6·CI/CD e Entrega de Software | 3, 5, 7, 8 |
+| Security Architecture | 13·Fundamentos de Segurança da Informação, 9·Segurança de Infraestrutura e DevSecOps, 3·Computação em Nuvem, 10·Resiliência e Arquitetura de Infraestrutura | 2, 4, 5, 11 |
+| Infrastructure Security | 9·Segurança de Infraestrutura e DevSecOps, 2·Redes, 1·Fundamentos de Sistemas, 13·Fundamentos de Segurança da Informação | 4, 5, 7, 10 |
+| Identity & Access Management | 13·Fundamentos de Segurança da Informação, 9·Segurança de Infraestrutura e DevSecOps, 3·Computação em Nuvem, 4·Infraestrutura como Código e Automação | 6, 7 |
+| Security Operations | 7·Observabilidade e Monitoramento, 13·Fundamentos de Segurança da Informação, 2·Redes, 9·Segurança de Infraestrutura e DevSecOps | 1, 4, 8 |
+| Threat Modeling | 13·Fundamentos de Segurança da Informação, 3·Computação em Nuvem, 2·Redes, 10·Resiliência e Arquitetura de Infraestrutura | 5, 9 |
+| Incident Response | 13·Fundamentos de Segurança da Informação, 7·Observabilidade e Monitoramento, 8·Confiabilidade e Gestão de Incidentes, 1·Fundamentos de Sistemas | 2, 9, 10 |
+| GRC | 13·Fundamentos de Segurança da Informação, 9·Segurança de Infraestrutura e DevSecOps | 3, 4, 7, 10 |
+| Privacy Engineering | 13·Fundamentos de Segurança da Informação, 9·Segurança de Infraestrutura e DevSecOps | 3, 4, 7 |
+
+**Funções de Security:** esta base dá o panorama (skill 13) e a operação em infraestrutura (skill 9). A profundidade de código seguro está na *Skill Base Backend/Frontend* (segurança), a de privacidade de dados na *Skill Base Data* (segurança e privacidade) e a de segurança de IA na *Skill Base AI*. Application Security e Privacy Engineering devem combinar essas bases.
+
+> Uma função não *limita* o estudo: serve para priorizar a ordem. Lacunas no núcleo são prioridade; lacunas no apoio são aceitáveis.

package/skills/eng-qa/SKILL.md

@@ -0,0 +1,283 @@
+---
+name: eng-qa
+description: >
+  Skill base de qualidade e testes, válida em qualquer stack, framework de teste ou ferramenta de
+  automação: fundamentos de qualidade, estratégia e planejamento, design de casos, testes manuais e
+  exploratórios, automação, API/integração/contrato, interface/compatibilidade/mobile, performance,
+  confiabilidade, segurança, acessibilidade, dados de teste, gestão de testes e defeitos, e
+  arquitetura de QA. Pode ser complementada por especializações registradas em QA_SPECIALIZATIONS
+  (ex: eng-qa-planner).
+  Trigger: Use para planejar estratégia de testes, identificar lacunas de cobertura, projetar casos
+  de teste, decidir o que automatizar ou para qualquer dúvida sobre qualidade de software em geral.
+license: AGPL-3.0
+compatibility: Designed for Claude Code (or similar products)
+allowed-tools: Read Write Edit Glob Grep Bash
+metadata:
+  author: jarvis-team
+  version: "1.0"
+  area: qa
+# Campos Claude Code-specific (não fazem parte da spec oficial agentskills.io):
+argument-hint: "[estrategia|design-casos|automacao|performance|seguranca|a11y] [contexto]"
+disable-model-invocation: false
+---
+
+# Eng QA - Skill Base de Qualidade e Testes
+
+Você é uma **pessoa especialista em qualidade e testes sênior**, com domínio dos princípios que valem em qualquer stack, framework de teste ou ferramenta de automação: estratégia de risco, design de casos, automação, tipos de teste não funcionais, gestão de defeitos e arquitetura de qualidade.
+
+## Objetivo
+
+Garantir que o software tenha a cobertura de testes e a qualidade adequadas ao risco, aplicando a **base universal** de QA. Este skill não presume um framework de teste ou ferramenta: ele descobre o que o projeto já usa pelo próprio código (suíte existente, CI, convenções) e segue o padrão que encontra.
+
+## Entrada
+
+- `$ARGUMENTS` - Operação, funcionalidade ou problema a resolver (ex: `plano-de-testes-checkout`, `identificar-gaps-cobertura`, `design-casos-cadastro`, `estrategia-performance-busca`)
+
+## Recursos
+
+- **ENV**: `$IDE/ENV.md` (variáveis de ambiente e configurações do projeto)
+- **Base universal**: os 15 temas em [references/](references/), carregados sob demanda
+- **Funções × skills**: [references/especializacoes.md](references/especializacoes.md) — peso por função (Test Automation, Manual, Performance, Quality Engineering etc.)
+- **Saída**: planos de teste, casos de teste e relatórios de gap no repositório atual
+
+---
+
+## Pré-requisito
+
+Verificar se o `ENV.md` existe e se as variáveis necessárias ao projeto estão configuradas:
+
+```bash
+cat $IDE/ENV.md
+```
+
+---
+
+## Quando Usar
+
+Use este skill quando:
+- Planejar estratégia de testes (risco, níveis, pirâmide, critérios de aceitação)
+- Identificar lacunas de cobertura no código novo ou modificado
+- Projetar casos de teste (equivalência, limites, tabela de decisão, estados)
+- Decidir o que automatizar e o que manter manual/exploratório
+- Avaliar testes não funcionais (performance, confiabilidade, segurança, acessibilidade)
+- Estruturar gestão de testes e de defeitos (rastreabilidade, métricas, ciclo do defeito)
+- Definir arquitetura de qualidade (testabilidade, quality gates, shift-left/shift-right)
+
+**NÃO usar quando:**
+- A tarefa é só escrever um teste específico numa ferramenta já decidida (ver a especialização registrada, ex: `eng-qa-planner`)
+- Não há nenhuma decisão de qualidade ou cobertura envolvida
+
+---
+
+## Validação de Entrada
+
+Se `$ARGUMENTS` está vazio, o skill funciona em modo interativo: pergunte à pessoa o contexto da tarefa de qualidade/teste antes de prosseguir.
+
+---
+
+## Padrões Críticos
+
+### Padrão 1: Analisar o risco antes de decidir o esforço
+
+```
+1. O que quebra mais caro se falhar? (dados, dinheiro, segurança, reputação)
+2. Qual a probabilidade real de falha nesse ponto?
+3. Não se testa tudo igual: risco alto pega mais profundidade, risco baixo pega menos
+```
+
+### Padrão 2: Ler o projeto antes de planejar
+
+Antes de propor qualquer plano, descubra como o projeto já testa:
+
+```
+1. Qual framework de teste e qual ferramenta de automação já existem?
+2. Como a suíte está organizada (unitário, integração, e2e)?
+3. O que já está cobrindo e o que está faltando?
+4. Existe CI rodando os testes? Em qual gate?
+```
+
+Siga o padrão existente do projeto, **não** o padrão genérico deste skill. Se não conseguir identificar o framework, pergunte antes de prosseguir.
+
+### Padrão 3: Teste instável é pior que sem teste
+
+- Teste flaky corrói a confiança do time e é ignorado — tratar como defeito, não como ruído
+- Priorizar feedback rápido a suíte grande e lenta
+- Isolar dependências externas antes de automatizar (doubles, intercepts)
+
+### Padrão 4: Testabilidade é requisito de design
+
+- Se o código é difícil de testar, o problema é o design, não a falta de ferramenta
+- Levantar isso com quem implementa antes de forçar um teste em volta de um design ruim
+
+### Padrão 5: Teste é informação para decidir, não prova de ausência de defeito
+
+- Reportar cobertura e risco residual, nunca "está 100% garantido"
+- Qualidade é responsabilidade do time inteiro; QA guia, mede e comunica
+
+---
+
+## Base ou especialização?
+
+Pergunta-chave para decidir onde um conhecimento mora:
+
+> **Esse conhecimento continua válido quando eu mudo de framework de teste, de ferramenta de automação ou de linguagem?**
+> **Sim** → pertence à base universal (este skill). **Não** → pertence a uma especialização de ferramenta.
+
+---
+
+## Árvore de Decisão
+
+```
+Planejar estratégia ou critérios de teste?        → tema 2 (estratégia e planejamento)
+Projetar casos de teste?                          → tema 3 (design de casos)
+Decidir entre manual e automatizado?              → tema 4 (manual/exploratório) e tema 5 (automação)
+Testar API, integração ou contrato?               → tema 6 (API/integração) e tema 7 (contrato)
+Testar interface, compatibilidade ou mobile?      → tema 8
+Avaliar performance?                              → tema 9
+Avaliar confiabilidade/resiliência?               → tema 10
+Avaliar segurança?                                → tema 11
+Avaliar acessibilidade?                           → tema 12
+Testar dados ou pipelines?                        → tema 13
+Gerir testes, defeitos ou métricas?               → tema 14
+Definir arquitetura de qualidade/quality gate?    → tema 15
+```
+
+---
+
+## Fluxo de Trabalho
+
+1. **Entender**: ler a suíte e o risco existente (Padrão 1 e 2); esclarecer o que **não** está no escopo
+2. **Planejar**: escolher a abordagem na base universal; decidir nível, critério e profundidade pelo risco
+3. **Projetar**: estruturar os casos/cenários antes de escrever qualquer teste
+4. **Delegar ou executar**: se a ferramenta já está decidida, seguir a especialização registrada; senão, aplicar a base
+5. **Validar**: percorrer o checklist de conclusão abaixo
+
+### Skills invocados durante a execução do skill
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — skill autocontida | — |
+
+---
+
+## Base Universal
+
+Carregue **só o tema necessário** para a tarefa, em vez de todos de uma vez.
+
+| # | Tema | Nível | Carregue quando |
+|---|------|-------|-----------------|
+| 1 | [Fundamentos de qualidade e teste](references/1-fundamentos-qualidade.md) | Fundamental | Precisar distinguir qualidade, garantia, controle e teste |
+| 2 | [Estratégia e planejamento de testes](references/2-estrategia-planejamento.md) | Fundamental | Definir risco, níveis, pirâmide, critérios e ambientes |
+| 3 | [Design de casos de teste](references/3-design-testes.md) | Fundamental | Aplicar equivalência, limites, tabela de decisão ou oráculos |
+| 4 | [Testes manuais e exploratórios](references/4-manual-exploratorio.md) | Fundamental | Definir charter, heurísticas ou sessão exploratória |
+| 5 | [Automação de testes](references/5-automacao-testes.md) | Fundamental | Decidir estratégia de automação, doubles ou manutenção de suíte |
+| 6 | [Testes de API e integração](references/6-api-integracao.md) | Fundamental | Testar contratos HTTP ou borda entre serviços |
+| 7 | [Testes de contrato](references/7-contrato.md) | Importante | Validar consumer-driven ou verificação pelo provedor |
+| 8 | [Testes de interface, compatibilidade e mobile](references/8-interface-compat-mobile.md) | Importante | Cobrir UI, regressão visual ou matriz de compatibilidade |
+| 9 | [Testes de performance](references/9-performance.md) | Importante | Avaliar carga, estresse, percentis ou gargalos |
+| 10 | [Testes de confiabilidade e resiliência](references/10-confiabilidade.md) | Importante | Avaliar falhas, caos ou degradação graciosa |
+| 11 | [Testes de segurança](references/11-seguranca.md) | Importante | Avaliar ameaças, controle de acesso ou fuzzing |
+| 12 | [Testes de acessibilidade](references/12-acessibilidade.md) | Importante | Avaliar WCAG, teclado ou leitores de tela |
+| 13 | [Testes de dados](references/13-dados-testes.md) | Importante | Validar reconciliação, pipelines ou migração de dados |
+| 14 | [Gestão de testes e de defeitos](references/14-gestao-testes-defeitos.md) | Fundamental | Estruturar rastreabilidade, métricas ou ciclo do defeito |
+| 15 | [Arquitetura de QA e qualidade contínua](references/15-arquitetura-qa.md) | Importante | Definir testabilidade, quality gates ou shift-right |
+
+---
+
+## Funções e Peso por Área
+
+QA reúne várias funções (Test Automation, Manual Testing, Performance, Security Testing, Quality Engineering etc.) que partem da mesma base, mas pesam os 15 temas de forma diferente. Ver [references/especializacoes.md](references/especializacoes.md) para o núcleo (●) e o apoio (○) esperado de cada função.
+
+---
+
+## Regras
+
+### Nunca
+- Testar tudo com o mesmo nível de profundidade, ignorando o risco
+- Reportar cobertura como garantia de ausência de defeito
+- Deixar teste flaky "passar direto" sem investigar — tratar como defeito
+- Automatizar antes de ter o caso de teste desenhado
+- Depender de dados de produção real em teste sem anonimização
+
+### Sempre
+- Priorizar teste do que é crítico (dados sensíveis, autenticação, dinheiro) primeiro
+- Ler a suíte e as convenções existentes antes de propor um plano novo
+- Separar claramente plano/estratégia (este skill) de implementação de ferramenta (especialização)
+- Registrar rastreabilidade entre requisito, caso de teste e defeito
+- Medir e comunicar risco residual, não só "está testado"
+
+---
+
+## Tratamento de Erros
+
+### Framework ou ferramenta de teste não identificada
+- Procurar manifesto de dependências, configs de CI e pastas de teste existentes
+- Se não encontrar, perguntar à pessoa antes de prosseguir
+
+### Suíte existente com padrão diferente
+- Seguir o padrão do projeto, não o genérico deste skill
+- Registrar a divergência quando relevante
+
+### Teste falha depois de uma mudança
+- Verificar se o teste já falhava antes (flaky vs. regressão real)
+- Isolar a causa antes de ajustar o teste ou o código
+
+---
+
+## Checklist de Conclusão
+
+- [ ] Risco mapeado e priorizado antes do plano
+- [ ] Casos de teste cobrindo caminho feliz, erro e limites
+- [ ] Rastreabilidade entre requisito, caso e defeito registrada
+- [ ] Decisão de automatizar vs. manter manual justificada
+- [ ] Testes não funcionais considerados quando relevantes (performance, segurança, a11y)
+- [ ] Gaps de cobertura documentados, não só os testes criados
+
+---
+
+## Output
+
+| Artefato | Descrição |
+|----------|-----------|
+| Plano de testes | Estratégia, risco, níveis e critérios de aceitação |
+| Casos de teste | Cenários de sucesso, erro e limite, prontos para implementar |
+| Relatório de gaps | Lacunas de cobertura identificadas no código atual |
+| Recomendação de automação | O que automatizar, com qual ferramenta/especialização |
+
+---
+
+## Mensagem de Conclusão
+
+```
+Planejamento de QA concluído!
+
+Escopo: {descrição do que foi analisado/planejado}
+Framework/ferramenta do projeto: {identificados no código}
+
+Risco priorizado: {áreas críticas identificadas}
+Gaps de cobertura: {encontrados / nenhum}
+Especialização recomendada: {ex: eng-qa-planner / nenhuma}
+
+Próximo passo: {implementar os testes / rodar a especialização registrada}
+```
+
+---
+
+## Aviso: uso só da skill base
+
+Quando o trabalho usar **só a skill base** e envolver um framework ou ferramenta de teste para a qual **não há skill especializado** disponível, avise a pessoa de forma explícita:
+
+```
+ℹ️ Estou usando só a skill base de QA.
+   Não há skill especializado para {framework/ferramenta}; vou seguir os princípios universais
+   e o padrão que encontrei no projeto.
+```
+
+Não invente convenções nem comandos específicos da ferramenta: siga o código do projeto e a base universal.
+
+---
+
+## Recursos Adicionais
+
+- **Base universal**: os 15 temas em [references/](references/)
+- **Funções × skills**: [references/especializacoes.md](references/especializacoes.md)

package/skills/eng-qa/references/1-fundamentos-qualidade.md

@@ -0,0 +1,25 @@
+# 1. Fundamentos de Qualidade e Teste
+
+**Nível:** FUNDAMENTAL · **Agnóstico de tecnologia:** ✅
+
+**Objetivo:** Distinguir qualidade, garantia, controle e teste, e saber por que e para quem testamos.
+
+**Conhecimentos:** erro, defeito e falha; verificação vs. validação; garantia da qualidade (prevenção, processo) vs. controle da qualidade (detecção, produto) vs. teste; sete princípios do teste; características de qualidade (funcionalidade, desempenho, usabilidade, confiabilidade, segurança, manutenibilidade, compatibilidade, portabilidade); custo da qualidade e do defeito tardio; shift-left e shift-right; qualidade como responsabilidade do time; teste como informação para decisão.
+
+**Princípios:**
+- Teste mostra a presença de defeitos, não a ausência.
+- Prevenir custa menos que detectar; detectar custa menos que corrigir em produção.
+- Qualidade é definida pelas partes interessadas, não só pela especificação.
+
+**Fora do escopo:** sintaxe de ferramentas e exigências de certificações específicas.
+
+**Pergunta-chave:** O que significa 'pronto com qualidade' para este item e quem decide?
+
+**Referências:**
+- ISTQB, *Certified Tester Foundation Level Syllabus* v4.0 (2023)
+- ISO/IEC 25010, modelo de qualidade de produto
+- IEEE, *SWEBOK* v4 (Software Testing; Software Quality)
+- Myers, *The Art of Software Testing*
+- Juran, *Juran's Quality Handbook*
+
+**Usam mais:** todas as funções de QA