@gabrihhh/jarvis 2.6.2 → 2.7.0

package/README.md

@@ -41,7 +41,7 @@ Reinicie o Claude Code após o setup.
 | `jarvis --line` | Saída de uma linha usada internamente pela status bar |
 | `jarvis --help` | Lista todos os comandos |
 
-**Slash commands** *(dentro do Claude Code)*:
+**Slash commands** *(dentro do Claude Code — instalados por `jarvis --setup`)*:
 
 | Comando | Descrição |
 |---|---|
@@ -49,6 +49,8 @@ Reinicie o Claude Code após o setup.
 | `/create-memory` | Indexa um repositório no grafo de memória (primeira vez) |
 | `/update-memory` | Atualiza o grafo com as mudanças recentes do repositório |
 | `/configure-memory` | Personaliza o schema, regras e fluxos da arquitetura de memória |
+| `/reset-folder` | Reseta todos os repos filhos para um branch (`qa`/`main`), tratando alterações interativamente |
+| `/folder-submit` | Cria branches, commita e faz push das alterações de todos os repos filhos |
 
 ---
 

package/bin/jarvis.js

@@ -2,7 +2,7 @@
 import { run } from '../src/index.js';
 import { renderLine } from '../src/statusline.js';
 import { readTheme, writeTheme, isValidHex, DEFAULT_COLORS, VALID_NAMES, THEME_PATH } from '../src/theme.js';
-import { readFileSync, writeFileSync, existsSync, mkdirSync, copyFileSync } from 'fs';
+import { readFileSync, writeFileSync, existsSync, mkdirSync, copyFileSync, readdirSync } from 'fs';
 import { join, dirname } from 'path';
 import { homedir } from 'os';
 import { exec, execSync } from 'child_process';
@@ -87,11 +87,12 @@ if (args.includes('--help') || args.includes('-h')) {
     jarvis --token off           Disable token display
     jarvis --help                Show this help
 
-  Slash commands (inside Claude Code):
+  Slash commands (inside Claude Code — installed by --setup):
     /setup-memory                Setup Docker + Neo4j + register MCP server
     /create-memory               Index a repository into the memory graph (first time)
     /update-memory               Update an existing memory graph with recent changes
     /configure-memory            Customize the memory graph architecture (schema, rules, flows)
+    /gerar-estimativa            Gera documento de estimativa técnica a partir de um monorepo
 
   Data source: ~/.claude/projects/
 `);
@@ -126,18 +127,19 @@ if (args.includes('--graph')) {
   writeFileSync(settingsPath, JSON.stringify(settings, null, 2));
   console.log('  ✓ Status bar configured');
 
-  // Slash commands → ~/.claude/skills/<name>/SKILL.md
-  const skillsDir = join(homedir(), '.claude', 'skills');
-  const srcSkills = join(__dir, '../.claude/skills');
-  for (const skill of ['setup-memory', 'create-memory', 'update-memory', 'configure-memory']) {
-    const destDir = join(skillsDir, skill);
-    mkdirSync(destDir, { recursive: true });
-    copyFileSync(join(srcSkills, skill, 'SKILL.md'), join(destDir, 'SKILL.md'));
-    console.log(`  ✓ Slash command /${skill} installed`);
+  // Slash commands → ~/.claude/commands/<name>.md
+  const commandsDir = join(homedir(), '.claude', 'commands');
+  const srcSlash = join(__dir, '../slash');
+  mkdirSync(commandsDir, { recursive: true });
+  const slashFiles = readdirSync(srcSlash).filter(f => f.endsWith('.md') && f !== 'MEMORY_ARCHITECTURE.md');
+  for (const file of slashFiles) {
+    copyFileSync(join(srcSlash, file), join(commandsDir, file));
+    const name = file.replace('.md', '');
+    console.log(`  ✓ Slash command /${name} installed`);
   }
 
-  // Arquitetura de memória (referenciada pelas skills)
-  copyFileSync(join(srcSkills, 'MEMORY_ARCHITECTURE.md'), join(skillsDir, 'MEMORY_ARCHITECTURE.md'));
+  // Arquivo de suporte (referenciado pelos comandos)
+  copyFileSync(join(srcSlash, 'MEMORY_ARCHITECTURE.md'), join(commandsDir, 'MEMORY_ARCHITECTURE.md'));
   console.log('  ✓ MEMORY_ARCHITECTURE.md installed');
 
   // Trigger padrão: session

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gabrihhh/jarvis",
-  "version": "2.6.2",
+  "version": "2.7.0",
   "description": "Claude Code terminal dashboard + semantic memory graph via Neo4j",
   "bin": {
     "jarvis": "bin/jarvis.js",
@@ -13,7 +13,7 @@
   "files": [
     "bin/",
     "src/",
-    ".claude/skills/"
+    "slash/"
   ],
   "keywords": [
     "claude",

package/{.claude/skills/configure-memory/SKILL.md → slash/configure-memory.md}

@@ -6,7 +6,7 @@ description: Configurar a arquitetura do grafo de memória semântica — person
 # /configure-memory — Configurar Arquitetura de Memória
 
 Você vai guiar o usuário para criar ou modificar a arquitetura do grafo de memória semântica.
-O resultado será salvo em `~/.claude/skills/MEMORY_ARCHITECTURE.md`, substituindo o padrão e sendo usado pelo `/create-memory` e `/update-memory`.
+O resultado será salvo em `~/.claude/commands/MEMORY_ARCHITECTURE.md`, substituindo o padrão e sendo usado pelo `/create-memory` e `/update-memory`.
 
 ## REGRA GLOBAL
 
@@ -18,7 +18,7 @@ O resultado será salvo em `~/.claude/skills/MEMORY_ARCHITECTURE.md`, substituin
 
 ## Passo 0 — Ler arquitetura atual
 
-Leia o arquivo `~/.claude/skills/MEMORY_ARCHITECTURE.md`.
+Leia o arquivo `~/.claude/commands/MEMORY_ARCHITECTURE.md`.
 
 Se não existir, informe: "Nenhuma arquitetura customizada encontrada. Usarei a arquitetura padrão como base."
 Nesse caso, use o conteúdo padrão definido internamente (schema básico com Project, Module, File, Concept, Pattern, Dependency).
@@ -161,7 +161,7 @@ Com base na conversa, gere o arquivo completo `MEMORY_ARCHITECTURE.md` seguindo
 
 Mostre o arquivo **completo** gerado ao usuário.
 
-Diga: **"Esta é a arquitetura que vou salvar em `~/.claude/skills/MEMORY_ARCHITECTURE.md`. Revise, corrija o que quiser, e me diga 'pode salvar' quando estiver pronto."**
+Diga: **"Esta é a arquitetura que vou salvar em `~/.claude/commands/MEMORY_ARCHITECTURE.md`. Revise, corrija o que quiser, e me diga 'pode salvar' quando estiver pronto."**
 
 Se o usuário pedir ajustes:
 - Aplique, mostre o trecho alterado
@@ -175,7 +175,7 @@ Se o usuário pedir ajustes:
 Após aprovação explícita, salve o conteúdo gerado em:
 
 ```
-~/.claude/skills/MEMORY_ARCHITECTURE.md
+~/.claude/commands/MEMORY_ARCHITECTURE.md
 ```
 
 Informe ao usuário:

package/{.claude/skills/create-memory/SKILL.md → slash/create-memory.md}

@@ -7,7 +7,7 @@ description: Indexar repositório atual no grafo de memória semântica (Neo4j)
 
 Você vai analisar o repositório atual de forma exaustiva e indexar seu entendimento no Neo4j.
 
-**Antes de iniciar:** leia `.claude/skills/MEMORY_ARCHITECTURE.md` — ele define o schema do grafo, as regras de indexação e os critérios de qualidade que você deve seguir durante toda a execução desta skill.
+**Antes de iniciar:** leia `~/.claude/commands/MEMORY_ARCHITECTURE.md` — ele define o schema do grafo, as regras de indexação e os critérios de qualidade que você deve seguir durante toda a execução desta skill.
 
 ## PRÉ-REQUISITO — Verificar ambiente
 

package/slash/folder-submit.md

@@ -0,0 +1,286 @@
+---
+name: folder-submit
+description: Cria branches, commita e faz push das alterações em todos os repositórios git filhos com mudanças locais pendentes
+---
+
+# /folder-submit — Submeter Alterações dos Repositórios Filhos
+
+## Uso
+
+```
+/folder-submit qa
+/folder-submit main
+```
+
+---
+
+## REGRA GLOBAL
+
+- Nunca executar `git add`, `commit` ou `push` sem aprovação explícita do usuário
+- Nunca subir arquivos de ambiente ou segredos — bloquear e avisar sempre que encontrado
+- Se travar em qualquer ponto — erro inesperado, ambiguidade — **pare e pergunte ao usuário**
+- Tratar cada repositório de forma independente: um erro em um repo não impede os demais
+- Sempre tentar usar o MCP do GitHub quando disponível; se não estiver, usar linha de comando
+
+---
+
+## Passo 1 — Ler argumento
+
+O alvo é o branch passado como argumento: `qa` ou `main`.
+
+Se nenhum argumento for fornecido, informe:
+**"Qual o branch alvo? Use: `/folder-submit qa` ou `/folder-submit main`"**
+Interrompa aqui.
+
+Defina internamente:
+- `BRANCH_ALVO` = argumento recebido (ex: `qa`)
+- `LABEL` = argumento em maiúsculas (ex: `QA`)
+
+---
+
+## Passo 2 — Descobrir repositórios com alterações
+
+Execute na pasta atual:
+
+```bash
+for d in */; do
+  [ -d "${d}.git" ] && echo "${d%/}"
+done
+```
+
+Para cada repositório encontrado, verifique se há alterações pendentes:
+
+```bash
+git -C <repo> status --short
+```
+
+Considere "com alterações" qualquer repo que retorne output não-vazio (arquivos modificados, staged, untracked).
+
+Se nenhum repositório tiver alterações:
+**"Nenhuma alteração encontrada nos repositórios de `$(pwd)`. Nada a submeter."**
+Interrompa aqui.
+
+---
+
+## Passo 3 — Apresentar panorama e pedir confirmação
+
+Liste os repositórios com alterações e o que cada um tem:
+
+```
+Repositórios com alterações pendentes:
+
+  📦 api-service
+     M  src/auth/login.js
+     M  src/auth/middleware.js
+     ?? src/utils/newHelper.js
+
+  📦 frontend
+     M  src/components/LoginForm.tsx
+     D  src/components/OldModal.tsx
+
+Total: 2 repositórios com alterações.
+
+Deseja criar branches e submeter as alterações de todos eles?
+```
+
+Aguarde resposta:
+- **Sim / confirmar / pode ir:** prossiga para o Passo 4
+- **Não / cancelar / parar:** interrompa aqui sem modificar nada
+
+---
+
+## Passo 4 — Verificar arquivos de ambiente (BLOQUEIO DE SEGURANÇA)
+
+Antes de qualquer `git add`, verifique em **cada repositório** se há arquivos sensíveis nas alterações:
+
+```bash
+# Arquivos modificados e não-rastreados
+git -C <repo> diff --name-only
+git -C <repo> ls-files --others --exclude-standard
+```
+
+Considere bloqueados arquivos que correspondam a qualquer um destes padrões:
+
+```
+.env
+.env.*
+*.env
+*.pem
+*.key
+*.p12
+*.pfx
+secrets.*
+*secret*
+*credentials*
+*password*
+*.token
+```
+
+Se encontrar qualquer arquivo bloqueado em algum repositório, **não prossiga** nesse repo. Informe:
+
+```
+⛔ Arquivo sensível detectado em <repo>:
+   • .env.local
+   • config/secrets.json
+
+Esse repositório será ignorado por segurança.
+Corrija o .gitignore ou remova os arquivos antes de tentar novamente.
+```
+
+Continue normalmente com os demais repositórios.
+
+---
+
+## Passo 5 — Coletar informações para cada repositório
+
+Para cada repositório aprovado (sem arquivos sensíveis), **um de cada vez**:
+
+**5.1 — Mostrar resumo das alterações:**
+
+```bash
+git -C <repo> diff --stat
+git -C <repo> status --short
+```
+
+**5.2 — Perguntar tipo e mensagem:**
+
+```
+Repositório: api-service
+
+Alterações:
+  M  src/auth/login.js
+  M  src/auth/middleware.js
+  ?? src/utils/newHelper.js
+
+  [1] fix    — correção de bug, ajuste, hotfix
+  [2] feature — funcionalidade nova, melhoria
+
+Qual o tipo? E qual a mensagem curta da branch? (será usada em camelCase)
+Exemplo: "correcaoValidacaoToken" ou "novaTelaLogin"
+```
+
+Aguarde a resposta do usuário. Valide:
+- Tipo deve ser `fix` ou `feature`
+- Mensagem deve ser curta (sem espaços — se o usuário mandar com espaços, converta para camelCase automaticamente)
+
+Monte o nome da branch:
+```
+<tipo>/<branch-alvo>/<mensagem>
+Exemplo: fix/qa/correcaoValidacaoToken
+```
+
+**5.3 — Gerar mensagem de commit:**
+
+Analise o diff para entender o que foi alterado:
+
+```bash
+git -C <repo> diff
+```
+
+Proponha uma mensagem de commit no padrão:
+
+```
+[<LABEL>] <título breve da alteração>
+
+<descrição do que foi feito e por quê, baseada no diff>
+```
+
+Exemplo:
+```
+[QA] Correção na validação do token de autenticação
+
+Ajustado o middleware de autenticação para rejeitar tokens expirados
+corretamente. O comportamento anterior permitia tokens com expiração
+inválida passarem pela validação em edge cases de timezone.
+```
+
+Mostre a mensagem proposta e pergunte:
+**"Essa mensagem está correta? Pode ajustar o título ou a descrição se quiser."**
+
+Só prossiga após aprovação ou ajuste do usuário.
+
+---
+
+## Passo 6 — Executar: branch, add, commit, push
+
+Para cada repositório, com as informações coletadas:
+
+**6.1 — Criar a branch:**
+
+Tente via MCP do GitHub se disponível:
+```
+create_branch(repo: "<repo>", branch: "<nova-branch>", from: "<branch-alvo>")
+```
+
+Se o MCP não estiver disponível ou retornar erro, use CLI:
+```bash
+git -C <repo> checkout -b <nova-branch>
+```
+
+**6.2 — Adicionar arquivos:**
+
+```bash
+git -C <repo> add .
+```
+
+Confirme o que foi staged:
+```bash
+git -C <repo> status --short
+```
+
+Se arquivos inesperados aparecerem no stage (ex: arquivos que não estavam no resumo), avise o usuário antes de continuar.
+
+**6.3 — Fazer commit:**
+
+```bash
+git -C <repo> commit -m "$(cat <<'EOF'
+[<LABEL>] <título>
+
+<descrição>
+EOF
+)"
+```
+
+Se o commit falhar (hook rejeitou, nada para commitar, etc.), informe o erro e pergunte o que fazer.
+
+**6.4 — Fazer push:**
+
+Tente via MCP do GitHub se disponível:
+```
+push_branch(repo: "<repo>", branch: "<nova-branch>")
+```
+
+Se o MCP não estiver disponível, use CLI:
+```bash
+git -C <repo> push origin <nova-branch>
+```
+
+Se o push falhar, informe o erro e pergunte ao usuário o que fazer.
+
+---
+
+## Passo 7 — Resumo Final
+
+Ao concluir todos os repositórios, apresente o resultado:
+
+```
+Resumo — folder-submit <branch-alvo>
+
+  ✅ api-service
+     Branch:  fix/qa/correcaoValidacaoToken
+     Commit:  [QA] Correção na validação do token de autenticação
+     Push:    origin/fix/qa/correcaoValidacaoToken ✓
+
+  ✅ frontend
+     Branch:  feature/qa/novaTelaLogin
+     Commit:  [QA] Nova tela de login com validação em tempo real
+     Push:    origin/feature/qa/novaTelaLogin ✓
+
+  ⛔ config-service  → ignorado (arquivo .env detectado)
+
+Concluído. 2 branches criadas e publicadas, 1 ignorado por segurança.
+
+Branches criadas:
+  • fix/qa/correcaoValidacaoToken
+  • feature/qa/novaTelaLogin
+```

package/slash/gerar-estimativa.md

@@ -0,0 +1,289 @@
+# Prompt — Gerador de Estimativa Técnica
+
+> **Como usar:**
+> 1. Abra o terminal na pasta pai que contém os repositórios do projeto
+> 2. Execute `claude` para abrir o Claude Code
+> 3. Cole o conteúdo deste arquivo no chat
+> 4. Siga as fases na ordem — o Claude irá conduzir o processo
+
+---
+
+## Regras Absolutas (leia antes de qualquer coisa)
+
+1. **Zero chutes** — toda afirmação sobre código deve ser verificada lendo o arquivo. Cite sempre `caminho/arquivo.ts:linha`. Se não leu, não afirme.
+2. **Perguntas ilimitadas** — qualquer informação que não possa ser confirmada no código deve ser perguntada ao usuário. Não existe limite de perguntas. Agrupe-as por tema e apresente todas de uma vez.
+3. **CLAUDE.md primeiro** — ao entrar em qualquer repositório, leia o `CLAUDE.md` antes de qualquer outro arquivo.
+4. **Siga o fluxo, não o monorepo** — identifique apenas os repos que participam do caminho descrito pelo usuário. Se o front chama a API 1 e existe uma API 2 que não faz parte do fluxo, não leia a API 2.
+5. **Português** — todo o documento gerado deve estar em português.
+6. **Estimativa dupla** — estime usando a escala Fibonacci e preencha a coluna de horas, mas deixe a coluna do PO/Tech Lead sempre em branco para revisão humana.
+7. **Saída no Desktop** — salvar o documento final em `~/Desktop/[nome-da-demanda].md`.
+
+---
+
+## FASE 1 — Contexto Inicial
+
+Antes de qualquer pesquisa no código, solicite ao usuário:
+
+- **Nome da demanda** — será o nome do arquivo gerado (ex: `amazon-fba-nfe.md`)
+- **Número do PPM** — identificador da demanda (ex: `DMND0002177`)
+- **Descrição do que precisa ser feito** — pode ser em linguagem natural, com o máximo de detalhes disponíveis
+- **Ponto de entrada no fluxo** (opcional) — se souber por onde começa (ex: "webhook AnyMarket", "rota POST /pedidos", "evento SQS"), informe
+
+> Não avance para a Fase 2 sem ter ao menos o **nome da demanda** e a **descrição do que precisa ser feito**.
+
+---
+
+## FASE 2 — Mapeamento do Monorepo
+
+Execute nessa ordem:
+
+### 2.1 — Inventariar os repositórios
+
+Liste todas as pastas no diretório atual. Para cada pasta, verifique:
+- Se é um repositório git (presença de `.git/`)
+- Se tem `CLAUDE.md`
+- Se tem `package.json` — registre o valor de `name`
+
+Registre esse inventário internamente. Não apresente ao usuário ainda.
+
+### 2.2 — Identificar repos candidatos
+
+Com base na descrição do usuário, identifique quais repos provavelmente participam do fluxo. Critérios:
+- Nome sugere relação com o que foi descrito
+- `package.json` ou `CLAUDE.md` menciona tecnologias ou domínios relevantes
+
+### 2.3 — Ler CLAUDE.md dos candidatos
+
+Para cada repo candidato, leia o `CLAUDE.md` antes de qualquer outro arquivo. Use o conteúdo para:
+- Confirmar se o repo é realmente relevante para o fluxo
+- Entender a arquitetura e convenções do projeto
+- Identificar os pontos de entrada (automations, controllers, routes)
+
+### 2.4 — Traçar o fluxo e descartar o que não é relevante
+
+A partir do ponto de entrada descrito pelo usuário (ou identificado no CLAUDE.md):
+- Siga o caminho da requisição/evento passo a passo
+- Identifique exatamente quais repos estão no caminho
+- **Pare de explorar repos que não estão no fluxo**
+
+Exemplo de raciocínio correto:
+> "O usuário quer alterar o webhook. O webhook vive no repo `ServiceBUSMigrationJitter`. Ele chama internamente o `AnymarketOrderRepository`. Existe também um repo `FastshopFrontend` — mas o fluxo não passa por ele → não leio."
+
+---
+
+## FASE 3 — Deep Search nos Repos Relevantes
+
+Para cada repo no fluxo, pesquise em profundidade seguindo esta sequência:
+
+1. **Ponto de entrada** — automation, route, trigger, controller principal
+2. **Controller / Handler** — como recebe, valida e despacha o request
+3. **Use Case / Service** — lógica de negócio central
+4. **Repository / Infrastructure** — acesso a banco, filas, APIs externas
+5. **DTOs e validações** — tipagem, decorators, transformações
+6. **Configurações** — config files, variáveis de ambiente, staging vs production
+7. **Testes existentes** — se houver, entenda o que já está coberto
+
+Para cada arquivo lido, registre internamente:
+- Caminho completo + linhas relevantes (ex: `src/http/controllers/AnymarketController.ts:16-31`)
+- O que o trecho faz
+- Como se conecta com o próximo passo do fluxo
+
+> Se encontrar algo que não entende, que parece incompleto, ou que depende de informação externa (nome de fila, credencial, schema de terceiro): **não assuma** — adicione à lista de perguntas da Fase 4.
+
+---
+
+## FASE 4 — Perguntas ao Usuário
+
+Após o mapeamento completo, compile todas as perguntas que não puderam ser respondidas pelo código. Agrupe por categoria e apresente **todas de uma vez**:
+
+- **Negócio / Requisitos** — comportamentos esperados que o código não define
+- **Infraestrutura** — nomes de filas, hosts, credenciais, ambientes (HML/PRD)
+- **Contrato externo** — schemas de APIs de terceiros, autenticação, retry, sandbox
+- **Operacional** — volume estimado, SLA, responsáveis, deduplicação no consumidor
+
+Aguarde todas as respostas antes de gerar o documento.
+
+> Sem limite de perguntas. Prefira perguntar a inventar.
+
+---
+
+## FASE 5 — Geração do Documento
+
+Com contexto completo, gere o documento em `~/Desktop/[nome-da-demanda].md` usando o template abaixo.
+
+Substitua todos os campos entre `[colchetes]` com informações reais verificadas no código ou confirmadas pelo usuário. Não deixe nenhum `[colchete]` no documento final.
+
+---
+
+## Template do Documento
+
+```markdown
+# Estimativa — PPM [NUMERO_PPM] [NOME DA DEMANDA]
+
+> Documento de estimativa e planejamento técnico. **Rascunho para refinamento.**
+> Pontuação Fibonacci: **PP (1–3h), P (3–6h), M (6–9h), G (9–12h), GG (18h), XG (24h)**.
+> As horas finais serão preenchidas pelo PO/Tech Lead após refinamento.
+
+---
+
+## Contexto
+
+[Descrição do que precisa ser feito. Combine a descrição do usuário com o que foi encontrado no código. Cite repos e arquivos onde o contexto foi confirmado. Inclua o impacto no fluxo existente.]
+
+---
+
+## Estado Atual (AS IS)
+
+**Repo:** `[nome-do-repo-principal]`
+
+Fluxo:
+
+1. [Passo 1 — ex: Gateway → `automations/XAutomation.ts`]
+2. [Passo 2 — ex: `src/http/controllers/XController.ts` → `xMethod(ctx)`]
+3. [Passo N — com caminho:linha verificado]
+
+**Observações importantes para o desenho TO BE** (verificadas no código):
+
+- [Observação 1 — `caminho/arquivo.ts:linha` — o que foi encontrado e por que é relevante]
+- [Observação 2 — idem]
+
+Infraestrutura reutilizável já existente:
+
+- `[caminho/Classe.ts]` — [o que faz e como pode ser reaproveitada]
+- [...]
+
+---
+
+## Estado Alvo (TO BE)
+
+[Descrição do novo fluxo proposto. Se houver ramificação de roteamento, use diagrama ASCII:]
+
+```
+[Ponto de entrada]
+  switch [discriminador]:
+    case "[TIPO_A]"  → [UseCase existente] (fluxo atual, INTOCADO)
+    case "[TIPO_B]"  → [Novo UseCase]
+                       ├── [passo 1]
+                       ├── [passo 2]
+                       └── [passo N]
+    default          → log + 200 (não-bloqueante)
+```
+
+**Por que [decisão técnica chave tomada]:**
+
+- [Justificativa 1 — baseada no código existente]
+- [Justificativa 2 — baseada nas respostas do usuário]
+
+---
+
+## Contratos e Integrações Externas
+
+> Seção por integração externa identificada no fluxo.
+
+### [Nome da integração — ex: API AnyMarket, Fila IBM MQ]
+
+**Fonte:** [documentação oficial, código, resposta do usuário]
+
+**Payload / Schema:**
+
+```json
+{
+  "[campo]": "[valor de exemplo]"
+}
+```
+
+**Autenticação:** [como é feita, onde o token está armazenado, confirmado em `arquivo:linha`]
+
+**Retry / Contingência:** [comportamento em falha — confirmado ou perguntado]
+
+**Idempotência:** [estratégia adotada e por quê]
+
+---
+
+## Perguntas Remanescentes para [Nome do time/cliente]
+
+> Apenas o que é genuinamente do lado deles: negócio, infra interna, credenciais, contratos externos.
+
+### [Categoria 1 — ex: Fila GAN]
+
+1. [Pergunta objetiva]
+2. [Pergunta objetiva]
+
+### [Categoria 2 — ex: Cadastro / Credenciais]
+
+1. [Pergunta objetiva]
+
+### [Categoria 3 — ex: Operacional]
+
+1. [Pergunta objetiva]
+
+---
+
+## Estrutura — Épico, Features, Histórias e Tarefas
+
+### ÉPICO: [Título do épico — resumo da demanda em uma linha]
+
+---
+
+#### FEATURE 1 — [Nome da feature]
+
+> [Descrição curta do objetivo desta feature — uma linha]
+
+| #   | História / Tarefa | Tipo     | Estimativa     | Horas (Claude) | Horas (PO/TL) |
+| --- | ----------------- | -------- | -------------- | -------------- | ------------- |
+| 1.1 | [Descrição]       | Tarefa   | **PP**         | 2              |               |
+| 1.2 | [Descrição]       | História | **M**          | 9              |               |
+
+---
+
+#### FEATURE 2 — [Nome da feature]
+
+> [Descrição curta]
+
+| #   | História / Tarefa | Tipo   | Estimativa | Horas (Claude) | Horas (PO/TL) |
+| --- | ----------------- | ------ | ---------- | -------------- | ------------- |
+| 2.1 | [Descrição]       | Tarefa | **P**      | 4              |               |
+
+[Repetir para cada feature identificada]
+
+---
+
+## Riscos & Buffers
+
+- **[Risco 1 — ex: Contrato externo indefinido]**: [Descrição do risco e qual tarefa pode ser impactada]. Se [condição], estimativa X pode subir de **[tamanho]** para **[tamanho maior]**.
+- **[Risco 2 — ex: Dependência de provisionamento externo]**: [Descrição — não conta como esforço de dev mas pode bloquear cronograma].
+- **[Risco 3 — ex: Ausência de testes no repo]**: [Impacto no escopo de testes].
+- **Buffer recomendado**: **+[X]%** sobre o total para [motivo específico — ex: imprevistos de integração, retrabalho pós-validação].
+
+---
+
+## Arquivos Críticos a Modificar
+
+- `[caminho/Arquivo.ts]` — [o que será alterado]
+- `[caminho/Arquivo.ts]` — [o que será alterado]
+- [Novos arquivos a criar:]
+- `[caminho/NovoArquivo.ts]` — [o que fará]
+
+---
+
+## Verificação
+
+[Preencha apenas com comandos e passos confirmados no código — scripts definidos no `package.json`, comandos de teste encontrados no repo, etc. Não inclua comandos de plataforma ou deploy que não foram verificados.]
+
+1. Build local: `[comando confirmado no package.json]`
+2. Testes: `[comando confirmado no package.json]`
+3. [Passo de validação manual que pode ser inferido do fluxo]
+```
+
+---
+
+## Checklist antes de salvar o documento
+
+- [ ] Todos os arquivos citados foram lidos (nenhum chute)
+- [ ] Todo `caminho/arquivo.ts:linha` foi verificado no código
+- [ ] Nenhum `[colchete]` permaneceu no documento final
+- [ ] Perguntas remanescentes são do lado do cliente, não dúvidas técnicas suas
+- [ ] Estimativas usam escala Fibonacci correta: PP / P / M / G / GG / XG
+- [ ] Coluna "Horas (PO/TL)" está em branco em todas as tabelas
+- [ ] Documento está em português
+- [ ] Arquivo salvo em `~/Desktop/[nome-da-demanda].md`

package/slash/reset-folder.md

@@ -0,0 +1,203 @@
+---
+name: reset-folder
+description: Reseta todos os repositórios git filhos da pasta atual para um branch específico (qa/main), tratando alterações locais de forma interativa
+---
+
+# /reset-folder — Sincronizar Repositórios para um Branch
+
+## Uso
+
+```
+/reset-folder qa
+/reset-folder main
+```
+
+---
+
+## REGRA GLOBAL
+
+- Nunca executar `checkout`, `pull`, `stash` ou `reset` sem que o comportamento esperado esteja claro
+- Se travar em qualquer ponto — conflito inesperado, permissão negada, output estranho — **pare e pergunte ao usuário** antes de continuar
+- Tratar cada repositório de forma independente: um erro em um repo não deve impedir a execução nos demais
+
+---
+
+## Passo 1 — Ler argumento
+
+O branch alvo é o argumento passado após `/reset-folder`. Exemplos: `qa`, `main`.
+
+Se nenhum argumento for fornecido, informe:
+**"Qual branch deseja usar? Use: `/reset-folder qa` ou `/reset-folder main`"**
+Interrompa aqui.
+
+---
+
+## Passo 2 — Descobrir repositórios
+
+Execute na pasta atual:
+
+```bash
+for d in */; do
+  [ -d "${d}.git" ] && echo "${d%/}"
+done
+```
+
+Se nenhum repositório for encontrado:
+**"Nenhum repositório git encontrado como subpasta direta de `$(pwd)`. Certifique-se de estar na pasta pai correta."**
+Interrompa aqui.
+
+---
+
+## Passo 3 — Escanear status de cada repositório
+
+Para cada repositório encontrado, colete as informações abaixo **sem modificar nada ainda**:
+
+```bash
+# Branch atual
+git -C <repo> branch --show-current
+
+# Alterações locais (staged + unstaged + untracked)
+git -C <repo> status --short
+
+# Branch alvo existe localmente ou no remote?
+git -C <repo> show-ref --verify --quiet refs/heads/<branch> 2>/dev/null \
+  || git -C <repo> ls-remote --heads origin <branch> 2>/dev/null | grep -q .
+# exit 0 = existe, exit 1 = não existe
+```
+
+Classifique cada repositório em uma das categorias:
+
+| Categoria | Critério |
+|---|---|
+| `PRONTO` | Branch existe, sem alterações locais |
+| `COM ALTERAÇÕES` | Branch existe, mas tem mudanças locais |
+| `SEM BRANCH` | Branch alvo não existe no repo |
+
+---
+
+## Passo 4 — Apresentar panorama ao usuário
+
+Antes de qualquer ação, mostre o resumo completo:
+
+```
+Repositórios encontrados em <pasta atual>:
+
+  ✅ PRONTOS (serão atualizados automaticamente):
+     • api-service        [main → qa]
+     • frontend           [main → qa]
+
+  ⚠️  COM ALTERAÇÕES LOCAIS (aguardando decisão):
+     • backend            [qa]  — 3 arquivos modificados
+
+  ✗  SEM BRANCH "qa" (serão ignorados):
+     • legacy-app         — branch "qa" não encontrado
+
+Total: 4 repositórios | 2 prontos | 1 com alterações | 1 sem branch
+```
+
+Pergunte: **"Posso prosseguir? Vou tratar os repositórios com alterações um a um antes de continuar."**
+
+Aguarde confirmação antes de continuar.
+
+---
+
+## Passo 5 — Tratar repositórios COM ALTERAÇÕES (interativo)
+
+Para cada repositório da categoria `COM ALTERAÇÕES`, **um de cada vez**:
+
+**5.1 — Mostrar o que mudou:**
+
+```bash
+git -C <repo> status --short
+git -C <repo> diff --stat
+```
+
+Apresente ao usuário:
+
+```
+Repositório: backend  (branch atual: qa)
+
+Arquivos modificados:
+  M  src/auth/login.js
+  M  src/auth/middleware.js
+  ?? src/auth/newfile.js
+
+O que deseja fazer com essas alterações?
+
+  [1] Stash — guardar as alterações e continuar o reset (pode recuperar depois)
+  [2] Commit — fazer commit das alterações no branch atual antes de mudar
+  [3] Descartar — apagar todas as alterações locais (irreversível)
+  [4] Pular — deixar este repositório como está, sem alterar
+```
+
+**5.2 — Executar conforme escolha:**
+
+- **[1] Stash:**
+  ```bash
+  git -C <repo> stash push -m "reset-folder: stash antes de mudar para <branch> — $(date +%Y-%m-%d)"
+  ```
+  Confirme que o stash foi criado. Se falhar, informe e pergunte o que fazer.
+
+- **[2] Commit:**
+  Pergunte: **"Qual mensagem de commit para as alterações em `<repo>`?"**
+  Aguarde a resposta, então:
+  ```bash
+  git -C <repo> add -A
+  git -C <repo> commit -m "<mensagem do usuário>"
+  ```
+  Se falhar (ex: nada para commitar, hook rejeitou), informe o erro e pergunte o que fazer.
+
+- **[3] Descartar:**
+  Confirme com o usuário: **"Confirma que deseja DESCARTAR todas as alterações em `<repo>`? Isso é irreversível."**
+  Só prossiga após confirmação explícita:
+  ```bash
+  git -C <repo> checkout -- .
+  git -C <repo> clean -fd
+  ```
+
+- **[4] Pular:**
+  Marque o repo como `PULADO` no resumo final. Não execute nada nele.
+
+---
+
+## Passo 6 — Executar checkout + pull
+
+Para cada repositório das categorias `PRONTO` e `COM ALTERAÇÕES` (que não foi pulado):
+
+```bash
+# Mudar para o branch alvo
+git -C <repo> checkout <branch>
+```
+
+Se o checkout falhar:
+**"Erro ao fazer checkout em `<repo>`: <mensagem de erro>. O que deseja fazer?"**
+Aguarde instrução antes de tentar o pull.
+
+```bash
+# Atualizar com o remote
+git -C <repo> pull origin <branch>
+```
+
+Se o pull gerar conflito:
+**"Conflito de merge em `<repo>` ao fazer pull de `<branch>`. Os conflitos estão em: <arquivos>. O que deseja fazer?"**
+Opções sugeridas: resolver manualmente, usar `--ours`, abortar o merge.
+
+---
+
+## Passo 7 — Resumo Final
+
+Ao concluir, apresente o resultado de cada repositório:
+
+```
+Resumo — reset-folder <branch>
+
+  ✅ api-service      → <branch> atualizado  (pull: 3 commits novos)
+  ✅ frontend         → <branch> atualizado  (pull: já estava atualizado)
+  ✅ backend          → <branch> atualizado  (stash criado antes do pull)
+  ⏭️  legacy-app      → ignorado             (branch "<branch>" não existe)
+
+Concluído. 3 repositórios atualizados, 1 ignorado.
+```
+
+Se algum repositório ficou com stash pendente, lembre o usuário:
+**"O repositório `<repo>` tem um stash salvo com as alterações anteriores. Use `git stash pop` dentro dele quando quiser recuperá-las."**

package/{.claude/skills/update-memory/SKILL.md → slash/update-memory.md}

@@ -7,7 +7,7 @@ description: Atualizar o índice de memória semântica (Neo4j) de um repositór
 
 Você vai identificar o que mudou no repositório desde a última indexação e aplicar as atualizações no grafo de memória.
 
-**Antes de iniciar:** leia `.claude/skills/MEMORY_ARCHITECTURE.md` — ele define o schema, as regras de indexação e os critérios de qualidade que guiam esta skill.
+**Antes de iniciar:** leia `~/.claude/commands/MEMORY_ARCHITECTURE.md` — ele define o schema, as regras de indexação e os critérios de qualidade que guiam esta skill.
 
 ## PRÉ-REQUISITO — Verificar ambiente