@luanpdd/kit-mcp 0.2.0 → 0.3.0

package/kit/commands/publicar.md

@@ -0,0 +1,370 @@
+---
+name: publicar
+description: Publica o milestone atual — cria documentação no Notion, abre PR no GitHub com link Notion na descrição
+argument-hint: "[versão opcional, ex: 'v1.1']"
+allowed-tools:
+  - Read
+  - Bash
+  - Grep
+  - Glob
+  - Write
+  - AskUserQuestion
+  - mcp__claude_ai_Notion__notion-create-pages
+---
+
+# /publicar — Publicar Milestone com Documentação Notion + GitHub
+
+Publica o milestone atual: cria documentação no Notion, abre PR no GitHub e inclui o link Notion na descrição do PR.
+
+## Quando usar
+
+Após concluir e arquivar um milestone com `/concluir-marco`.
+
+## Dependências obrigatórias
+
+- `.claude/notion-config.json` presente e preenchido — se não existir, encerre com:
+  > "⛔ notion-config.json não encontrado. Execute /setup-notion para configurar o Notion deste projeto."
+- Notion MCP configurado na sessão Claude Code
+- `gh` CLI autenticado (`gh auth status`)
+- Milestone arquivado com `/concluir-marco`
+
+## Dependências opcionais
+
+- `$OBSIDIAN_TEAM_VAULT` — caminho absoluto do cofre Obsidian do time (sincronizado via Git).
+  - Se ausente ou inválido: o **Passo 5 (Obsidian)** é pulado com aviso, sem quebrar PR/Notion.
+
+## Processo
+
+### Passo 1 — Ler contexto
+
+Leia os seguintes arquivos:
+- `.claude/notion-config.json` → IDs das páginas Notion
+- `.planning/STATE.md` → versão e nome do milestone
+- `.planning/PROJECT.md` → nome e stack do projeto
+- `.planning/milestones/` → arquivos do último milestone arquivado (ROADMAP + REQUIREMENTS)
+- `.planning/milestones/vX.X-MILESTONE-AUDIT.md` → cobertura de requisitos e métricas
+
+Extraia:
+- `VERSION` — ex: `v1.1`
+- `MILESTONE_NAME` — ex: `Nome do Milestone`
+- `NOTION_CHANGELOG_PAGE_ID` — do notion-config.json
+- Realizações principais (das SUMMARY.md ou do ROADMAP arquivado)
+- Decisões arquiteturais (do STATE.md ou SUMMARYs)
+- Dívidas técnicas
+- Métricas (testes, arquivos, fases, planos)
+
+### Passo 2 — Decidir branch de publicação
+
+Execute `git branch --show-current` para identificar a branch local atual.
+
+Use `AskUserQuestion` com opções para perguntar ao usuário:
+
+```
+question: "Branch atual: {BRANCH_ATUAL}. Como deseja publicar?"
+header: "Branch"
+options:
+  - label: "Usar branch atual"
+    description: "Commit, push e PR na branch {BRANCH_ATUAL}"
+  - label: "Criar nova branch"
+    description: "Criar uma branch a partir da main com nome baseado nas mudanças"
+```
+
+#### Se "Usar branch atual"
+
+- Verifique mudanças não commitadas: `git status --porcelain`
+- Se houver, use `AskUserQuestion`:
+  ```
+  question: "Há mudanças não commitadas. Deseja incluí-las no commit?"
+  header: "Commit"
+  options:
+    - label: "Sim, incluir tudo"
+      description: "git add . — o commit será feito após criar o Notion (para incluir o link)"
+    - label: "Não, só fazer push"
+      description: "Pular o commit e ir direto para o push"
+  ```
+  - Se "Sim": guarde `PENDENTE_COMMIT = true`. O commit será executado no Passo 3, depois de ter o `NOTION_URL`.
+- Prossiga para o Passo 3 com `BRANCH = {BRANCH_ATUAL}`
+
+#### Se "Criar nova branch"
+
+Analise o conteúdo do milestone para inferir tipo e escopo e gere o nome sugerido:
+
+**Regras de nomenclatura:**
+
+| Tipo de mudança | Prefixo | Exemplo |
+|---|---|---|
+| Correção de bug | `fix` | `fix-sidebar-v2` |
+| Nova feature | `feat` | `feat-dashboard-icons` |
+| Refatoração | `refactor` | `refactor-auth-flow` |
+| Melhoria de performance | `perf` | `perf-sidebar` |
+| Mudança visual / UI | `ui` | `ui-dashboard-icons` |
+| Atualização de conteúdo/texto | `content` | `content-onboarding` |
+
+**Formato:** `{prefixo}-{nome-da-aba-modal-ou-area}-{versão se houver mais de uma branch do mesmo tipo}`
+
+Use `AskUserQuestion` para confirmar o nome sugerido:
+
+```
+question: "Nome sugerido para a nova branch: {NOME_SUGERIDO}. Confirma?"
+header: "Nome da branch"
+options:
+  - label: "{NOME_SUGERIDO}"
+    description: "Usar o nome sugerido"
+  - label: "Outro nome"
+    description: "Digitar um nome diferente"
+```
+
+Se "Outro nome" → aguarde o usuário digitar via campo "Other" do modal.
+
+Após confirmação:
+```bash
+git fetch origin
+git checkout -b {NOVA_BRANCH} origin/main
+```
+
+- Se havia mudanças não commitadas na branch anterior, use `AskUserQuestion`:
+  ```
+  question: "Deseja levar as mudanças não commitadas para a nova branch?"
+  header: "Mudanças"
+  options:
+    - label: "Sim, transportar"
+      description: "git stash → checkout → git stash pop"
+    - label: "Não, descartar"
+      description: "Deixar as mudanças na branch anterior"
+  ```
+- Prossiga para o Passo 3 com `BRANCH = {NOVA_BRANCH}`
+
+### Passo 3 — Criar página Notion ⚠️ OBRIGATÓRIO — não pule esta etapa
+
+**Esta etapa deve ser executada ANTES do push e do PR.** O link do Notion precisa estar disponível para incluir na descrição do PR.
+
+Use o Notion MCP (`notion-create-pages`) para criar uma subpágina em `NOTION_CHANGELOG_PAGE_ID` (a página `changelog/` do projeto).
+
+Após chamar `notion-create-pages`, armazene a URL retornada como `NOTION_URL`.
+
+Se `PENDENTE_COMMIT = true`, execute o commit agora com o link incluído:
+```bash
+git add .
+git commit -m "{tipo}: {MILESTONE_NAME}
+
+Notion: {NOTION_URL}"
+```
+
+**Template da página:**
+
+```
+Título: {VERSION} — {MILESTONE_NAME}
+Ícone: 🚀
+
+[Callout verde] Entregue em: {DATA} | Requisitos: X/X | Testes: N passando
+
+---
+
+# Para o Time de Produto
+
+## O que você consegue fazer agora
+[Para cada feature entregue: 1 parágrafo em linguagem de produto, sem jargão técnico]
+[Se houver UI nova: inclua passo a passo "Como usar"]
+
+---
+
+# Para o Time Técnico
+
+## O que mudou no código
+[Tabela: Arquivo | O que mudou]
+[Code snippet do padrão principal implementado, se relevante]
+
+## Decisões Arquiteturais
+[Toggle para cada decisão relevante: contexto + decisão + consequências]
+
+## Dívidas Técnicas Registradas
+[Tabela: Item | Impacto | Quando tratar]
+
+---
+
+## Referências
+- Branch: `{BRANCH}`
+- Tag git: `{VERSION}`
+- Testes: N passando
+- Auditoria: `.planning/{VERSION}-MILESTONE-AUDIT.md`
+```
+
+**Regras de voz:**
+- Seção "Produto": sem nomes de arquivo, sem SQL, sem termos de código. Foco em "antes X, agora Y".
+- Seção "Técnico": arquivos reais, commits, decisões de implementação.
+
+### Passo 4 — Push e PR no GitHub
+
+⚠️ Só execute este passo após ter o `NOTION_URL` do Passo 3.
+
+```bash
+git push origin {BRANCH}
+
+gh pr create \
+  --title "{VERSION}: {MILESTONE_NAME}" \
+  --body "..."
+```
+
+**Template do body do PR:**
+
+```markdown
+## {VERSION} — {MILESTONE_NAME}
+
+### O que muda
+[3-5 bullet points em linguagem de negócio]
+
+### Cobertura
+- Requisitos: X/X satisfeitos
+- Testes: N passando
+- TypeScript: limpo (0 erros)
+
+### Documentação
+📄 Notion: {NOTION_URL}
+
+### Como testar
+[Checklist de smoke tests manuais do MILESTONE-AUDIT.md]
+```
+
+**Regras para o PR:**
+- Sem rodapé de assinatura de IA
+- Sem menção a ferramentas ou geradores
+- Linguagem direta, como se fosse escrito pelo dev
+
+### Passo 5 — 📚 Atualizar cofre Obsidian do time
+
+⚠️ **Este passo é "bônus".** Se falhar por qualquer motivo (variável ausente, caminho inválido, conflito Git não-resolvível, push rejeitado após retry), **armazene o motivo em `OBSIDIAN_SKIP_REASON` e prossiga para o Passo 6**. PR e Notion já estão feitos — o dev atualiza o cofre manualmente depois.
+
+#### 5.1 — Validar ambiente
+
+- Ler `$OBSIDIAN_TEAM_VAULT`.
+- Se a variável não estiver definida:
+  > ⚠️ Variável OBSIDIAN_TEAM_VAULT não configurada. Pule para os próximos passos do onboarding no README do cofre.
+
+  Defina `OBSIDIAN_SKIP_REASON = "OBSIDIAN_TEAM_VAULT não configurada"` e vá para o Passo 6.
+- Se definida mas o caminho não existir (`test -d "$OBSIDIAN_TEAM_VAULT"` falha):
+  > ⚠️ Cofre Obsidian não encontrado em: {caminho}. Verifique se o clone local existe.
+
+  Defina `OBSIDIAN_SKIP_REASON = "Cofre não encontrado em {caminho}"` e vá para o Passo 6.
+
+#### 5.2 — Sincronizar com remoto
+
+```bash
+git -C "$OBSIDIAN_TEAM_VAULT" pull --rebase
+```
+
+- Se o `pull --rebase` falhar com conflito, tentar resolução automática:
+  ```bash
+  git -C "$OBSIDIAN_TEAM_VAULT" rebase --abort 2>/dev/null || true
+  git -C "$OBSIDIAN_TEAM_VAULT" pull --rebase -X theirs
+  ```
+- Se ainda assim falhar: defina `OBSIDIAN_SKIP_REASON = "Conflito Git no cofre — resolver manualmente"` e vá para o Passo 6.
+
+#### 5.3 — Ler CLAUDE.md do cofre
+
+Ler `$OBSIDIAN_TEAM_VAULT/CLAUDE.md`. Esse arquivo contém as convenções de documentação do time (nomenclatura, estrutura de pastas, templates, convenções de commit). **As regras vivem lá** — siga o que o CLAUDE.md mandar, não o que este prompt diz de cor.
+
+Se o `CLAUDE.md` não existir: defina `OBSIDIAN_SKIP_REASON = "CLAUDE.md ausente no cofre — estrutura desconhecida"` e vá para o Passo 6.
+
+#### 5.4 — Criar/atualizar as notas
+
+Baseado no contexto do PR que acabou de ser publicado (número, título, arquivos tocados, `MILESTONE_NAME`, `NOTION_URL`):
+
+**a) Nota do PR** (obrigatória)
+
+Caminho: `01 - PRs/YYYY/YYYY-MM-DD-pr-{PR_NUMBER}-{slug-do-titulo}.md`
+
+- `YYYY` / `YYYY-MM-DD` = data do merge/criação do PR.
+- `slug-do-titulo` = título do PR em kebab-case (lowercase, sem acentos, espaços → `-`, sem pontuação).
+- Usar `09 - Templates/template-pr.md` como base.
+- **Frontmatter DEVE conter `notion: {NOTION_URL}`** para ponte bidirecional entre as duas bases.
+
+**b) Changelog** (obrigatório)
+
+Caminho: `03 - Changelog/YYYY.md`
+
+- Adicionar entrada na seção `## Não lançado`, nas subseções apropriadas:
+  - `### Adicionado` — features novas
+  - `### Alterado` — mudanças de comportamento existente
+  - `### Corrigido` — bugs
+  - `### Removido` — remoções
+- Cada entrada deve referenciar o número do PR.
+
+**c) Notas de componentes/endpoints afetados** (condicional)
+
+Se o PR tocar componentes/páginas/endpoints existentes:
+- Localizar a nota correspondente em `05 - Frontend/` e/ou `06 - Backend/`.
+- Atualizar a seção `## Histórico de mudanças` com a data (`YYYY-MM-DD`) e o link do PR.
+
+Se o PR introduzir algo **novo**:
+- Criar nova nota em `05 - Frontend/` ou `06 - Backend/` usando `09 - Templates/template-funcionalidade.md`.
+
+#### 5.5 — Commit e push
+
+```bash
+cd "$OBSIDIAN_TEAM_VAULT"
+git add .
+git commit -m "docs(pr-{PR_NUMBER}): {título-curto}"
+git push
+```
+
+- Título curto = slug do título do PR truncado em ~60 chars, seguindo convenções de commit do `CLAUDE.md` do cofre.
+- Se o `git push` falhar por divergência:
+  ```bash
+  git pull --rebase
+  git push
+  ```
+- Se ainda falhar: defina `OBSIDIAN_SKIP_REASON = "Push rejeitado após rebase — resolver manualmente"` e vá para o Passo 6.
+
+#### 5.6 — Capturar link da nota de PR
+
+Construir a URL pública da nota no GitHub. Defina o repositório do cofre via env var `OBSIDIAN_VAULT_REPO` (formato `owner/repo`):
+
+```
+OBSIDIAN_URL = https://github.com/${OBSIDIAN_VAULT_REPO}/blob/main/01%20-%20PRs/YYYY/YYYY-MM-DD-pr-{PR_NUMBER}-{slug}.md
+```
+
+Se `OBSIDIAN_VAULT_REPO` não estiver definida, defina `OBSIDIAN_SKIP_REASON = "OBSIDIAN_VAULT_REPO não configurada"` e vá para o Passo 6.
+
+- Encode: espaços → `%20`. Barras internas permanecem literais.
+- Armazene como `OBSIDIAN_URL` para uso no Passo 6.
+
+### Passo 6 — Reportar resultado
+
+Exiba ao usuário:
+
+```
+✅ Milestone {VERSION} publicado
+
+📄 Notion: {NOTION_URL}
+🔗 PR: {PR_URL}
+📚 Obsidian: {OBSIDIAN_URL}
+🌿 Branch: {BRANCH}
+```
+
+Se o Passo 5 foi pulado, substitua a linha do Obsidian por:
+
+```
+⚠️ Obsidian: pulado — {OBSIDIAN_SKIP_REASON}
+```
+
+(mantendo as demais linhas intactas)
+
+## Para outros projetos
+
+Copie `.claude/notion-config.json` para o projeto e preencha com os IDs corretos:
+
+```json
+{
+  "project": "NomeDoProjeto",
+  "notion": {
+    "root": "ID_DA_PAGINA_PRINCIPAL",
+    "root_url": "https://www.notion.so/...",
+    "changelog": "ID_DA_PAGINA_CHANGELOG",
+    "features": "ID_DA_PAGINA_FEATURES",
+    "adr": "ID_DA_PAGINA_ADR",
+    "runbooks": "ID_DA_PAGINA_RUNBOOKS"
+  }
+}
+```
+
+Para criar a estrutura de um novo projeto no Notion, execute `/setup-notion`.

package/kit/commands/rapido.md

@@ -0,0 +1,30 @@
+---
+name: rapido
+description: Executa uma tarefa trivial inline — sem subagentes, sem overhead de planejamento
+argument-hint: "[descrição da tarefa]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Grep
+  - Glob
+---
+
+<objective>
+Executa uma tarefa trivial diretamente no contexto atual sem invocar subagentes
+ou gerar arquivos PLAN.md. Para tarefas pequenas demais para justificar overhead de planejamento:
+correções de typo, mudanças de configuração, pequenas refatorações, commits esquecidos, adições simples.
+
+Este NÃO é um substituto para /expresso — use /expresso para qualquer coisa que
+precise de pesquisa, planejamento multi-etapas ou verificação. /rapido é para tarefas
+que você poderia descrever em uma frase e executar em menos de 2 minutos.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/fast.md
+</execution_context>
+
+<process>
+Execute o workflow fast de @./.claude/framework/workflows/fast.md do início ao fim.
+</process>

package/kit/commands/reaplicar-patches.md

@@ -0,0 +1,124 @@
+---
+name: reaplicar-patches
+description: Reaplicar modificações locais após uma atualização do framework
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
+---
+
+<purpose>
+Após uma atualização do framework limpar e reinstalar arquivos, este comando mescla as modificações locais salvas anteriormente pelo usuário de volta para a nova versão. Usa comparação inteligente para tratar casos onde o arquivo upstream também foi alterado.
+</purpose>
+
+<process>
+
+## Passo 1: Detectar patches com backup
+
+Verificar diretório de patches locais:
+
+```bash
+# Instalação global — detectar diretório de config do runtime
+if [ -d "$HOME/.config/opencode/local-patches" ]; then
+  PATCHES_DIR="$HOME/.config/opencode/local-patches"
+elif [ -d "$HOME/.opencode/local-patches" ]; then
+  PATCHES_DIR="$HOME/.opencode/local-patches"
+elif [ -d "$HOME/.gemini/local-patches" ]; then
+  PATCHES_DIR="$HOME/.gemini/local-patches"
+else
+  PATCHES_DIR="./.claude/local-patches"
+fi
+# Fallback para instalação local — verificar todos os diretórios de runtime
+if [ ! -d "$PATCHES_DIR" ]; then
+  for dir in .config/opencode .opencode .gemini .claude; do
+    if [ -d "./$dir/local-patches" ]; then
+      PATCHES_DIR="./$dir/local-patches"
+      break
+    fi
+  done
+fi
+```
+
+Ler `backup-meta.json` do diretório de patches.
+
+**Se nenhum patch encontrado:**
+```
+Nenhum patch local encontrado. Nada a reaplicar.
+
+Patches locais são salvos automaticamente quando você executa /atualizar
+após modificar qualquer workflow, comando ou arquivo de agente do framework.
+```
+Sair.
+
+## Passo 2: Mostrar resumo de patches
+
+```
+## Patches Locais para Reaplicar
+
+**Backup de:** v{from_version}
+**Versão atual:** {ler arquivo VERSION}
+**Arquivos modificados:** {contagem}
+
+| # | Arquivo | Status |
+|---|---------|--------|
+| 1 | {file_path} | Pendente |
+| 2 | {file_path} | Pendente |
+```
+
+## Passo 3: Mesclar cada arquivo
+
+Para cada arquivo em `backup-meta.json`:
+
+1. **Ler a versão com backup** (cópia modificada pelo usuário de `local-patches/`)
+2. **Ler a versão recém-instalada** (arquivo atual após atualização)
+3. **Comparar e mesclar:**
+
+   - Se o novo arquivo for idêntico ao arquivo com backup: pular (modificação foi incorporada upstream)
+   - Se o novo arquivo diferir: identificar as modificações do usuário e aplicá-las à nova versão
+
+   **Estratégia de mesclagem:**
+   - Ler ambas as versões completamente
+   - Identificar seções que o usuário adicionou ou modificou (procurar por adições, não apenas diferenças de substituição de caminho)
+   - Aplicar adições/modificações do usuário à nova versão
+   - Se uma seção que o usuário modificou também foi alterada upstream: sinalizar como conflito, mostrar ambas as versões, perguntar ao usuário qual manter
+
+4. **Escrever resultado mesclado** no local instalado
+5. **Reportar status:**
+   - `Mesclado` — modificações do usuário aplicadas corretamente
+   - `Pulado` — modificação já está upstream
+   - `Conflito` — usuário escolheu resolução
+
+## Passo 4: Atualizar manifesto
+
+Após reaplicar, regenerar o manifesto de arquivo para que futuras atualizações detectem corretamente estes como modificações do usuário:
+
+```bash
+# O manifesto será regenerado no próximo /atualizar
+# Por agora, apenas registrar quais arquivos foram modificados
+```
+
+## Passo 5: Opção de limpeza
+
+Perguntar ao usuário:
+- "Manter backups de patch para referência?" → preservar `local-patches/`
+- "Limpar backups de patch?" → remover diretório `local-patches/`
+
+## Passo 6: Relatório
+
+```
+## Patches Reaplicados
+
+| # | Arquivo | Status |
+|---|---------|--------|
+| 1 | {file_path} | ✓ Mesclado |
+| 2 | {file_path} | ○ Pulado (já está upstream) |
+| 3 | {file_path} | ⚠ Conflito resolvido |
+
+{contagem} arquivo(s) atualizado(s). Suas modificações locais estão ativas novamente.
+```
+
+</process>
+
+<success_criteria>
+- [ ] Todos os patches com backup processados
+- [ ] Modificações do usuário mescladas na nova versão
+- [ ] Conflitos resolvidos com entrada do usuário
+- [ ] Status reportado para cada arquivo
+</success_criteria>

package/kit/commands/relatorio-sessao.md

@@ -0,0 +1,19 @@
+---
+name: relatorio-sessao
+description: Gera relatório da sessão com estimativas de uso de tokens, resumo de trabalho e resultados
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+---
+<objective>
+Gera um documento SESSION_REPORT.md estruturado capturando resultados da sessão, trabalho realizado e uso estimado de recursos. Fornece um artefato compartilhável para revisão pós-sessão.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/session-report.md
+</execution_context>
+
+<process>
+Execute o workflow session-report de @./.claude/framework/workflows/session-report.md do início ao fim.
+</process>

package/kit/commands/remover-fase.md

@@ -0,0 +1,31 @@
+---
+name: remover-fase
+description: Remove uma fase futura do roadmap e renumera as fases subsequentes
+argument-hint: <phase-number>
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+---
+<objective>
+Remover uma fase futura não iniciada do roadmap e renumerar todas as fases subsequentes para manter uma sequência limpa e linear.
+
+Propósito: Remoção limpa de trabalho que você decidiu não fazer, sem poluir o contexto com marcadores cancelados/adiados.
+Saída: Fase deletada, todas as fases subsequentes renumeradas, commit git como registro histórico.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/remove-phase.md
+</execution_context>
+
+<context>
+Fase: $ARGUMENTS
+
+Roadmap e estado são resolvidos no workflow via `init phase-op` e leituras específicas.
+</context>
+
+<process>
+Execute o workflow remove-phase de @./.claude/framework/workflows/remove-phase.md do início ao fim.
+Preserve todos os checkpoints de validação (verificação de fase futura, verificação de trabalho), lógica de renumeração e commit.
+</process>

package/kit/commands/remover-workspace.md

@@ -0,0 +1,26 @@
+---
+name: remover-workspace
+description: Remove um workspace framework e limpa as worktrees
+argument-hint: "<nome-do-workspace>"
+allowed-tools:
+  - Bash
+  - Read
+  - AskUserQuestion
+---
+<context>
+**Argumentos:**
+- `<nome-do-workspace>` (obrigatório) — Nome do workspace a remover
+</context>
+
+<objective>
+Remove um diretório de workspace após confirmação. Para estratégia de worktree, executa `git worktree remove` para cada repositório membro primeiro. Recusa se algum repositório tiver alterações não commitadas.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/remove-workspace.md
+@./.claude/framework/references/ui-brand.md
+</execution_context>
+
+<process>
+Execute o workflow remove-workspace de @./.claude/framework/workflows/remove-workspace.md do início ao fim.
+</process>

package/kit/commands/resumo-marco.md

@@ -0,0 +1,51 @@
+---
+type: prompt
+name: resumo-marco
+description: Gera um resumo abrangente do projeto a partir dos artefatos do milestone para onboarding e revisão da equipe
+argument-hint: "[version]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+---
+
+<objective>
+Gerar um resumo estruturado do milestone para onboarding da equipe e revisão do projeto. Lê artefatos do milestone concluído (arquivos ROADMAP, REQUIREMENTS, CONTEXT, SUMMARY, VERIFICATION) e produz uma visão geral amigável do que foi construído, como e por quê.
+
+Propósito: Permitir que novos membros da equipe entendam um projeto concluído lendo um documento e fazendo perguntas de acompanhamento.
+Saída: MILESTONE_SUMMARY escrito em `.planning/reports/`, apresentado inline, Q&A interativo opcional.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/milestone-summary.md
+</execution_context>
+
+<context>
+**Arquivos do projeto:**
+- `.planning/ROADMAP.md`
+- `.planning/PROJECT.md`
+- `.planning/STATE.md`
+- `.planning/RETROSPECTIVE.md`
+- `.planning/milestones/v{version}-ROADMAP.md` (se arquivado)
+- `.planning/milestones/v{version}-REQUIREMENTS.md` (se arquivado)
+- `.planning/phases/*-*/` (SUMMARY.md, VERIFICATION.md, CONTEXT.md, RESEARCH.md)
+
+**Entrada do usuário:**
+- Versão: $ARGUMENTS (opcional — padrão para milestone atual/mais recente)
+</context>
+
+<process>
+Ler e executar o workflow milestone-summary de @./.claude/framework/workflows/milestone-summary.md do início ao fim.
+</process>
+
+<success_criteria>
+- Versão do milestone resolvida (de argumentos, STATE.md ou scan de arquivo)
+- Todos os artefatos disponíveis lidos (ROADMAP, REQUIREMENTS, CONTEXT, SUMMARY, VERIFICATION, RESEARCH, RETROSPECTIVE)
+- Documento de resumo escrito em `.planning/reports/MILESTONE_SUMMARY-v{version}.md`
+- Todas as 7 seções geradas (Visão Geral, Arquitetura, Fases, Decisões, Requisitos, Dívida Técnica, Começando)
+- Resumo apresentado inline ao usuário
+- Q&A interativo oferecido
+- STATE.md atualizado
+</success_criteria>

package/kit/commands/retomar-trabalho.md

@@ -0,0 +1,40 @@
+---
+name: retomar-trabalho
+description: Retoma o trabalho da sessão anterior com restauração completa de contexto
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - AskUserQuestion
+  - SlashCommand
+---
+
+<objective>
+Restaura o contexto completo do projeto e retoma o trabalho de forma contínua a partir da sessão anterior.
+
+Roteia para o workflow resume-project que trata:
+
+- Carregamento do STATE.md (ou reconstrução se ausente)
+- Detecção de checkpoints (arquivos .continue-here)
+- Detecção de trabalho incompleto (PLAN sem SUMMARY)
+- Apresentação de status
+- Roteamento de próxima ação com consciência de contexto
+  </objective>
+
+<execution_context>
+@./.claude/framework/workflows/resume-project.md
+</execution_context>
+
+<process>
+**Seguir o workflow resume-project** de `@./.claude/framework/workflows/resume-project.md`.
+
+O workflow trata toda a lógica de retomada incluindo:
+
+1. Verificação de existência do projeto
+2. Carregamento ou reconstrução do STATE.md
+3. Detecção de checkpoints e trabalho incompleto
+4. Apresentação visual de status
+5. Oferta de opções com consciência de contexto (verifica CONTEXT.md antes de sugerir planejar vs discutir)
+6. Roteamento para próximo comando apropriado
+7. Atualizações de continuidade da sessão
+   </process>