@luanpdd/kit-mcp 1.35.0 → 1.36.0

package/kit/commands/criar-workflow.md

@@ -1,158 +1,158 @@
----
-name: criar-workflow
-description: Gera um Dynamic Workflow customizado pro teu projeto. Pergunta o padrao de harness (6 opcoes), eliciaa params especificos, compoe reusando agents/skills do kit, materializa em .claude/workflows/.
-argument-hint: "<descricao livre em portugues do que voce quer auditar/automatizar>"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Grep
-  - Glob
-  - AskUserQuestion
-  - Task
----
-
-# criar-workflow
-
-> Entrypoint pra gerar um Dynamic Workflow customizado pro teu projeto. O kit não cresce com workflows de nicho — cresce com a capacidade de gerar workflows sob demanda.
-
-> Cada usuário ganha o DELE, calibrado pro stack/dor que ele tem. Outro usuário com necessidade diferente roda `/criar-workflow <sua descrição>` e ganha um diferente.
-
-<objective>
-Invoca o agent [`workflow-generator`](../agents/workflow-generator.md) que executa 4 layers:
-
-1. **Classify** — pergunta qual dos 6 patterns canônicos (Classify-Act, Fanout-Synthesize, Adversarial-Verify, Generate-Filter, Tournament, Loop-Done) encaixa
-2. **Specify** — faz 2-4 perguntas específicas do pattern escolhido
-3. **Compose** — detecta MCP necessárias + propõe reuso de agents canônicos do kit
-4. **Materialize** — escreve `.claude/workflows/<slug>.workflow.js` + `.claude/commands/<slug>.md` (locais ao projeto, NUNCA no kit canônico)
-
-**Cria:**
-- `.claude/workflows/<slug>.workflow.js` — script JS executável pela tool Workflow do Claude Code
-- `.claude/commands/<slug>.md` — slash-command que dispara o workflow
-
-**Após:** `/<slug> [--args]` invoca direto. Pra rodar a cada N minutos: `/loop 3m /<slug>`. Pra cron remoto: `/schedule "*/3 * * * *" <slug>`.
-</objective>
-
-<context>
-**Argumento:**
-- `$ARGUMENTS` — descrição livre em português do objetivo. Quanto mais específico, menos perguntas o gerador faz no Layer 1.
-
-**Exemplos:**
-```
-/criar-workflow auditar comportamento dos agentes IA atendendo WhatsApp 
-                a cada 3 minutos, analisar transcripts e gerar report
-
-/criar-workflow rankear top 10 PRs no GitHub abertos ha mais de 7 dias 
-                sem revisao por impacto
-
-/criar-workflow bug hunt continuo no codigo do servico de pagamento 
-                ate 2 rounds sem novos achados
-
-/criar-workflow brainstorm 12 nomes pra minha CLI e pegar top 3 por 
-                memorability + brand fit
-```
-
-**Pré-requisitos:**
-- Claude Code Max / Team / Enterprise (Dynamic Workflows em research preview Opus 4.8+)
-- Tool `Workflow` habilitada na sessão
-- `.claude/workflows/` existe ou sera criado
-
-**Quando NÃO usar:**
-- Tarefa cabe em 1 slash-command existente (ex.: ja temos `/auditar-observabilidade-cobertura-workflow` — não duplique)
-- Descrição vaga ("automatize meu projeto") — refine antes
-- Mudança que precisa entrar no kit canônico — esses são PRs no repo `luanpdd/kit-mcp`, não workflows locais
-</context>
-
-<process>
-
-## 1. Validar descrição mínima
-
-```bash
-DESC="$ARGUMENTS"
-if [ -z "$DESC" ] || [ ${#DESC} -lt 10 ]; then
-  echo "ERRO: descreva o que voce quer com pelo menos 10 chars."
-  echo "Exemplo: /criar-workflow auditar conversas IA no WhatsApp a cada 3min"
-  exit 1
-fi
-```
-
-## 2. Garantir destino existe
-
-```bash
-mkdir -p .claude/workflows .claude/commands
-```
-
-## 3. Dispatch para workflow-generator
-
-```text
-Task(
-  subagent_type="workflow-generator",
-  prompt="
-description: ${DESC}
-output_dir_workflows: .claude/workflows/
-output_dir_commands: .claude/commands/
-
-Execute os 4 layers conforme spec do agent:
-
-LAYER 0 — Classify (AskUserQuestion obrigatorio, 6 opcoes do pattern)
-LAYER 1 — Specify (perguntas especificas do pattern escolhido, 2-4 max)
-LAYER 2 — Compose (detectar MCP + propor reuso de agents do kit via AskUserQuestion)
-LAYER 3 — Materialize (.workflow.js + .md com header // kit-mcp:user-generated)
-LAYER 4 — Deliver (output formatado com slug, pattern, MCP, comandos /<slug>, /loop, /schedule)
-
-REGRAS DURAS:
-- meta literal puro (sem template literals, sem function calls, sem spread)
-- Todo agent() com schema JSON Schema declarado (required: [...])
-- pipeline() default, parallel() so com justificativa inline
-- Sem Date.now()/Math.random()/argless new Date() — pra randomness varie por indice, pra timestamps passe via args
-- Header // kit-mcp:user-generated no topo do .workflow.js (distingue de // kit-mcp:reference do canonico)
-
-NAO escreva em kit/ — workflows gerados sao locais.
-"
-)
-```
-
-## 4. Pós-output
-
-```
-═══════════════════════════════════════════════════════════
- framework ► CRIAR-WORKFLOW ▸ <slug>
-═══════════════════════════════════════════════════════════
-
-[output do workflow-generator]
-
-## Como usar
-
-```
-/<slug> [--args ...]                       # 1 execucao
-/loop 3m /<slug> [--args ...]              # a cada 3min (dentro da sessao)
-/schedule "*/3 * * * *" <slug> [--args]    # cron remoto (24/7)
-```
-
-## Editar depois
-
-Se quiser ajustar:
-- `.claude/workflows/<slug>.workflow.js` — script do workflow
-- `.claude/commands/<slug>.md` — slash-command (interface + flags)
-
-A tool Workflow do Claude Code re-le o script a cada execucao — edit ja vale na proxima rodada.
-
-## Quando descontinuar
-
-Apaga os 2 arquivos. Sem efeito colateral (workflows user-generated nao entram no kit/file-manifest.json nem no kit-mcp sync).
-```
-
-</process>
-
-<success_criteria>
-- [ ] `$ARGUMENTS` validado (≥ 10 chars)
-- [ ] `.claude/workflows/` e `.claude/commands/` criados se ausentes
-- [ ] `workflow-generator` invocado via `Task()` com a descrição original
-- [ ] Layer 0 (classify pattern) com `AskUserQuestion` obrigatório — NUNCA infere
-- [ ] Layer 1 (specify) com perguntas específicas DO PADRÃO ESCOLHIDO — não pergunta tudo sempre
-- [ ] Layer 2 (compose) propõe reuso de agents canônicos quando match óbvio
-- [ ] Layer 3 (materialize) escreve 2 arquivos com headers corretos
-- [ ] Layer 4 (deliver) output com `/<slug>`, `/loop`, `/schedule` formatados
-- [ ] Workflow gerado parseável (`node -c` syntax check)
-- [ ] Nenhum arquivo escrito em `kit/` (canônico) — só em `.claude/`
-</success_criteria>
+---
+name: criar-workflow
+description: Gera um Dynamic Workflow customizado pro teu projeto. Pergunta o padrao de harness (6 opcoes), eliciaa params especificos, compoe reusando agents/skills do kit, materializa em .claude/workflows/.
+argument-hint: "<descricao livre em portugues do que voce quer auditar/automatizar>"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+  - AskUserQuestion
+  - Task
+---
+
+# criar-workflow
+
+> Entrypoint pra gerar um Dynamic Workflow customizado pro teu projeto. O kit não cresce com workflows de nicho — cresce com a capacidade de gerar workflows sob demanda.
+
+> Cada usuário ganha o DELE, calibrado pro stack/dor que ele tem. Outro usuário com necessidade diferente roda `/criar-workflow <sua descrição>` e ganha um diferente.
+
+<objective>
+Invoca o agent [`workflow-generator`](../agents/workflow-generator.md) que executa 4 layers:
+
+1. **Classify** — pergunta qual dos 6 patterns canônicos (Classify-Act, Fanout-Synthesize, Adversarial-Verify, Generate-Filter, Tournament, Loop-Done) encaixa
+2. **Specify** — faz 2-4 perguntas específicas do pattern escolhido
+3. **Compose** — detecta MCP necessárias + propõe reuso de agents canônicos do kit
+4. **Materialize** — escreve `.claude/workflows/<slug>.workflow.js` + `.claude/commands/<slug>.md` (locais ao projeto, NUNCA no kit canônico)
+
+**Cria:**
+- `.claude/workflows/<slug>.workflow.js` — script JS executável pela tool Workflow do Claude Code
+- `.claude/commands/<slug>.md` — slash-command que dispara o workflow
+
+**Após:** `/<slug> [--args]` invoca direto. Pra rodar a cada N minutos: `/loop 3m /<slug>`. Pra cron remoto: `/schedule "*/3 * * * *" <slug>`.
+</objective>
+
+<context>
+**Argumento:**
+- `$ARGUMENTS` — descrição livre em português do objetivo. Quanto mais específico, menos perguntas o gerador faz no Layer 1.
+
+**Exemplos:**
+```
+/criar-workflow auditar comportamento dos agentes IA atendendo WhatsApp 
+                a cada 3 minutos, analisar transcripts e gerar report
+
+/criar-workflow rankear top 10 PRs no GitHub abertos ha mais de 7 dias 
+                sem revisao por impacto
+
+/criar-workflow bug hunt continuo no codigo do servico de pagamento 
+                ate 2 rounds sem novos achados
+
+/criar-workflow brainstorm 12 nomes pra minha CLI e pegar top 3 por 
+                memorability + brand fit
+```
+
+**Pré-requisitos:**
+- Claude Code Max / Team / Enterprise (Dynamic Workflows em research preview Opus 4.8+)
+- Tool `Workflow` habilitada na sessão
+- `.claude/workflows/` existe ou sera criado
+
+**Quando NÃO usar:**
+- Tarefa cabe em 1 slash-command existente (ex.: ja temos `/auditar-observabilidade-cobertura-workflow` — não duplique)
+- Descrição vaga ("automatize meu projeto") — refine antes
+- Mudança que precisa entrar no kit canônico — esses são PRs no repo `luanpdd/kit-mcp`, não workflows locais
+</context>
+
+<process>
+
+## 1. Validar descrição mínima
+
+```bash
+DESC="$ARGUMENTS"
+if [ -z "$DESC" ] || [ ${#DESC} -lt 10 ]; then
+  echo "ERRO: descreva o que voce quer com pelo menos 10 chars."
+  echo "Exemplo: /criar-workflow auditar conversas IA no WhatsApp a cada 3min"
+  exit 1
+fi
+```
+
+## 2. Garantir destino existe
+
+```bash
+mkdir -p .claude/workflows .claude/commands
+```
+
+## 3. Dispatch para workflow-generator
+
+```text
+Task(
+  subagent_type="workflow-generator",
+  prompt="
+description: ${DESC}
+output_dir_workflows: .claude/workflows/
+output_dir_commands: .claude/commands/
+
+Execute os 4 layers conforme spec do agent:
+
+LAYER 0 — Classify (AskUserQuestion obrigatorio, 6 opcoes do pattern)
+LAYER 1 — Specify (perguntas especificas do pattern escolhido, 2-4 max)
+LAYER 2 — Compose (detectar MCP + propor reuso de agents do kit via AskUserQuestion)
+LAYER 3 — Materialize (.workflow.js + .md com header // kit-mcp:user-generated)
+LAYER 4 — Deliver (output formatado com slug, pattern, MCP, comandos /<slug>, /loop, /schedule)
+
+REGRAS DURAS:
+- meta literal puro (sem template literals, sem function calls, sem spread)
+- Todo agent() com schema JSON Schema declarado (required: [...])
+- pipeline() default, parallel() so com justificativa inline
+- Sem Date.now()/Math.random()/argless new Date() — pra randomness varie por indice, pra timestamps passe via args
+- Header // kit-mcp:user-generated no topo do .workflow.js (distingue de // kit-mcp:reference do canonico)
+
+NAO escreva em kit/ — workflows gerados sao locais.
+"
+)
+```
+
+## 4. Pós-output
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► CRIAR-WORKFLOW ▸ <slug>
+═══════════════════════════════════════════════════════════
+
+[output do workflow-generator]
+
+## Como usar
+
+```
+/<slug> [--args ...]                       # 1 execucao
+/loop 3m /<slug> [--args ...]              # a cada 3min (dentro da sessao)
+/schedule "*/3 * * * *" <slug> [--args]    # cron remoto (24/7)
+```
+
+## Editar depois
+
+Se quiser ajustar:
+- `.claude/workflows/<slug>.workflow.js` — script do workflow
+- `.claude/commands/<slug>.md` — slash-command (interface + flags)
+
+A tool Workflow do Claude Code re-le o script a cada execucao — edit ja vale na proxima rodada.
+
+## Quando descontinuar
+
+Apaga os 2 arquivos. Sem efeito colateral (workflows user-generated nao entram no kit/file-manifest.json nem no kit-mcp sync).
+```
+
+</process>
+
+<success_criteria>
+- [ ] `$ARGUMENTS` validado (≥ 10 chars)
+- [ ] `.claude/workflows/` e `.claude/commands/` criados se ausentes
+- [ ] `workflow-generator` invocado via `Task()` com a descrição original
+- [ ] Layer 0 (classify pattern) com `AskUserQuestion` obrigatório — NUNCA infere
+- [ ] Layer 1 (specify) com perguntas específicas DO PADRÃO ESCOLHIDO — não pergunta tudo sempre
+- [ ] Layer 2 (compose) propõe reuso de agents canônicos quando match óbvio
+- [ ] Layer 3 (materialize) escreve 2 arquivos com headers corretos
+- [ ] Layer 4 (deliver) output com `/<slug>`, `/loop`, `/schedule` formatados
+- [ ] Workflow gerado parseável (`node -c` syntax check)
+- [ ] Nenhum arquivo escrito em `kit/` (canônico) — só em `.claude/`
+</success_criteria>

package/kit/commands/definir-perfil.md

@@ -1,7 +1,7 @@
 ---
 name: definir-perfil
 description: Altera o perfil de modelo para os agentes framework (quality/balanced/budget/inherit)
-argument-hint: "<perfil (quality|balanced|budget|inherit)>"
+argument-hint: "<perfil (quality|balanced|budget|inherit)>"
 model: haiku
 allowed-tools:
   - Bash

package/kit/commands/definir-slo.md

@@ -1,108 +1,108 @@
----
-name: definir-slo
-description: Invoca slo-engineer para gerar SLO.md + SQL materialização SLI events. Aplica skill event-based-slos. Default 30d sliding window, target ≤ 99.95%.
-argument-hint: "<feature> [--target 99.9] [--owner email]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Task
-  - AskUserQuestion
----
-
-<objective>
-Definir um SLO event-based para uma feature/jornada do usuário. Invoca o agente [`slo-engineer`](../agents/slo-engineer.md) que aplica a skill [`event-based-slos`](../skills/event-based-slos/SKILL.md) — SLI event-based, sliding window 30d, target ≤ 99.95%, owner nomeado, materialização em Postgres.
-
-**Cria/Atualiza:**
-- `.planning/slos/<slo_name>.md` — definição canônica do SLO
-- `supabase/migrations/<timestamp>_create_sli_<slo_name>.sql` — view materializada SLI
-
-**Após:** SLO está em `draft` status. Próximo passo: `/burn-rate-status <slo_name>` para validar baseline; após 1+ semana, promover de `draft` → `test_channel` → `primary`.
-</objective>
-
-<context>
-**Argumentos:** `$ARGUMENTS` — primeiro token é a feature/jornada (ex: `checkout`, `login`, `bulk-orders`); restante são flags.
-
-**Flags:**
-- `--target <percent>` — target % do SLO (default: agent sugere baseado em criticality, sempre ≤ 99.95%)
-- `--owner <email>` — owner do SLO (default: AskUserQuestion)
-- `--window <duration>` — sliding window (default: `30d`)
-
-**Pré-requisito (Full mode):** projeto Supabase configurado, schema `observability` com tabela de events (Phase 31 supabase-architect projeta isso).
-</context>
-
-<process>
-
-## 1. Parsear argumentos
-
-```bash
-FEATURE=$(echo "$ARGUMENTS" | awk '{print $1}')
-TARGET=$(echo "$ARGUMENTS" | grep -oE -- '--target [0-9.]+' | awk '{print $2}')
-OWNER=$(echo "$ARGUMENTS" | grep -oE -- '--owner [^ ]+' | awk '{print $2}')
-WINDOW=$(echo "$ARGUMENTS" | grep -oE -- '--window [^ ]+' | awk '{print $2}')
-
-[ -z "$FEATURE" ] && {
-  echo "Uso: /definir-slo <feature> [--target N] [--owner email]"
-  exit 1
-}
-
-[ -z "$WINDOW" ] && WINDOW="30d"
-```
-
-## 2. Detectar `supabase/config.toml`
-
-```bash
-PROJECT_ID=""
-if [ -f supabase/config.toml ]; then
-  PROJECT_ID=$(grep -E '^project_id\s*=' supabase/config.toml | sed 's/.*= *"\(.*\)".*/\1/' | head -1)
-fi
-```
-
-## 3. Dispatch para `slo-engineer`
-
-```text
-Task(
-  subagent_type="slo-engineer",
-  prompt="
-feature: ${FEATURE}
-${TARGET:+target: ${TARGET}}
-${OWNER:+owner: ${OWNER}}
-window: ${WINDOW}
-${PROJECT_ID:+project_id: ${PROJECT_ID}}
-
-Aplicar skill event-based-slos. Gerar:
-1. .planning/slos/<slo_name>.md (SLO definition canônico)
-2. supabase/migrations/<timestamp>_create_sli_<slo_name>.sql (materialized view + pg_cron refresh)
-
-Se target > 99.95%, recusar e explicar — métrica informativa, não SLO.
-Se Full mode (mcp__supabase disponível), apply_migration; senão, output text.
-"
-)
-```
-
-## 4. Pós-output
-
-```
-═══════════════════════════════════════════════════════════
- framework ► DEFINIR-SLO ▸ {slo_name}
-═══════════════════════════════════════════════════════════
-
-[output do slo-engineer — ver Step 8 do agent]
-
-## Próximos passos
-1. `/burn-rate-status {slo_name}` — checar baseline atual
-2. Após 1+ semana validando que SLO detecta incidents reais:
-   - Editar `.planning/slos/{slo_name}.md` → status: `test_channel` → `primary`
-3. Configurar alerts (page + ticket) — invocar `burn-rate-forecaster` ou config manual
-```
-
-</process>
-
-<success_criteria>
-- [ ] FEATURE parseado de $ARGUMENTS
-- [ ] `slo-engineer` invocado via Task
-- [ ] `.planning/slos/<slo_name>.md` criado
-- [ ] Migration SQL criada (Full mode applied; Offline mode escrita)
-- [ ] Target ≤ 99.95% enforced
-- [ ] Owner registrado (via flag ou AskUserQuestion)
-</success_criteria>
+---
+name: definir-slo
+description: Invoca slo-engineer para gerar SLO.md + SQL materialização SLI events. Aplica skill event-based-slos. Default 30d sliding window, target ≤ 99.95%.
+argument-hint: "<feature> [--target 99.9] [--owner email]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Task
+  - AskUserQuestion
+---
+
+<objective>
+Definir um SLO event-based para uma feature/jornada do usuário. Invoca o agente [`slo-engineer`](../agents/slo-engineer.md) que aplica a skill [`event-based-slos`](../skills/event-based-slos/SKILL.md) — SLI event-based, sliding window 30d, target ≤ 99.95%, owner nomeado, materialização em Postgres.
+
+**Cria/Atualiza:**
+- `.planning/slos/<slo_name>.md` — definição canônica do SLO
+- `supabase/migrations/<timestamp>_create_sli_<slo_name>.sql` — view materializada SLI
+
+**Após:** SLO está em `draft` status. Próximo passo: `/burn-rate-status <slo_name>` para validar baseline; após 1+ semana, promover de `draft` → `test_channel` → `primary`.
+</objective>
+
+<context>
+**Argumentos:** `$ARGUMENTS` — primeiro token é a feature/jornada (ex: `checkout`, `login`, `bulk-orders`); restante são flags.
+
+**Flags:**
+- `--target <percent>` — target % do SLO (default: agent sugere baseado em criticality, sempre ≤ 99.95%)
+- `--owner <email>` — owner do SLO (default: AskUserQuestion)
+- `--window <duration>` — sliding window (default: `30d`)
+
+**Pré-requisito (Full mode):** projeto Supabase configurado, schema `observability` com tabela de events (Phase 31 supabase-architect projeta isso).
+</context>
+
+<process>
+
+## 1. Parsear argumentos
+
+```bash
+FEATURE=$(echo "$ARGUMENTS" | awk '{print $1}')
+TARGET=$(echo "$ARGUMENTS" | grep -oE -- '--target [0-9.]+' | awk '{print $2}')
+OWNER=$(echo "$ARGUMENTS" | grep -oE -- '--owner [^ ]+' | awk '{print $2}')
+WINDOW=$(echo "$ARGUMENTS" | grep -oE -- '--window [^ ]+' | awk '{print $2}')
+
+[ -z "$FEATURE" ] && {
+  echo "Uso: /definir-slo <feature> [--target N] [--owner email]"
+  exit 1
+}
+
+[ -z "$WINDOW" ] && WINDOW="30d"
+```
+
+## 2. Detectar `supabase/config.toml`
+
+```bash
+PROJECT_ID=""
+if [ -f supabase/config.toml ]; then
+  PROJECT_ID=$(grep -E '^project_id\s*=' supabase/config.toml | sed 's/.*= *"\(.*\)".*/\1/' | head -1)
+fi
+```
+
+## 3. Dispatch para `slo-engineer`
+
+```text
+Task(
+  subagent_type="slo-engineer",
+  prompt="
+feature: ${FEATURE}
+${TARGET:+target: ${TARGET}}
+${OWNER:+owner: ${OWNER}}
+window: ${WINDOW}
+${PROJECT_ID:+project_id: ${PROJECT_ID}}
+
+Aplicar skill event-based-slos. Gerar:
+1. .planning/slos/<slo_name>.md (SLO definition canônico)
+2. supabase/migrations/<timestamp>_create_sli_<slo_name>.sql (materialized view + pg_cron refresh)
+
+Se target > 99.95%, recusar e explicar — métrica informativa, não SLO.
+Se Full mode (mcp__supabase disponível), apply_migration; senão, output text.
+"
+)
+```
+
+## 4. Pós-output
+
+```
+═══════════════════════════════════════════════════════════
+ framework ► DEFINIR-SLO ▸ {slo_name}
+═══════════════════════════════════════════════════════════
+
+[output do slo-engineer — ver Step 8 do agent]
+
+## Próximos passos
+1. `/burn-rate-status {slo_name}` — checar baseline atual
+2. Após 1+ semana validando que SLO detecta incidents reais:
+   - Editar `.planning/slos/{slo_name}.md` → status: `test_channel` → `primary`
+3. Configurar alerts (page + ticket) — invocar `burn-rate-forecaster` ou config manual
+```
+
+</process>
+
+<success_criteria>
+- [ ] FEATURE parseado de $ARGUMENTS
+- [ ] `slo-engineer` invocado via Task
+- [ ] `.planning/slos/<slo_name>.md` criado
+- [ ] Migration SQL criada (Full mode applied; Offline mode escrita)
+- [ ] Target ≤ 99.95% enforced
+- [ ] Owner registrado (via flag ou AskUserQuestion)
+</success_criteria>

package/kit/commands/fio.md

@@ -1,7 +1,7 @@
 ---
 name: fio
 description: Gerencia threads de contexto persistentes para trabalho entre sessões
-argument-hint: "[nome | descrição]"
+argument-hint: "[nome | descrição]"
 allowed-tools:
   - Read
   - Write