@luanpdd/kit-mcp 1.21.0 → 1.26.0

package/kit/commands/revisar-backlog.md

@@ -1,60 +1,60 @@
----
-name: revisar-backlog
-description: Revisa e promove itens do backlog para o milestone ativo
-allowed-tools:
-  - Read
-  - Write
-  - Bash
----
-
-<objective>
-Revisar todos os itens de backlog 999.x e opcionalmente promovê-los para a sequência do milestone ativo ou remover entradas obsoletas.
-</objective>
-
-<process>
-
-1. **Listar itens do backlog:**
-   ```bash
-   ls -d .planning/phases/999* 2>/dev/null || echo "Nenhum item de backlog encontrado"
-   ```
-
-2. **Ler ROADMAP.md** e extrair todas as entradas de fase 999.x:
-   ```bash
-   cat .planning/ROADMAP.md
-   ```
-   Mostrar cada item do backlog com sua descrição, qualquer contexto acumulado (CONTEXT.md, RESEARCH.md) e data de criação.
-
-3. **Apresentar a lista ao usuário** via AskUserQuestion:
-   - Para cada item do backlog, mostrar: número da fase, descrição, artefatos acumulados
-   - Opções por item: **Promover** (mover para ativo), **Manter** (deixar no backlog), **Remover** (deletar)
-
-4. **Para itens a PROMOVER:**
-   - Encontrar o próximo número de fase sequencial no milestone ativo
-   - Renomear o diretório de `999.x-slug` para `{novo_num}-slug`:
-     ```bash
-     NEW_NUM=$(node "./.claude/framework/bin/tools.cjs" phase add "${DESCRIPTION}" --raw)
-     ```
-   - Mover artefatos acumulados para o novo diretório de fase
-   - Atualizar ROADMAP.md: mover entrada da seção `## Backlog` para a lista de fases ativas
-   - Remover marcador `(BACKLOG)`
-   - Adicionar campo `**Depends on:**` apropriado
-
-5. **Para itens a REMOVER:**
-   - Deletar o diretório da fase
-   - Remover a entrada da seção `## Backlog` do ROADMAP.md
-
-6. **Commitar alterações:**
-   ```bash
-   node "./.claude/framework/bin/tools.cjs" commit "docs: revisar backlog — promovidos N, removidos M" --files .planning/ROADMAP.md
-   ```
-
-7. **Relatório resumo:**
-   ```
-   ## Revisão de Backlog Concluída
-
-   Promovidos: {lista de itens promovidos com novos números de fase}
-   Mantidos: {lista de itens que permanecem no backlog}
-   Removidos: {lista de itens deletados}
-   ```
-
-</process>
+---
+name: revisar-backlog
+description: Revisa e promove itens do backlog para o milestone ativo
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+---
+
+<objective>
+Revisar todos os itens de backlog 999.x e opcionalmente promovê-los para a sequência do milestone ativo ou remover entradas obsoletas.
+</objective>
+
+<process>
+
+1. **Listar itens do backlog:**
+   ```bash
+   ls -d .planning/phases/999* 2>/dev/null || echo "Nenhum item de backlog encontrado"
+   ```
+
+2. **Ler ROADMAP.md** e extrair todas as entradas de fase 999.x:
+   ```bash
+   cat .planning/ROADMAP.md
+   ```
+   Mostrar cada item do backlog com sua descrição, qualquer contexto acumulado (CONTEXT.md, RESEARCH.md) e data de criação.
+
+3. **Apresentar a lista ao usuário** via AskUserQuestion:
+   - Para cada item do backlog, mostrar: número da fase, descrição, artefatos acumulados
+   - Opções por item: **Promover** (mover para ativo), **Manter** (deixar no backlog), **Remover** (deletar)
+
+4. **Para itens a PROMOVER:**
+   - Encontrar o próximo número de fase sequencial no milestone ativo
+   - Renomear o diretório de `999.x-slug` para `{novo_num}-slug`:
+     ```bash
+     NEW_NUM=$(node "./.claude/framework/bin/tools.cjs" phase add "${DESCRIPTION}" --raw)
+     ```
+   - Mover artefatos acumulados para o novo diretório de fase
+   - Atualizar ROADMAP.md: mover entrada da seção `## Backlog` para a lista de fases ativas
+   - Remover marcador `(BACKLOG)`
+   - Adicionar campo `**Depends on:**` apropriado
+
+5. **Para itens a REMOVER:**
+   - Deletar o diretório da fase
+   - Remover a entrada da seção `## Backlog` do ROADMAP.md
+
+6. **Commitar alterações:**
+   ```bash
+   node "./.claude/framework/bin/tools.cjs" commit "docs: revisar backlog — promovidos N, removidos M" --files .planning/ROADMAP.md
+   ```
+
+7. **Relatório resumo:**
+   ```
+   ## Revisão de Backlog Concluída
+
+   Promovidos: {lista de itens promovidos com novos números de fase}
+   Mantidos: {lista de itens que permanecem no backlog}
+   Removidos: {lista de itens deletados}
+   ```
+
+</process>

package/kit/commands/revisar-ui.md

@@ -1,32 +1,32 @@
----
-name: revisar-ui
-description: Auditoria visual retroativa de 6 pilares do código frontend implementado
-argument-hint: "[fase]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Glob
-  - Grep
-  - Task
-  - AskUserQuestion
----
-<objective>
-Realiza uma auditoria visual retroativa de 6 pilares. Produz UI-REVIEW.md com
-avaliação graduada (1-4 por pilar). Funciona em qualquer projeto.
-Saída: {phase_num}-UI-REVIEW.md
-</objective>
-
-<execution_context>
-@./.claude/framework/workflows/ui-review.md
-@./.claude/framework/references/ui-brand.md
-</execution_context>
-
-<context>
-Fase: $ARGUMENTS — opcional, padrão é a última fase concluída.
-</context>
-
-<process>
-Execute @./.claude/framework/workflows/ui-review.md do início ao fim.
-Preserve todos os gates do workflow.
-</process>
+---
+name: revisar-ui
+description: Auditoria visual retroativa de 6 pilares do código frontend implementado
+argument-hint: "[fase]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+  - Task
+  - AskUserQuestion
+---
+<objective>
+Realiza uma auditoria visual retroativa de 6 pilares. Produz UI-REVIEW.md com
+avaliação graduada (1-4 por pilar). Funciona em qualquer projeto.
+Saída: {phase_num}-UI-REVIEW.md
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/ui-review.md
+@./.claude/framework/references/ui-brand.md
+</execution_context>
+
+<context>
+Fase: $ARGUMENTS — opcional, padrão é a última fase concluída.
+</context>
+
+<process>
+Execute @./.claude/framework/workflows/ui-review.md do início ao fim.
+Preserve todos os gates do workflow.
+</process>

package/kit/commands/revisar.md

@@ -1,37 +1,37 @@
----
-name: revisar
-description: Solicita revisão entre IAs de planos de fase a partir de CLIs externas
-argument-hint: "--phase N [--gemini] [--claude] [--codex] [--all]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Glob
-  - Grep
----
-
-<objective>
-Invoca CLIs externas de IA (Gemini, Claude, Codex) para revisar planos de fase de forma independente.
-Produz um REVIEWS.md estruturado com feedback por revisor que pode ser incorporado de volta ao
-planejamento via /planejar-fase --reviews.
-
-**Fluxo:** Detectar CLIs → Construir prompt de revisão → Invocar cada CLI → Coletar respostas → Escrever REVIEWS.md
-</objective>
-
-<execution_context>
-@./.claude/framework/workflows/review.md
-</execution_context>
-
-<context>
-Número da fase: extraído de $ARGUMENTS (obrigatório)
-
-**Flags:**
-- `--gemini` — Incluir revisão do Gemini CLI
-- `--claude` — Incluir revisão do Claude CLI (usa sessão separada)
-- `--codex` — Incluir revisão do Codex CLI
-- `--all` — Incluir todos os CLIs disponíveis
-</context>
-
-<process>
-Execute o workflow review de @./.claude/framework/workflows/review.md do início ao fim.
-</process>
+---
+name: revisar
+description: Solicita revisão entre IAs de planos de fase a partir de CLIs externas
+argument-hint: "--phase N [--gemini] [--claude] [--codex] [--all]"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Grep
+---
+
+<objective>
+Invoca CLIs externas de IA (Gemini, Claude, Codex) para revisar planos de fase de forma independente.
+Produz um REVIEWS.md estruturado com feedback por revisor que pode ser incorporado de volta ao
+planejamento via /planejar-fase --reviews.
+
+**Fluxo:** Detectar CLIs → Construir prompt de revisão → Invocar cada CLI → Coletar respostas → Escrever REVIEWS.md
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/review.md
+</execution_context>
+
+<context>
+Número da fase: extraído de $ARGUMENTS (obrigatório)
+
+**Flags:**
+- `--gemini` — Incluir revisão do Gemini CLI
+- `--claude` — Incluir revisão do Claude CLI (usa sessão separada)
+- `--codex` — Incluir revisão do Codex CLI
+- `--all` — Incluir todos os CLIs disponíveis
+</context>
+
+<process>
+Execute o workflow review de @./.claude/framework/workflows/review.md do início ao fim.
+</process>

package/kit/commands/saude.md

@@ -1,22 +1,22 @@
----
-name: saude
-description: Diagnostica a integridade do diretório de planejamento e opcionalmente repara problemas
-argument-hint: [--repair]
-allowed-tools:
-  - Read
-  - Bash
-  - Write
-  - AskUserQuestion
----
-<objective>
-Validar a integridade do diretório `.planning/` e reportar problemas acionáveis. Verifica arquivos ausentes, configurações inválidas, estado inconsistente e planos órfãos.
-</objective>
-
-<execution_context>
-@./.claude/framework/workflows/health.md
-</execution_context>
-
-<process>
-Execute o workflow health de @./.claude/framework/workflows/health.md do início ao fim.
-Analisar a flag --repair dos argumentos e passar para o workflow.
+---
+name: saude
+description: Diagnostica a integridade do diretório de planejamento e opcionalmente repara problemas
+argument-hint: [--repair]
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - AskUserQuestion
+---
+<objective>
+Validar a integridade do diretório `.planning/` e reportar problemas acionáveis. Verifica arquivos ausentes, configurações inválidas, estado inconsistente e planos órfãos.
+</objective>
+
+<execution_context>
+@./.claude/framework/workflows/health.md
+</execution_context>
+
+<process>
+Execute o workflow health de @./.claude/framework/workflows/health.md do início ao fim.
+Analisar a flag --repair dos argumentos e passar para o workflow.
 </process>

package/kit/commands/setup-notion.md

@@ -1,93 +1,93 @@
-# /setup-notion — Inicializar Documentação Notion para um Projeto
-
-Cria a estrutura de páginas Notion para um novo projeto sob a página raiz do seu workspace e gera o `.claude/notion-config.json` local.
-
-## Quando usar
-
-Ao iniciar um novo projeto framework que ainda não tem página no Notion.
-Execute uma vez por projeto — depois use `/publicar` normalmente.
-
-## Processo
-
-### Passo 1 — Ler contexto do projeto
-
-Leia `.planning/PROJECT.md` para obter:
-- Nome do projeto
-- Stack
-- Descrição em 1 frase
-
-### Passo 2 — Criar páginas no Notion
-
-Use o Notion MCP (`notion-create-pages`) com `parent.page_id = "{NOTION_PARENT_PAGE_ID}"`, onde `NOTION_PARENT_PAGE_ID` é o ID da página raiz do seu workspace de documentação (configure via env var `KIT_NOTION_PARENT_PAGE_ID` ou substitua diretamente).
-
-Crie a página raiz do projeto com ícone 📋 e este conteúdo:
-
-```
-[Callout azul] {NOME_PROJETO} — {DESCRICAO_1_FRASE}
-
----
-
-## Stack
-[Tabela com camadas e tecnologias do PROJECT.md]
-
----
-
-## Estrutura da Documentação
-- changelog/ — Uma entrada por milestone
-- features/ — O que cada feature faz
-- adr/ — Decisões arquiteturais
-- runbooks/ — Procedimentos operacionais
-
----
-
-## Versões Lançadas
-[Tabela vazia: Versão | Nome | Data | Status]
-```
-
-Depois crie as 4 subpáginas sob a página raiz criada:
-- 📅 `changelog/` — com tabela de índice vazia
-- 📄 `features/` — com tabela de índice vazia
-- 🏛️ `adr/` — com tabela de índice vazia
-- 📖 `runbooks/` — com tabela de índice vazia
-
-### Passo 3 — Gerar notion-config.json
-
-Com os IDs retornados pelo Notion MCP, crie `.claude/notion-config.json`:
-
-```json
-{
-  "project": "{NOME_PROJETO}",
-  "notion": {
-    "root": "{ID_ROOT}",
-    "root_url": "{URL_ROOT}",
-    "changelog": "{ID_CHANGELOG}",
-    "features": "{ID_FEATURES}",
-    "adr": "{ID_ADR}",
-    "runbooks": "{ID_RUNBOOKS}"
-  }
-}
-```
-
-### Passo 4 — Reportar resultado
-
-```
-✅ Notion configurado para {NOME_PROJETO}
-
-📋 Página principal: {URL_ROOT}
-📅 changelog/: {URL_CHANGELOG}
-📄 features/: {URL_FEATURES}
-🏛️ adr/: {URL_ADR}
-📖 runbooks/: {URL_RUNBOOKS}
-
-Arquivo criado: .claude/notion-config.json
-Próximo passo: use /publicar ao concluir o próximo milestone.
-```
-
-## Configuração da página raiz do Notion
-
-Defina o ID da página raiz onde os projetos serão criados (uma página "guarda-chuva" no seu workspace Notion):
-
-- Via env var: `export KIT_NOTION_PARENT_PAGE_ID="<ID_DA_PAGINA>"`
-- Ou substitua `{NOTION_PARENT_PAGE_ID}` no Passo 2 pelo ID literal antes de executar.
-
-Para obter o ID: abra a página no Notion → Share → Copy link → o ID é o hash de 32 caracteres no final da URL.
+# /setup-notion — Inicializar Documentação Notion para um Projeto
+
+Cria a estrutura de páginas Notion para um novo projeto sob a página raiz do seu workspace e gera o `.claude/notion-config.json` local.
+
+## Quando usar
+
+Ao iniciar um novo projeto framework que ainda não tem página no Notion.
+Execute uma vez por projeto — depois use `/publicar` normalmente.
+
+## Processo
+
+### Passo 1 — Ler contexto do projeto
+
+Leia `.planning/PROJECT.md` para obter:
+- Nome do projeto
+- Stack
+- Descrição em 1 frase
+
+### Passo 2 — Criar páginas no Notion
+
+Use o Notion MCP (`notion-create-pages`) com `parent.page_id = "{NOTION_PARENT_PAGE_ID}"`, onde `NOTION_PARENT_PAGE_ID` é o ID da página raiz do seu workspace de documentação (configure via env var `KIT_NOTION_PARENT_PAGE_ID` ou substitua diretamente).
+
+Crie a página raiz do projeto com ícone 📋 e este conteúdo:
+
+```
+[Callout azul] {NOME_PROJETO} — {DESCRICAO_1_FRASE}
+
+---
+
+## Stack
+[Tabela com camadas e tecnologias do PROJECT.md]
+
+---
+
+## Estrutura da Documentação
+- changelog/ — Uma entrada por milestone
+- features/ — O que cada feature faz
+- adr/ — Decisões arquiteturais
+- runbooks/ — Procedimentos operacionais
+
+---
+
+## Versões Lançadas
+[Tabela vazia: Versão | Nome | Data | Status]
+```
+
+Depois crie as 4 subpáginas sob a página raiz criada:
+- 📅 `changelog/` — com tabela de índice vazia
+- 📄 `features/` — com tabela de índice vazia
+- 🏛️ `adr/` — com tabela de índice vazia
+- 📖 `runbooks/` — com tabela de índice vazia
+
+### Passo 3 — Gerar notion-config.json
+
+Com os IDs retornados pelo Notion MCP, crie `.claude/notion-config.json`:
+
+```json
+{
+  "project": "{NOME_PROJETO}",
+  "notion": {
+    "root": "{ID_ROOT}",
+    "root_url": "{URL_ROOT}",
+    "changelog": "{ID_CHANGELOG}",
+    "features": "{ID_FEATURES}",
+    "adr": "{ID_ADR}",
+    "runbooks": "{ID_RUNBOOKS}"
+  }
+}
+```
+
+### Passo 4 — Reportar resultado
+
+```
+✅ Notion configurado para {NOME_PROJETO}
+
+📋 Página principal: {URL_ROOT}
+📅 changelog/: {URL_CHANGELOG}
+📄 features/: {URL_FEATURES}
+🏛️ adr/: {URL_ADR}
+📖 runbooks/: {URL_RUNBOOKS}
+
+Arquivo criado: .claude/notion-config.json
+Próximo passo: use /publicar ao concluir o próximo milestone.
+```
+
+## Configuração da página raiz do Notion
+
+Defina o ID da página raiz onde os projetos serão criados (uma página "guarda-chuva" no seu workspace Notion):
+
+- Via env var: `export KIT_NOTION_PARENT_PAGE_ID="<ID_DA_PAGINA>"`
+- Ou substitua `{NOTION_PARENT_PAGE_ID}` no Passo 2 pelo ID literal antes de executar.
+
+Para obter o ID: abra a página no Notion → Share → Copy link → o ID é o hash de 32 caracteres no final da URL.

package/kit/commands/supabase.md

@@ -1,6 +1,6 @@
 ---
 name: supabase
-description: Orquestrador da Suíte Supabase — dispatch para agents especializados (arquiteto, migration, rls, edge, realtime, auth, storage, rag, cron, check) com sinônimos PT/EN.
+description: Orquestrador da Suíte Supabase — serviço de materialização (v1.23) que recebe planejamento/draft SQL de qualquer agent ou user e devolve código hardenado pronto. NUNCA bloqueia upstream — handoff cooperativo via Task(). Subcomandos arquiteto, migration, rls, hardener, edge, realtime, auth, storage, rag, cron, check com sinônimos PT/EN.
 argument-hint: "<subcomando> [args...]"
 allowed-tools:
   - Read
@@ -13,11 +13,15 @@ allowed-tools:
 ---
 
 <objective>
-Orquestrador único da Suíte Supabase. Recebe um subcomando e args, faz dispatch via `Task(subagent_type=supabase-...)` para o agent especializado correto. É o **único ponto de chain de agents Supabase** — agents permanecem função pura (anti-pitfall A10 de v1.8).
+Orquestrador único da Suíte Supabase. **Serviço de materialização (v1.23):** recebe planejamento de qualquer agent ou input do user e devolve código hardenado pronto. **NUNCA bloqueia upstream** — agents externos passam draft via `Task()` para receber SQL final hardenado preservando intent.
 
-**Cria/Atualiza:** o que cada agent invocado cria/atualiza (migrations, schemas, functions, etc.).
+Faz dispatch via `Task(subagent_type=supabase-...)` para o agent especializado correto. É o **único ponto de chain de agents Supabase** — agents permanecem função pura (anti-pitfall A10 de v1.8).
 
-**Após:** o usuário tem o output do agent (plano, código, SQL, ou veredito).
+**Princípio canônico v1.23:** Agents não-Supabase pensam/planejam; agents Supabase materializam/hardenam; ninguém descarta upstream.
+
+**Cria/Atualiza:** o que cada agent invocado cria/atualiza (migrations, schemas, functions, etc.) — com RLS auto-injetada no output via handoff cooperativo com `supabase-rls-hardener` em CREATE TABLE.
+
+**Após:** o usuário tem o output do agent (plano, código, SQL hardenado, ou veredito GO/STRENGTHEN/REWRITE).
 </objective>
 
 <execution_context>
@@ -33,8 +37,12 @@ Agents disponíveis: `kit/agents/supabase-*.md` (Phase 26) + `kit/agents/schema-
 | Subcomando | Sinônimos | Agent dispatched |
 |---|---|---|
 | `arquiteto` | `architect`, `arch` | `supabase-architect` |
-| `migration` | `migrar`, `migrate` | `supabase-migration-writer` |
-| `rls` | — | `supabase-rls-writer` |
+| `migration` | `migrar`, `migrate` | `supabase-migration-writer` (v1.23: auto-chain cooperativo com hardener em CREATE TABLE) |
+| `rls` | — | `supabase-rls-writer` (v1.23: GRANTs + IS NOT NULL + views security_invoker) |
+| `hardener` | `harden`, `endurecer` | `supabase-rls-hardener` (v1.23 canonical materializer — recebe draft via Task) |
+| `column` | `coluna`, `col-priv` | `supabase-column-privileges-writer` (v1.24 canonical materializer column-level — recebe spec via Task) |
+| `rbac` | `roles`, `permissions`, `claims` | `supabase-rbac-implementer` (v1.25 canonical materializer Custom Claims & RBAC via Auth Hook — recebe spec via Task) |
+| `role` | `papel`, `roles-pg` | `supabase-roles-implementer` (v1.26 canonical materializer Postgres Roles — recebe spec via Task; system access) |
 | `edge` | `edge-function`, `function`, `funcao` | `supabase-edge-fn-writer` |
 | `realtime` | `tempo-real` | `supabase-realtime-implementer` |
 | `auth` | `autenticacao`, `auth-ssr` | `supabase-auth-bootstrapper` |
@@ -65,8 +73,12 @@ Mapear `SUBCMD` para agent name canônico:
 
 ```
 arquiteto, architect, arch       → supabase-architect
-migration, migrar, migrate       → supabase-migration-writer
-rls                              → supabase-rls-writer
+migration, migrar, migrate       → supabase-migration-writer  (v1.23: auto-chain hardener em CREATE TABLE)
+rls                              → supabase-rls-writer        (v1.23: GRANTs + IS NOT NULL + views security_invoker)
+hardener, harden, endurecer      → supabase-rls-hardener      (v1.23 canonical materializer)
+column, coluna, col-priv         → supabase-column-privileges-writer  (v1.24 canonical materializer column-level — feature AVANÇADA)
+rbac, roles, permissions, claims → supabase-rbac-implementer           (v1.25 canonical materializer Custom Claims & RBAC via Auth Hook)
+role, papel, roles-pg            → supabase-roles-implementer          (v1.26 canonical materializer Postgres Roles — system access only)
 edge, edge-function, function, funcao → supabase-edge-fn-writer
 realtime, tempo-real             → supabase-realtime-implementer
 auth, autenticacao, auth-ssr     → supabase-auth-bootstrapper
@@ -76,6 +88,31 @@ cron, queues, pgmq, background   → supabase-edge-fn-writer (com flag pattern=c
 check, validar, validate         → schema-checker
 ```
 
+### Serviço de materialização (v1.23 — handoff cooperativo)
+
+Quando agents externos (multi-tenant, debugger, planner, executor, audit-log, CRM, etc.) precisam produzir SQL/DDL, devem invocar `/supabase migration "<plano>"` ou `Task(subagent_type=supabase-rls-hardener, prompt=<draft+intent>)` ao invés de gerar SQL próprio. O command NÃO bloqueia — recebe planejamento, devolve código hardenado.
+
+**Pattern de invocação:**
+
+```python
+# de outro agent (ex: multi-tenant-rls-writer)
+result = Task(subagent_type="supabase-rls-hardener", prompt=f"""
+<upstream_intent>
+Source agent: multi-tenant-rls-writer
+Original goal: criar policies hierárquicas org→dept→role para {table_name}
+Constraints: helper functions já existem em schema private
+</upstream_intent>
+
+<draft_sql>
+{draft_policies_sql}
+</draft_sql>
+
+<user_facing_caller>true</user_facing_caller>
+""")
+# result.verdict: GO | STRENGTHEN | REWRITE
+# result.final_sql: SQL hardenado preservando intent
+```
+
 **Se subcomando não resolve:** exibir erro inline com lista de subcomandos válidos. Sair.
 
 ```
@@ -130,6 +167,16 @@ mode: rag-embeddings   (ou cron-pgmq-edge)
 
 **Subcomando `check`:** dispatch para `schema-checker` (existente). O caller deve passar `migration_path` e `project_id` no `$ARGUMENTS` — exemplo: `/supabase check supabase/migrations/20260506_x.sql`.
 
+**Subcomando `migration` (v1.23 — CMD-02):** após `supabase-migration-writer` produzir SQL inicial, o agent **AUTOMATICAMENTE** invoca `supabase-rls-hardener` via `Task()` para validar defense-in-depth em CREATE TABLE. Output final inclui verdict + RLS auto-injetada. Caller NÃO precisa invocar hardener separadamente — é parte do contrato do subcomando.
+
+**Subcomando `hardener` (v1.23 novo):** dispatch direto para `supabase-rls-hardener`. Útil quando caller tem draft SQL pronto e quer apenas validação/hardening sem gerar SQL novo. Aceita input com bloco `<draft_sql>` no `$ARGUMENTS` ou via stdin.
+
+**Subcomando `column` (v1.24 novo):** dispatch direto para `supabase-column-privileges-writer`. Recebe spec de table + colunas sensíveis + roles permitidos e produz REVOKE table-level + GRANT column-level. **Feature AVANÇADA** — apenas para casos com PII compliance (LGPD/GDPR), audit log payload, billing data, tokens raw. Para casos comuns (admin/user roles), prefira dedicated role table pattern (documentado em [`supabase-column-level-security`](../skills/supabase-column-level-security/SKILL.md)). Aceita input com bloco `<sensitive_columns>` e `<allowed_roles>` no `$ARGUMENTS`.
+
+**Subcomando `rbac` (v1.25 novo):** dispatch direto para `supabase-rbac-implementer`. Recebe spec de roles + permissions matrix + multi_tenant flag e materializa setup completo (7 passos canônicos: enum types + user_roles + role_permissions + Custom Access Token Auth Hook + supabase_auth_admin GRANTs + authorize() function + RLS policies template + client jwt-decode snippet). Pattern recomendado v1.25 para RBAC — zero-JOIN em policies via claim no JWT. Caveat JWT freshness (mudanças refletem após token refresh). Aceita input com bloco `<roles>` + `<permissions_matrix>` + `<multi_tenant>` no `$ARGUMENTS`. Cross-ref skill [`supabase-custom-claims-rbac`](../skills/supabase-custom-claims-rbac/SKILL.md).
+
+**Subcomando `role` (v1.26 novo):** dispatch direto para `supabase-roles-implementer`. Recebe spec de custom Postgres roles + hierarchy + GRANT matrix e materializa setup completo (CREATE ROLE com LOGIN PASSWORD opcional + role hierarchy INHERIT/NOINHERIT + GRANT/REVOKE per schema/table/function + password security check). **System access apenas** — para application access (end-users), use `/supabase rbac` (v1.25). Aceita input com bloco `<roles_to_create>` + `<grants>` + `<use_case>` no `$ARGUMENTS`. Cross-ref skill [`supabase-postgres-roles`](../skills/supabase-postgres-roles/SKILL.md).
+
 ## 5. Output
 
 Output do agent é o output do command. Sem post-processing — agent já formata estruturado.