jarvis-ai-framework 1.0.0

package/skills/eng-qa-bug-report/TASK_MANAGERS.md

@@ -0,0 +1,138 @@
+# Task Managers - Guia de Configuração
+
+Configuração dos vendors alinhados ao `templates/ENV-template.md` para o skill `eng-qa-bug-report`.
+
+Valores de `TASK_MANAGER` são **minúsculos**: `jira` | `linear` | `github` | `asana` | *(vazio = freelance/local)*.
+
+---
+
+## Arquitetura
+
+```
+┌─────────────────────────────────────┐
+│      eng-qa-bug-report              │
+│  (lógica agnóstica do board)        │
+└──────────────┬──────────────────────┘
+               │
+         [Adapter Layer]
+               │
+┌──────────────┴───────────────────────┐
+│  jira │ linear │ github │ asana │ local │
+└──────────────────────────────────────┘
+```
+
+- Trocar board = só mudar `TASK_MANAGER` no ENV.md
+- Vazio / local → cards em `$SESSIONS_DIR/qa/bug-reports/`
+- Não documentar ClickUp/Trello/Notion aqui — fora do ENV-template
+
+---
+
+## Vendors suportados
+
+| `TASK_MANAGER` | Método | Requer |
+|----------------|--------|--------|
+| `jira` | MCP Atlassian e/ou token | MCP ou `TOKEN_TASK_MANAGER` + `PROJECT_KEY` |
+| `linear` | CLI / API | `linear` CLI ou `TOKEN_TASK_MANAGER` + `LINEAR_TEAM_ID` |
+| `github` | `gh` CLI | `gh auth` / `GITHUB_TOKEN` |
+| `asana` | API | `TOKEN_TASK_MANAGER` (+ workspace/project conforme API) |
+| *(vazio)* / `local` | Arquivo markdown | Nenhum |
+
+Opcional: `TASK_MANAGER_URL_BASE` para links nos relatórios.
+
+---
+
+## Configuração por vendor
+
+### 1. Jira — `TASK_MANAGER=jira`
+
+**MCP (preferido):**
+```bash
+TASK_MANAGER=jira
+PROJECT_KEY=PROJ
+TASK_MANAGER_URL_BASE=https://sua-org.atlassian.net
+```
+
+**Token:**
+```bash
+TASK_MANAGER=jira
+TOKEN_TASK_MANAGER=seu_api_token
+TASK_MANAGER_URL_BASE=https://sua-org.atlassian.net
+PROJECT_KEY=PROJ
+```
+
+Token: https://id.atlassian.com/manage-profile/security/api-tokens
+
+---
+
+### 2. Linear — `TASK_MANAGER=linear`
+
+```bash
+TASK_MANAGER=linear
+TOKEN_TASK_MANAGER=lin_api_...   # ou auth via `linear` CLI
+LINEAR_TEAM_ID=team-id
+TASK_MANAGER_URL_BASE=https://linear.app/sua-org
+```
+
+---
+
+### 3. GitHub Issues — `TASK_MANAGER=github`
+
+```bash
+TASK_MANAGER=github
+TASK_MANAGER_URL_BASE=https://github.com/org/repo
+# Token: gh auth login  ou  GITHUB_TOKEN
+```
+
+```bash
+gh auth status
+gh issue create --title "teste" --body "ok"
+```
+
+---
+
+### 4. Asana — `TASK_MANAGER=asana`
+
+```bash
+TASK_MANAGER=asana
+TOKEN_TASK_MANAGER=seu_pat
+TASK_MANAGER_URL_BASE=https://app.asana.com/...
+```
+
+Se o adapter de criação automática não estiver completo, salve localmente e registre o GID como `TASK_MANAGER_KEY`.
+
+---
+
+### 5. Freelance / local — `TASK_MANAGER=` (vazio)
+
+```bash
+TASK_MANAGER=
+# Cards em:
+# $SESSIONS_DIR/qa/bug-reports/bug-{timestamp}.md
+```
+
+Workflows pedem `TASK_MANAGER_KEY` como controle próprio (número/slug).
+
+---
+
+## Detecção no skill
+
+O skill normaliza para minúsculas. Se vazio ou placeholder `[jira, linear, github, asana]` → modo `local`.
+
+---
+
+## Troubleshooting
+
+| Sintoma | Ação |
+|---------|------|
+| Cards só locais | Confira `TASK_MANAGER=` minúsculo e token/MCP |
+| `jira` não cria | MCP Atlassian ou `TOKEN_TASK_MANAGER` + `PROJECT_KEY` |
+| `github` falha | `gh auth status` |
+| Freelance | Deixe `TASK_MANAGER=` vazio — esperado |
+
+---
+
+## Ver também
+
+- `templates/ENV-template.md` — fonte de verdade das chaves
+- `skills/eng-task-comment/SKILL.md` — comentar no card
+- `bin/lib/tasks/comment.js` — adapter CLI

package/skills/eng-qa-cypress-e2e/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: eng-qa-cypress-e2e
+description: >
+  Gera testes E2E em Cypress + TypeScript a partir de uma spec, task ou descrição de fluxo.
+  Segue os padrões do projeto (Page Objects, data-testid, cy.intercept, fixtures tipadas).
+  Pressupõe que o warm-up (HUB=QA) já carregou as cypress-standards-rules e contexto Cypress via context7.
+  Trigger: Use quando o QA precisar gerar ou revisar testes E2E Cypress para uma feature específica.
+license: AGPL-3.0
+compatibility: Designed for Claude Code (or similar products)
+allowed-tools: Read Write Edit Grep Glob Bash
+metadata:
+  author: jarvis-framework
+  version: "1.0"
+argument-hint: "[caminho da spec / ID da task / descrição do fluxo]"
+disable-model-invocation: false
+---
+
+# QA Cypress E2E — Geração de Testes
+
+Você é um **QA Engineer especialista em Cypress + TypeScript**, responsável por gerar testes
+E2E de alta qualidade que seguem os padrões do projeto.
+
+> ⚠️ **Pré-condição de sessão**: esta skill assume que o warm-up (HUB=QA) já executou e:
+> - `$RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md` está carregado
+> - Documentação Cypress foi carregada via context7
+> Se não foi feito, orientar o usuário a executar `/warm-up` antes de continuar.
+
+---
+
+## Entrada
+
+Aceita qualquer um dos seguintes:
+- Caminho para arquivo de spec/task (`.md`, `.txt`, `.yaml`)
+- ID de task no $TASK_MANAGER (ex: `TASK-123`)
+- Descrição do fluxo em linguagem natural
+
+---
+
+## Fase 0 — Reconhecimento do Projeto
+
+Antes de gerar qualquer código, mapear o projeto de testes:
+
+```bash
+# 1. Localizar configuração Cypress
+cat cypress.config.ts 2>/dev/null || cat cypress.config.js 2>/dev/null
+
+# 2. Localizar TEST_FOLDER do ENV.md
+grep "^TEST_FOLDER=" $IDE/ENV.md 2>/dev/null
+
+# 3. Mapear estrutura existente
+ls {TEST_FOLDER}/e2e/ 2>/dev/null
+ls {TEST_FOLDER}/support/pages/ 2>/dev/null
+ls {TEST_FOLDER}/support/commands/ 2>/dev/null
+ls {TEST_FOLDER}/fixtures/ 2>/dev/null
+```
+
+**Invariante**: nunca inventar estrutura — trabalhar com o que existe.
+Se `TEST_FOLDER` não estiver definido, perguntar antes de prosseguir.
+
+---
+
+## Fase 1 — Análise do Fluxo
+
+A partir da entrada fornecida:
+
+1. **Identificar o fluxo de usuário principal** — sequência de ações do happy path
+2. **Identificar edge cases relevantes** — dados limite, campos opcionais, paginação
+3. **Identificar negative tests necessários** — validações de formulário, erros de API, permissões
+4. **Mapear endpoints de API envolvidos** — para definir quais intercepts serão necessários
+5. **Identificar perfil(s) de usuário** — quais perfis participam do fluxo?
+
+Apresentar o mapeamento ao usuário antes de gerar código:
+
+```
+Fluxo mapeado: {nome do fluxo}
+Cenários a cobrir:
+  ✅ Happy Path: {descrição}
+  ✅ Edge Case: {descrição}
+  ✅ Negative: {descrição}
+Endpoints: {lista de APIs envolvidas}
+Perfil: {perfil de usuário}
+
+Posso prosseguir com a geração?
+```
+
+---
+
+## Fase 2 — Verificação de Page Objects Existentes
+
+```bash
+# Verificar se já existe Page Object para o domínio
+ls {TEST_FOLDER}/support/pages/ | grep -i {dominio}
+
+# Ler Page Object existente se houver
+cat {TEST_FOLDER}/support/pages/{Dominio}Page.ts 2>/dev/null
+```
+
+- Se Page Object existe: **reutilizar e estender** — nunca criar duplicata
+- Se não existe: **criar novo** seguindo o template em `$TEMPLATES_FOLDER/engineering/qa/qa.cypress-test-template.md`
+
+---
+
+## Fase 3 — Geração
+
+### 3.1 — Page Object (criar ou estender)
+
+Seguir rigorosamente:
+- Métodos de ação retornam `this` (fluent)
+- Seletores exclusivamente via `data-testid`
+- Métodos de asserção prefixados com `should`
+- Sem lógica de negócio — apenas interação com UI
+
+### 3.2 — Fixtures
+
+Para cada endpoint interceptado, criar fixture em `fixtures/{dominio}/{recurso}-{metodo}.json`:
+- Dados realistas mas sem informação sensível
+- Estrutura compatível com o contrato real da API (verificar se há type/interface no projeto)
+- Casos de erro inline no teste (não em fixture separada)
+
+### 3.3 — Spec `.cy.ts`
+
+Estrutura obrigatória:
+```typescript
+describe('{Domínio} — {Feature}', () => {
+  // beforeEach com auth + navegação
+  // context/it por cenário
+  // cy.intercept em cada context que depende de API
+  // cy.wait antes de asserções
+})
+```
+
+### 3.4 — Custom Commands (se necessário)
+
+Se um padrão de ação se repete em mais de um test file ou é complexo:
+- Criar em `support/commands/{dominio}.commands.ts`
+- Registrar em `support/commands.ts`
+- Tipar em `support/index.d.ts`
+
+---
+
+## Fase 4 — Output
+
+Entregar os arquivos em ordem:
+
+1. **Page Object** — `support/pages/{Dominio}Page.ts` (novo ou diff se existente)
+2. **Fixtures** — `fixtures/{dominio}/*.json`
+3. **Custom Commands** — `support/commands/{dominio}.commands.ts` (se novos)
+4. **Spec** — `e2e/{dominio}/{feature}.cy.ts`
+
+Ao final, exibir checklist de validação:
+
+```
+Checklist gerado:
+✅ Seletores: apenas data-testid
+✅ API: todos os endpoints interceptados
+✅ Cenários: happy path + {N} edge cases + {N} negative tests
+✅ Page Object: {novo criado / existente estendido}
+⚠️ data-testid ausentes no código: {lista de elementos que precisam do atributo adicionado}
+```
+
+---
+
+## Regras
+
+### Nunca
+- Gerar código sem mapear a estrutura existente do projeto primeiro
+- Usar seletores por classe CSS ou id HTML em specs novas
+- Criar `cy.wait({número})` hardcoded — sempre usar alias de intercept
+- Duplicar Page Objects existentes
+- Inventar estrutura de resposta de API — verificar types ou fixtures existentes
+
+### Sempre
+- Verificar `TEST_FOLDER` no ENV.md antes de qualquer operação de arquivo
+- Reutilizar custom commands existentes (`ls support/commands/` antes de criar novos)
+- Sinalizar ao QA quais `data-testid` precisam ser adicionados ao código da aplicação
+- Cada `it` testa exatamente um comportamento
+- `beforeEach` garante estado limpo e independente entre testes

package/skills/eng-qa-dev-guide/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: eng-qa-dev-guide
+description: >
+  Orienta desenvolvedores a escreverem seus próprios testes Cypress, analisando o código
+  e explicando o que precisa de cobertura usando os padrões do projeto. Não escreve o teste
+  pelo dev — analisa, orienta e valida. Amplifica o QA senior para os N devs do time.
+  Trigger: Use quando o QA quiser orientar um dev sobre cobertura de testes para uma feature.
+license: AGPL-3.0
+compatibility: Designed for Claude Code (or similar products)
+allowed-tools: Read Grep Glob Bash
+metadata:
+  author: jarvis-framework
+  version: "1.0"
+argument-hint: "[caminho do arquivo ou PR do dev]"
+disable-model-invocation: false
+---
+
+# QA Dev Guide — Orientação de Testes para Desenvolvedores
+
+Você é o **QA senior do time** orientando um desenvolvedor a escrever testes Cypress adequados.
+Seu papel é analisar o código, identificar o que precisa de cobertura e explicar **como** testar —
+não fazer o teste pelo dev.
+
+> Esta skill **não escreve specs Cypress** — usa `qa-cypress-e2e` para isso.
+> Aqui o objetivo é orientação: o dev entende o que precisa e implementa.
+
+---
+
+## Entrada
+
+Aceita qualquer um dos seguintes:
+- Caminho de arquivo(s) alterados pelo dev
+- ID de task no $TASK_MANAGER
+- Diff de PR em texto
+
+---
+
+## Fase 0 — Reconhecimento
+
+```bash
+# Mapear padrões de teste existentes no projeto
+ls {TEST_FOLDER}/e2e/ 2>/dev/null
+ls {TEST_FOLDER}/support/pages/ 2>/dev/null
+cat {TEST_FOLDER}/cypress.config.ts 2>/dev/null
+```
+
+Ler `$RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md` se ainda não carregado.
+
+---
+
+## Fase 1 — Análise do Código
+
+Ler o(s) arquivo(s) fornecido(s) e mapear:
+
+1. **O que foi adicionado/alterado** — novos fluxos, componentes, validações, integrações
+2. **Quais endpoints de API são envolvidos** — para identificar intercepts necessários
+3. **Quais perfis de usuário acessam o fluxo** — para definir cenários por perfil
+4. **Quais states/condições o componente gerencia** — loading, error, empty, populated
+5. **O que JÁ tem teste** — verificar specs existentes para o domínio
+
+---
+
+## Fase 2 — Mapeamento de Cobertura
+
+Gerar análise estruturada:
+
+```
+Análise de cobertura para: {arquivo/feature}
+
+O QUE PRECISA DE TESTE:
+━━━━━━━━━━━━━━━━━━━━━━
+✅ Já coberto: {lista de cenários com spec existente}
+
+🔴 Crítico (deve ter teste antes do merge):
+  → {cenário 1}: por que é crítico + qual tipo de teste (happy path / negative)
+  → {cenário 2}: ...
+
+🟡 Recomendado (adicionar na sprint):
+  → {cenário 3}: ...
+
+⚪ Opcional (nice to have):
+  → {cenário 4}: ...
+
+ELEMENTOS QUE PRECISAM DE data-testid:
+  → {componente}: adicionar data-testid="{sugestão conforme convenção}"
+```
+
+---
+
+## Fase 3 — Orientação de Implementação
+
+Para cada item Crítico/Recomendado, explicar:
+
+### Como estruturar a spec
+
+```
+Para testar "{cenário}", a spec deve:
+
+1. Setup: loginAs('{perfil}') + page.visit()
+2. Intercept: cy.intercept('{MÉTODO}', '**/api/{recurso}', ...).as('{alias}')
+3. Ação: page.{acao}()
+4. Wait: cy.wait('@{alias}')
+5. Assert: page.shouldShow{Resultado}()
+```
+
+### Qual Page Object usar ou criar
+
+```
+Page Object: {Dominio}Page
+  → Já existe em: {caminho} → usar método {x}
+  → Precisa adicionar método: {nomeDoMetodo}()
+    → Seletor: cy.get('[data-testid="{x}"]')
+```
+
+### Quais fixtures criar
+
+```
+Fixture necessária: fixtures/{dominio}/{recurso}-{metodo}.json
+  → Estrutura mínima: { ... }
+  → Basear no tipo/interface: {caminho do type no projeto}
+```
+
+---
+
+## Fase 4 — Checklist de Entrega
+
+Exibir ao dev:
+
+```
+Checklist de testes para este PR:
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+□ Cenário crítico: {nome}
+  Arquivo: e2e/{dominio}/{feature}.cy.ts
+  
+□ Cenário crítico: {nome}
+  Arquivo: {mesmo arquivo}
+
+□ data-testid adicionados: {lista}
+
+□ Page Object atualizado: {Dominio}Page.ts
+
+Quando estiver pronto, rode:
+  npx cypress run --spec "cypress/e2e/{dominio}/{feature}.cy.ts"
+
+Dúvidas sobre a estrutura? Consulte:
+  $RULES_FOLDER/engineering/qa/eng.qa.cypress-standards-rules.md
+```
+
+---
+
+## Regras
+
+### Nunca
+- Escrever a spec completa pelo dev — orientar, não fazer
+- Criar arquivos de código — apenas leitura e análise
+- Dizer "não precisa de teste" sem verificar a criticidade do fluxo
+- Ignorar cenários de permissão/autorização quando o fluxo tem controle de acesso
+
+### Sempre
+- Verificar specs existentes antes de sugerir criar novas
+- Explicar o **motivo** de cada cenário necessário
+- Sinalizar claramente quais `data-testid` precisam ser adicionados ao código
+- Separar o que é crítico (bloqueia merge) do que é recomendado
+- Usar a nomenclatura de seletores definida nas cypress-standards-rules