@brunosps00/dev-workflow 0.15.0 → 1.0.1

package/scaffold/pt-br/commands/dw-brainstorm.md

@@ -9,14 +9,36 @@ Você é um facilitador de brainstorming para o workspace atual. Este comando ex
 - NÃO use quando já tiver requisitos claros prontos para um PRD, ou quando precisar implementar código
 
 ## Posição no Pipeline
-**Antecessor:** (ideia do usuário) | **Sucessor:** `/dw-create-prd`
+**Antecessor:** (ideia do usuário) | **Sucessor:** `/dw-plan prd`
 
-## Flags
+## Como este comando funciona (auto-dispatch, não switchboard de flags)
 
-- **(padrão)**: brainstorm normal com 3-7 opções (conservadora, equilibrada, ousada) e trade-offs. Se o produto tem PRDs ou rules, **Product Inventory** é produzido automaticamente e cada opção recebe tag de classificação.
-- **`--onepager`**: ao final do brainstorm, gera um one-pager durável em `.dw/spec/ideas/<slug>.md` (usando `.dw/templates/idea-onepager.md`) com Feature Inventory + Classification & Rationale + MVP Scope + Not Doing + Assumptions. Use quando quiser um artefato de produto persistido antes de seguir para `/dw-create-prd`.
-- **`--council`**: após o brainstorm normal, invoca a skill `dw-council` para stress-test das top 2-3 opções através de 3-5 archetypes (pragmatic-engineer, architect-advisor, security-advocate, product-mind, devils-advocate). Útil quando a escolha é de alto impacto e há genuine dissent entre caminhos.
-- Flags são combináveis: `--onepager --council` produz one-pager após debate do council.
+`/dw-brainstorm` roda **FULL** por padrão. Abre com uma fase de **Signal Reading** que inspeciona o pedido do usuário, o estado do projeto (PRDs, rules, intel, commits recentes) e a conversa até agora, e então **dispara um ou mais modos internos**. O usuário não escolhe o modo — o comando escolhe.
+
+Modos internos (o dispatcher seleciona 1+):
+
+| Modo | Dispara automaticamente quando |
+|------|--------------------------------|
+| **option-matrix** (default sempre ativo) | Surface padrão: 3-7 opções (conservadora / equilibrada / ousada) com tags `[IMPROVES] / [CONSOLIDATES] / [NEW]`. Sempre roda salvo override explícito. |
+| **grill** | Vocabulário está instável — termos do usuário divergem de `.dw/rules/` / `.dw/constitution.md`, ou dois sinônimos competem na mesma conversa, ou alguém propõe um nome que conflita com o glossário. |
+| **prototype** | Usuário pergunta "esse modelo de estado faz sentido?" / "como isso deveria parecer?" sem resposta clara; ou o próximo passo razoável é RODAR código, não escrever palavras. |
+| **council** | Duas ou mais abordagens competem sem vencedor óbvio; ou o consenso se forma rápido demais (sinal de false-consensus). |
+| **research** | A pergunta depende de state-of-the-art externo ("qual é a best practice atual para X", comparações multi-fonte, landscape regulatório ou de framework). |
+| **refactor-audit** | Usuário aponta um diretório ou descreve uma área como "bagunçada", "precisa de limpeza", "tech debt"; ou pede health-check trimestral. |
+| **onepager** | A conversa convergiu o suficiente para merecer um artefato durável (`.dw/spec/ideas/<slug>.md`); ou o usuário sinaliza que vai chamar `/dw-plan prd` em seguida. |
+
+Modos podem encadear numa sessão — grill pode revelar uma pergunta de design que o dispatcher manda para prototype; refactor-audit pode produzir findings que o dispatcher manda para council pra stress-test.
+
+### Overrides opcionais (raramente necessários)
+
+- **`--mode=<nome>`** — força um dispatch específico e pula Signal Reading. Nomes: `option-matrix`, `grill`, `prototype`, `council`, `research`, `refactor-audit`, `onepager`. Combine com `+` para encadear explicitamente: `--mode=grill+onepager`.
+- **`--quiet`** — pula Signal Reading inteiramente e roda apenas `option-matrix` como facilitador mínimo.
+
+Power users que já sabem o que querem podem passar `--mode=`. Todo mundo mais ganha auto-dispatch por padrão — o comando lê a situação e age.
+
+### Nota de migração (transitória)
+
+Invocações antigas com flags (`--onepager`, `--council`, `--research`, `--refactor`, `--grill`, `--prototype`) continuam aceitas por um ciclo minor e mapeiam para o `--mode=` equivalente. Código novo deve usar `--mode=` ou confiar no auto-dispatch.
 
 ## Fluxograma de Decisão: Brainstorm vs PRD Direto
 
@@ -27,7 +49,7 @@ digraph brainstorm_decision {
   Q1 [label="Are requirements\nclear and specific?"];
   Q2 [label="Are there multiple\nviable approaches?"];
   node [shape=box];
-  PRD [label="Go directly to\n/dw-create-prd"];
+  PRD [label="Go directly to\n/dw-plan prd"];
   BS [label="Start with\n/dw-brainstorm"];
   Q1 -> PRD [label="Yes"];
   Q1 -> Q2 [label="No"];
@@ -40,15 +62,16 @@ digraph brainstorm_decision {
 
 Quando disponíveis no projeto em `./.agents/skills/`, use para enriquecer a ideação:
 
-- `dw-council` (opt-in via `--council`): stress-test multi-advisor das opções mais promissoras com steel-manning obrigatório e concession tracking. **NÃO invocar por padrão** — só quando a flag está presente ou quando surge consenso rápido demais (sinal de false consensus).
-- `dw-ui-discipline`: use quando o brainstorm envolver frontend ou direção de UI — o hard-gate (scene sentence, surface job) é forcing function generativa durante ideação, não só check de review
-- `vercel-react-best-practices`: use quando explorar arquitetura React/Next.js ou trade-offs de performance
-- `security-review`: use quando o brainstorm tocar auth, manipulação de dados ou features sensíveis à segurança
+- `dw-council`: invocada pelo modo **council** do dispatcher — stress-test multi-advisor das opções mais promissoras com steel-manning obrigatório e concession tracking. O dispatcher dispara quando 2+ caminhos empatam OU consenso se forma rápido demais (sinal de false-consensus). Não roda em todo brainstorm — só quando os sinais justificam.
+- `dw-simplification`: invocada pelo modo **refactor-audit** — aplica Chesterton's Fence + métricas de complexidade + a nova referência **deep-modules** (deletion test, locality, leverage, interface depth) em todo smell flagueado.
+- `dw-ui-discipline`: use quando o brainstorm envolver frontend ou direção de UI — o hard-gate (scene sentence, surface job) é forcing function generativa durante ideação, não só check de review. Também usado pelo branch UI do modo **prototype**.
+- `vercel-react-best-practices`: use quando explorar arquitetura React/Next.js ou trade-offs de performance.
+- `security-review`: use quando o brainstorm tocar auth, manipulação de dados ou features sensíveis à segurança.
 
 ## Referência do Template
 
 - Template da matriz de brainstorm: `.dw/templates/brainstorm-matrix.md` (relativo ao workspace root)
-- Template do one-pager durável: `.dw/templates/idea-onepager.md` (usado com flag `--onepager`)
+- Template do one-pager durável: `.dw/templates/idea-onepager.md` (usado pelo modo **onepager**)
 
 Use este comando quando o usuario quiser:
 - gerar ideias para produto, UX, arquitetura ou automacao
@@ -61,6 +84,19 @@ Use este comando quando o usuario quiser:
 
 <critical>O brainstorm é fase **nível de produto**, não técnica. NÃO entre em arquitetura, stack, endpoints, schemas. Isso é trabalho do techspec. Aqui trabalhamos jornada do usuário, valor, features e fronteiras.</critical>
 
+### 0. Signal Reading (sempre primeiro, exceto com `--quiet` ou `--mode=` explícito)
+
+Antes de produzir qualquer output, **leia a situação**:
+
+1. Inspecione `.dw/spec/prd-*/`, `.dw/rules/`, `.dw/constitution.md`, `.dw/intel/` se existirem. Anote vocabulário atual e PRDs recentes.
+2. Inspecione git recente (`git log --oneline -20`) pra detectar trabalho em andamento.
+3. Releia o pedido do usuário contra a tabela de Auto-Dispatch no topo desse arquivo. Casa sinais com modos.
+4. Decida o dispatch: **option-matrix** sempre roda salvo override que pule. Outros modos (grill, prototype, council, research, refactor-audit, onepager) disparam **aditivamente** quando seus sinais estão presentes.
+5. Diga ao usuário em uma linha curta qual o dispatch decidido: ex. "Dispatch: option-matrix + onepager (PRD está um passo à frente)" ou "Dispatch: grill (vocabulário instável no PRD atual)". Não esconda — surface antes de rodar.
+6. Depois, execute os modos nessa ordem (quando encadeados): grill → research → option-matrix → council → refactor-audit → prototype → onepager. Pule modos fora do dispatch.
+
+### Fluxo padrão (modo option-matrix)
+
 1. Comece resumindo o problema em 1 a 3 frases.
 2. **Reformule como "How Might We"**: transforme a ideia bruta em `How might we [verbo] para [usuário] de forma que [resultado]?`. Isso tira o time de "solution mode" prematuro.
 3. **Product Inventory (obrigatório se o produto existe)**:
@@ -78,7 +114,7 @@ Use este comando quando o usuario quiser:
    - nível de esforço aproximado
 7. Sempre que fizer sentido, inclua alternativas conservadora, equilibrada e ousada.
 8. Feche com recomendação pragmática e próximos passos claros.
-9. **Se a flag `--onepager` estiver presente**: ao final, gerar `.dw/spec/ideas/<slug>.md` usando `.dw/templates/idea-onepager.md`, preenchendo Feature Inventory, Classification & Rationale, Recommended Direction (linguagem de produto), MVP Scope (user stories), Not Doing, Key Assumptions e Open Questions. Apresentar path ao usuário ao final.
+9. **Se o dispatcher selecionou o modo `onepager`** (auto-dispara quando a conversa converge ou usuário sinaliza que vai pra `/dw-plan prd`): ao final, gerar `.dw/spec/ideas/<slug>.md` usando `.dw/templates/idea-onepager.md`, preenchendo Feature Inventory, Classification & Rationale, Recommended Direction (linguagem de produto), MVP Scope (user stories), Not Doing, Key Assumptions e Open Questions. Apresentar path ao usuário ao final.
 
 ## Formato de resposta preferido
 
@@ -102,16 +138,16 @@ Use este comando quando o usuario quiser:
 - recomende 1 ou 2 caminhos
 - diga por que eles vencem no contexto atual
 
-### 6. One-pager (se `--onepager`)
+### 6. One-pager (se modo `onepager` disparou)
 - path do arquivo criado em `.dw/spec/ideas/<slug>.md`
 
 ### 7. Próximos passos
 - lista curta e executavel
 - se apropriado, sugira qual comando usar em seguida:
-  - `/dw-create-prd` (principal sucessor; aceita one-pager como input reduzindo perguntas de clarificação)
-  - `/dw-run-task` (se é IMPROVES pequeno que cabe em task única com um PRD curto)
-  - `/dw-create-techspec`
-  - `/dw-create-tasks`
+  - `/dw-plan prd` (principal sucessor; aceita one-pager como input reduzindo perguntas de clarificação)
+  - `/dw-run` (se é IMPROVES pequeno que cabe em task única com um PRD curto)
+  - `/dw-plan techspec`
+  - `/dw-plan tasks`
   - `/dw-bugfix`
 
 ## Heuristicas
@@ -139,7 +175,263 @@ Ao final, sempre deixe o usuario em uma destas situacoes:
 - com uma recomendacao clara (incluindo classificação IMPROVES/CONSOLIDATES/NEW)
 - com perguntas melhores para decidir
 - com um proximo comando do workspace para seguir
-- com o one-pager em `.dw/spec/ideas/<slug>.md` (se `--onepager` foi usado)
+- com o one-pager em `.dw/spec/ideas/<slug>.md` (se modo **onepager** disparou)
+- com o relatório de research em `~/Documents/<Tópico>_Research_<data>/` (se modo **research** disparou)
+- com o plano de refactor em `<target>/refactor-plan.md` (se modo **refactor-audit** disparou)
+- com entradas de glossário sharpened em `.dw/rules/` (se modo **grill** disparou)
+- com um protótipo throwaway rodável + template de verdict (se modo **prototype** disparou)
+
+## Modo: research (research multi-fonte)
+
+Dispara quando a pergunta depende de state-of-the-art externo (comparações multi-fonte, framework/regulatory landscape, decisões precisando de evidência citada). Override: `--mode=research`. Substitui o option-matrix padrão por um pipeline estruturado de research que produz documento citado com claims verificados.
+
+<critical>Cada afirmação factual DEVE ser citada imediatamente com [N] na mesma frase</critical>
+<critical>NUNCA fabrique citações — se não encontrar fonte, diga explicitamente</critical>
+<critical>A bibliografia DEVE conter TODAS as citações usadas no corpo, sem abreviações ou ranges</critical>
+
+### Quando usar modo research
+- Comparações multi-fonte (ex: "compare React Server Components vs Astro Islands").
+- State-of-the-art reviews de um tópico.
+- Mapeamento de contexto regulatório ou industrial.
+- Decisões precisando de evidência citada (não opinião).
+- NÃO use research mode pra lookups simples, debugging ou perguntas respondíveis em 1-2 web searches.
+
+### Sub-modos (research depth)
+
+```
+Seleção
+├── Exploração inicial → quick (3 fases, 2-5 min)
+├── Research padrão → standard (6 fases, 5-10 min) [DEFAULT pra research]
+├── Decisão crítica → deep (8 fases, 10-20 min)
+└── Review abrangente → ultradeep (8+ fases, 20-45 min)
+```
+
+### Required reading
+
+Skill complementar **`dw-source-grounding`**: **SEMPRE** — aplica protocolo Detect → Fetch → Implement → Cite com hierarquia estrita (docs oficiais versionados > changelogs > web standards > compat tables; Stack Overflow / blogs / training data são só discovery). Cada finding termina com `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`; bibliografia construída dessas citações.
+
+### Fases do pipeline
+
+**Fase 1 — SCOPE** | Enquadrar a questão. Decompor em componentes. Identificar perspectivas de stakeholders. Definir limites. Listar assumptions a validar.
+
+**Fase 2 — PLAN** | Identificar fontes primárias + secundárias. Mapear dependências de conhecimento. Estratégia de busca com variantes. Plano de triangulação. Quality gates.
+
+**Fase 3 — RETRIEVE** | Coleta paralela. Decompor em 5-10 ângulos independentes (semantic, keyword, date-filtered, academic, alternative perspectives, statistics, industry analysis, critical analysis). Executar TODAS as buscas em paralelo via múltiplas tool calls numa mensagem. First Finish Search: prosseguir quando primeiro threshold atingido (quick: 10+ sources avg credibilidade >60/100; standard: 15+ >60; deep: 25+ >70; ultradeep: 30+ >75).
+
+**Fase 4 — TRIANGULATE** | Identificar claims que requerem verificação. Cross-check em 3+ fontes independentes. Flagar contradições. Documentar status de verificação por claim.
+
+**Fase 5 — REFINAMENTO DO OUTLINE** | Comparar escopo inicial com findings reais. Adaptar estrutura baseada em evidência. Buscas direcionadas pra preencher gaps.
+
+**Fase 6 — SYNTHESIZE** | Identificar patterns cross-source. Mapear relações de conceitos. Gerar insights além do material fonte. Construir hierarquias de evidência.
+
+**Fase 7 — CRITIQUE** (só deep/ultradeep) | Review de consistência lógica. Verificar completude de citações. Identificar gaps ou fraquezas. Simular 2-3 personas críticas.
+
+**Fase 8 — REFINE** (deep/ultradeep) | Fortalecer argumentos fracos. Adicionar perspectivas ausentes. Resolver contradições.
+
+**Fase 9 — PACKAGE** | Gerar relatório progressivamente, seção por seção.
+
+### Output
+
+Salvo em `~/Documents/<Tópico>_Research_<YYYYMMDD>/`. Seções obrigatórias:
+1. Sumário Executivo (200-400 palavras)
+2. Introdução (escopo, metodologia, premissas)
+3. Análise Principal (4-8 achados, 600-2000 palavras cada, todos citados)
+4. Síntese e Insights
+5. Limitações e Ressalvas
+6. Recomendações
+7. Bibliografia (COMPLETA — toda citação, sem placeholders)
+8. Apêndice Metodológico
+
+Tamanhos-alvo: quick 2-4k palavras; standard 4-8k; deep 8-15k; ultradeep 15-20k+.
+
+### Padrões de qualidade
+- Narrativo: prosa fluida, com início/meio/fim. Min 80% prosa, max 20% bullets.
+- Cada afirmação factual citada imediatamente com [N].
+- Distinguir fato de síntese.
+- Sem atribuições vagas ("estudos mostram...", "especialistas acreditam..." sem citação).
+- Rotular especulação explicitamente.
+- Admitir incerteza: "Sem fontes encontradas para X."
+
+## Modo: refactor-audit (catálogo de code smells + deep-modules)
+
+Dispara quando o usuário aponta um diretório ou descreve uma área como "bagunçada" / "precisa de limpeza" / "tech debt", ou pede health-check trimestral. Override: `--mode=refactor-audit`. Audita a área-alvo por oportunidades de refactoring usando a taxonomia de smells de Martin Fowler combinada com a análise deep-modules (deletion test, locality, leverage, interface depth) embutida na skill `dw-simplification`.
+
+<critical>FAÇA EXATAMENTE 3 PERGUNTAS DE CLARIFICAÇÃO ANTES DE INICIAR ANÁLISE</critical>
+
+### Quando usar modo refactor
+- Audit pre-implementação de tech debt na área que vai mexer.
+- Code-health review trimestral.
+- Scoping pre-migration (ex: antes de upgrade de framework).
+- NÃO use refactor mode se `/dw-review` já flagou a mesma área (evita findings duplicados).
+
+### Required reading
+
+Skills complementares:
+- **`dw-review-rigor`**: **SEMPRE** — aplica de-duplication (mesmo smell em N arquivos = 1 entrada com affected list), severity ordering P0-P3, signal-over-volume (max ~20 findings; manter críticos, podar marginais). Smells com ADR justificatório caem para `low` no máximo.
+- **`dw-simplification`**: **SEMPRE** — todo smell flagueado passa pelo filtro Chesterton's Fence (o que o construto FAZ, por que foi adicionado, o que quebra se removido). Smells sem resposta clara para "por que isso está aqui" caem para `info` com nota de investigação. Métricas de complexidade (complexidade cognitiva ≥16 ou nesting depth ≥4 = candidato `high`; <10 = `low` no máximo) ancoram severity.
+- **`security-review`**: delegue preocupações de segurança para este skill — não duplique.
+- **`vercel-react-best-practices`** + seu `perf-discipline.md`: delegue padrões de performance React/Next.js para este skill.
+
+### Pipeline
+
+1. Três perguntas de clarificação (escopo, prioridades, restrições).
+2. Identificar área-alvo (diretório PRD-scoped, módulo específico, ou codebase inteiro).
+3. Scan por smells usando taxonomia Fowler:
+   - **Bloaters** — Long Method, Large Class, Long Parameter List, Data Clumps, Primitive Obsession.
+   - **Object-Orientation Abusers** — Switch Statements, Refused Bequest, Alternative Classes with Different Interfaces, Temporary Field.
+   - **Change Preventers** — Divergent Change, Shotgun Surgery, Parallel Inheritance Hierarchies.
+   - **Dispensables** — Comments, Duplicate Code, Lazy Class, Data Class, Dead Code, Speculative Generality.
+   - **Couplers** — Feature Envy, Inappropriate Intimacy, Message Chains, Middle Man.
+   - **Conditional complexity** — alta cyclomatic/cognitive, nesting profundo.
+4. Aplicar de-duplication `dw-review-rigor` + filtro Chesterton `dw-simplification`.
+5. Pra cada smell sobrevivente, mapear pra técnica de refactoring com sketches before/after.
+6. Severity-order P0-P3 (impacto × likelihood × custo de manutenção).
+7. Mais: coupling/cohesion metrics, análise SOLID.
+
+### Output
+
+Salvo em `<target>/refactor-plan.md`:
+
+```markdown
+# Oportunidades de Refactoring — <target>
+
+## Resumo
+- Smells encontrados: N (após de-dup)
+- P0 (fazer neste sprint): N
+- P1 (este trimestre): N
+- P2 (quando conveniente): N
+- P3 (informacional): N
+
+## Findings (severity-ordered)
+
+### P0 — <smell name>
+**Arquivos:** <lista> (de-duplicados)
+**Sintoma:** <descrição>
+**Por que corrigir:** <análise de impacto>
+**Refactor sugerido:** <técnica Fowler>
+**Before:** <code sketch>
+**After:** <code sketch>
+**Esforço:** S / M / L
+**Risco:** Baixo / Médio / Alto
+**Testes necessários:** <lista>
+
+...
+```
+
+### Ferramentas de análise
+- Projetos React: `npx react-doctor@latest --verbose` pra health score.
+- Projetos Angular: `ng lint` pra issues estáticos.
+
+### Anti-patterns
+- Listar todo hit de complexidade ciclomática > threshold sem contexto → ruído.
+- Sugerir "extract method" em toda função maior que N linhas → mecânico, não insight.
+- Propor refactors sem teste ou não-testáveis → alto risco, não shippa.
+- Ignorar decisões arquiteturais documentadas em `.dw/rules/` → flagar design intencional como smell.
+
+## Modo: grill (domain-grilling)
+
+Dispara quando o vocabulário está instável — termos do usuário divergem de `.dw/rules/` / `.dw/constitution.md`, dois sinônimos competem, ou alguém propõe um nome que conflita com o glossário. Override: `--mode=grill`. Substitui o option-matrix por um **stress-test estilo entrevista** do plan/PRD contra o vocabulário do projeto. Cada rodada sharpens um pedaço. Atualiza `.dw/rules/` (ou `.dw/constitution.md`) inline conforme termos cristalizam — nunca adia pra "depois da conversa".
+
+<critical>Pergunte UMA pergunta de cada vez. Espere a resposta. Não despeje 5 perguntas e torça pelo melhor.</critical>
+
+### Quando usar grill mode
+
+- Antes de `/dw-plan prd` quando o domínio parece instável ou o time usa termos competindo.
+- Depois de `/dw-plan prd` quando reviewers flagam linguagem ambígua no PRD.
+- Durante discussão de arquitetura quando "módulo", "serviço", "componente" são usados de forma intercambiável e precisa fixar o termo canônico.
+- Quando alguém propõe um nome que não combina com o glossário existente do projeto.
+
+### Disciplinas durante a sessão
+
+1. **Desafie contra o glossário.** Leia `.dw/rules/index.md` + `.dw/rules/<modulo>.md` + `.dw/constitution.md`. Flague conflitos de terminologia no instante em que o usuário usa um termo que diverge do que já está documentado.
+
+2. **Sharpen linguagem vaga.** Quando o usuário disser "a coisa do user" ou "aquele lance de pedidos", proponha um termo canônico preciso. Não finja que entendeu — empurre de volta.
+
+3. **Discuta cenários concretos.** Force precisão com edge cases específicos: "O que acontece com a Order no estado X quando o evento Y chega durante o retry Z?" Respostas vagas voltam como mais perguntas.
+
+4. **Cross-reference o código.** Quando o usuário afirmar um comportamento, olhe rápido no codebase pra confirmar. Surface contradições: "Você disse que a API retorna `OrderId` mas `src/api/orders.ts:42` retorna `{ order_id, status }`." Não argumente em generalidades.
+
+5. **Atualize `.dw/rules/` inline.** Quando um termo cristaliza, escreva no arquivo de rules apropriado no mesmo turn da conversa. Lazy file creation: se o arquivo não existir, crie. Formato segue a disciplina de glossário do projeto (ver `.dw/rules/index.md`).
+
+6. **Pule detalhe de implementação no glossário.** `.dw/rules/` e `.dw/constitution.md` descrevem vocabulário e princípios — não implementação. "Order: pedido de um cliente para comprar itens, em um destes estados: pending, paid, shipped, delivered, refunded" é bom. "Order: uma classe TypeScript em `src/orders/`" é vazamento de implementação.
+
+### Disciplina de criação de ADR
+
+Só proponha um ADR via `/dw-adr` quando **todos os três** valem:
+
+| Critério | Teste |
+|----------|-------|
+| **Difícil de reverter** | Se mudarmos em 6 meses, custa >1 semana de trabalho? |
+| **Surpreendente sem contexto** | Um novo contribuinte chegaria razoavelmente a uma decisão diferente? |
+| **Trade-off real** | Havia uma alternativa real considerada e descartada? |
+
+Se algum falta, pule o ADR. Não ADR toda decisão casual — vira ruído na pasta de ADRs.
+
+### Output
+
+O modo grill produz:
+- **`.dw/rules/<modulo>.md` ou `.dw/constitution.md` atualizado** com termos cristalizados.
+- **PRD / TechSpec atualizado** se grill rodou no meio do planejamento (termos alinhados com o glossário).
+- **`.dw/spec/<prd>/adrs/adr-NNN.md` opcional** se os critérios acima valem.
+- **NÃO** produz option matrix ou recomendação (esse é o option-matrix; grill é só sharpening). Se o dispatcher encadeou grill+option-matrix, o option matrix roda em fase separada.
+
+### Quando a disciplina dobra
+
+- **Projeto greenfield sem `.dw/rules/`**: grille mesmo assim; a conversa produz as PRIMEIRAS entradas em `.dw/rules/index.md`. Isso é o valor.
+- **Discordância cosmética de terminologia** ("usamos `userId` ou `user_id`?"): pule grill mode; use ADR de convenção de código ou seção Naming em `.dw/rules/index.md`.
+
+## Modo: prototype (protótipo descartável)
+
+Dispara quando o usuário pergunta "esse modelo de estado faz sentido?" / "como isso deveria parecer?" sem resposta clara — i.e., o próximo passo razoável é RODAR código, não escrever palavras. Override: `--mode=prototype`. Constrói um **protótipo descartável que responde a uma única pergunta**. A pergunta decide a forma — escolha um branch.
+
+<critical>O protótipo é descartável desde o dia um. Não polir. Não adicionar testes. Não extrair abstrações. O ponto é APRENDER algo rápido e depois DELETAR ou absorver.</critical>
+
+### Escolha um branch
+
+| Pergunta do usuário | Branch |
+|---------------------|--------|
+| "Esse modelo de state/logic faz sentido?" | **LOGIC** — terminal app interativo que empurra a máquina de estado por edge cases difíceis de raciocinar no papel. |
+| "Como isso deveria parecer?" | **UI** — várias variações radicalmente diferentes de UI num único route, toggleable por search param e bottom bar flutuante. |
+
+Se a pergunta é ambígua, pergunte ao usuário. Se não puder alcançar: default pelo contexto (módulo backend → LOGIC; página/componente → UI) e declare a suposição no topo do protótipo.
+
+### Regras (valem para os dois branches)
+
+1. **Descartável desde o dia um, claramente marcado.** Coloque o protótipo perto do módulo/página que ele está prototipando (pra contexto) mas nomeie pra que um leitor casual veja que é protótipo (`prototype-<slug>.ts`, `prototype-route.tsx`, etc.).
+
+2. **Um comando pra rodar.** Qualquer que seja o task runner do projeto — `pnpm <nome>`, `python <path>`, `bun <path>`, etc. O usuário tem que rodar sem pensar.
+
+3. **Sem persistência por padrão.** Estado vive em memória. Persistência é o que o protótipo está VERIFICANDO, não algo do qual depende. Se a pergunta envolve banco, use um DB scratch ou arquivo local com nome claro `PROTOTYPE — wipe me`.
+
+4. **Pule o polish.** Sem testes, sem error handling além do mínimo pro protótipo rodar, sem abstrações.
+
+5. **Surface o estado.** Depois de cada ação (LOGIC) ou troca de variante (UI), imprima ou renderize o estado relevante completo pro usuário ver o que mudou.
+
+6. **Delete ou absorva quando terminar.** Quando o protótipo respondeu sua pergunta, ou delete ou dobre a decisão validada em código real. Não deixe apodrecendo no repo.
+
+### Quando terminar
+
+A **resposta** é a única coisa que vale guardar. Capture duravelmente:
+- Commit message fechando o protótipo: "removed prototype X; decided <resposta> based on <observação>"
+- Ou um ADR (se os critérios do grill valem)
+- Ou `.dw/spec/<prd>/NOTES.md` se mid-PRD
+- Ou comentário em issue se user-driven
+
+Se o usuário não está por perto, deixe um placeholder `PROTOTYPE VERDICT: <pending>` pro próximo pass preencher antes da deleção.
+
+### Output
+
+O modo prototype produz:
+- **Arquivo(s) de código descartável** na localização apropriada.
+- Um `NOTES.md` ao lado do protótipo com a PERGUNTA que está respondendo.
+- Depois do usuário rodar e responder a pergunta, instruções pra remover o protótipo + capturar o verdict.
+
+### Anti-patterns
+
+- Construir protótipo que é feature disfarçada — código production-quality, testes, deploy config. Isso não é protótipo; é primeiro draft.
+- Deixar o protótipo no repo "por via das dúvidas" — seis meses depois é load-bearing.
+- Não capturar o verdict — protótipo respondeu a pergunta e a resposta evaporou.
+- Múltiplos protótipos empilhados — escolha uma pergunta, responda, mova.
 
 ## Inspired by
 
@@ -148,8 +440,10 @@ O padrão de codebase-grounded idea refinement é inspirado em [`addyosmani/agen
 - **Nível de produto, não de código**: enquanto `idea-refine` usa Glob/Grep/Read em `src/*`, aqui lemos **PRDs + rules + intel** para mapear o **inventário de features** do produto. O brainstorm continua sendo produtual.
 - **Classificação explícita** (IMPROVES / CONSOLIDATES / NEW) como disciplina dev-workflow-nativa — força o time a decidir se a ideia é feature nova, consolidação ou melhoria de algo existente, antes de abrir um PRD.
 - Output em `.dw/spec/ideas/<slug>.md` (irmão de `prd-<slug>/`) em vez de `docs/ideas/` — mantém a convenção de paths do dev-workflow.
-- Integração com o pipeline existente: `/dw-create-prd` aceita o one-pager como input, reduzindo perguntas de clarificação.
+- Integração com o pipeline existente: `/dw-plan prd` aceita o one-pager como input, reduzindo perguntas de clarificação.
+
+Os modos **grill** e **prototype** são adaptados de [`mattpocock/skills/grill-with-docs`](https://github.com/mattpocock/skills/tree/main/grill-with-docs) e [`mattpocock/skills/prototype`](https://github.com/mattpocock/skills/tree/main/prototype) (Matt Pocock, MIT). Adaptação dev-workflow: integrados como modos INTERNOS auto-dispatchados em vez de skills separadas, paths rebaseados em `.dw/rules/` + `.dw/spec/<prd>/`, criação de ADR gated no teste 3-critérios (difícil de reverter + surpreendente + trade-off real).
 
-Crédito: Addy Osmani e o padrão `idea-refine`.
+Crédito: Addy Osmani (idea-refine) e Matt Pocock (grill-with-docs, prototype).
 
 </system_instructions>

package/scaffold/pt-br/commands/dw-bugfix.md

@@ -5,8 +5,8 @@
 
     ## Quando Usar
     - Use para corrigir um bug reportado com triagem automática para distinguir bug vs feature vs escopo excessivo
-    - NÃO use para implementar uma nova funcionalidade (use `/dw-create-prd` em vez disso)
-    - NÃO use para corrigir bugs encontrados durante testes de QA (use `/dw-fix-qa` em vez disso)
+    - NÃO use para implementar uma nova funcionalidade (use `/dw-plan prd` em vez disso)
+    - NÃO use para corrigir bugs encontrados durante testes de QA (use `/dw-qa --fix` em vez disso)
 
     ## Posição no Pipeline
     **Antecessor:** (bug report) | **Sucessor:** `/dw-commit` e depois `/dw-generate-pr`
@@ -48,9 +48,9 @@
     Neste modo:
     1. Segue o fluxo normal de perguntas e análise
     2. Em vez de executar, gera documento em `.dw/spec/dw-bugfix-[nome]/prd.md`
-    3. O arquivo é nomeado `prd.md` para manter compatibilidade com o pipeline dw-create-techspec/dw-create-tasks
-    4. Depois o usuário pode rodar `/dw-create-techspec .dw/spec/dw-bugfix-[nome]`
-    5. E então `/dw-create-tasks .dw/spec/dw-bugfix-[nome]`
+    3. O arquivo é nomeado `prd.md` para manter compatibilidade com o pipeline dw-create-techspec/dw-plan tasks
+    4. Depois o usuário pode rodar `/dw-plan techspec .dw/spec/dw-bugfix-[nome]`
+    5. E então `/dw-plan tasks .dw/spec/dw-bugfix-[nome]`
 
     ## Fluxo de Trabalho
 
@@ -109,7 +109,7 @@
     ---
 
     **Deseja que eu inicie o fluxo de criação de PRD?**
-    - `sim` - Vou seguir `.dw/commands/dw-create-prd.md` para esta feature
+    - `sim` - Vou seguir `.dw/commands/dw-plan prd.md` para esta feature
     - `não, é bug` - Me explique melhor por que considera um bug
     - `não, cancelar` - Encerrar
     ```
@@ -244,7 +244,7 @@
     3. Salvar como: `.dw/spec/dw-bugfix-[nome-do-bug]/prd.md` (usa nome `prd.md` para compatibilidade com pipeline)
 
     **IMPORTANTE:** O arquivo deve ser nomeado `prd.md` para que os comandos
-    `/dw-create-techspec` e `/dw-create-tasks` funcionem sem modificação.
+    `/dw-plan techspec` e `/dw-plan tasks` funcionem sem modificação.
 
     ## Tipos de Tarefa (permitidos em bugfix)
 
@@ -280,7 +280,7 @@
         q2 [label="Does it require\nnew functionality?", shape=diamond];
         q3 [label="Scope <= 5 files\nand no migration?", shape=diamond];
         bug [label="BUG\n(continue bugfix flow)"];
-        feature [label="FEATURE\n(redirect to /dw-create-prd)"];
+        feature [label="FEATURE\n(redirect to /dw-plan prd)"];
         excessive [label="EXCESSIVE SCOPE\n(redirect to PRD or\nuse --analysis mode)"];
 
         start -> q1;

package/scaffold/pt-br/commands/dw-commit.md

@@ -7,7 +7,7 @@
     - NÃO use para criar uma PR (use `/dw-generate-pr` em vez disso)
 
     ## Posição no Pipeline
-    **Antecessor:** `/dw-run-task` ou `/dw-bugfix` | **Sucessor:** `/dw-generate-pr`
+    **Antecessor:** `/dw-run` ou `/dw-bugfix` | **Sucessor:** `/dw-generate-pr`
 
     ## Skills Complementares
 

package/scaffold/pt-br/commands/dw-dockerize.md

@@ -16,12 +16,12 @@ Este comando e **complementar** ao `/dw-new-project`:
 - Voce quer um `Dockerfile` `--prod` distinto do `--dev`, com multi-stage e usuario nao-root
 - Onboarding de teammate em projeto onde local-dev "so funciona" via `docker compose up`
 - NAO use para scaffold de projeto novo — `/dw-new-project`
-- NAO use para scan de vulnerabilidades em Dockerfile — `/dw-security-check` cobre Trivy IaC
+- NAO use para scan de vulnerabilidades em Dockerfile — `/dw-secure-audit` cobre Trivy IaC
 - NAO use para orquestracao (manifests k8s, helm) — fora do escopo; o relatorio pode citar essas tools
 
 ## Posicao no Pipeline
 
-**Predecessor:** qualquer projeto com manifest (`package.json`, `pyproject.toml`, `*.csproj`, `Cargo.toml`) | **Sucessor:** `/dw-security-check` (Trivy no Dockerfile + compose), `/dw-deps-audit` (auditar deps antes de bakar elas em imagem prod)
+**Predecessor:** qualquer projeto com manifest (`package.json`, `pyproject.toml`, `*.csproj`, `Cargo.toml`) | **Sucessor:** `/dw-secure-audit` (Trivy no Dockerfile + compose), `/dw-secure-audit --plan` (auditar deps antes de bakar elas em imagem prod)
 
 ## Skills Complementares
 
@@ -58,7 +58,7 @@ Detecte linguagem(s), framework, package manager, deps de infra de runtime e art
 
 #### 0.1 Matriz de linguagens
 
-Mesma matriz de `/dw-security-check` e `/dw-deps-audit`:
+Mesma matriz de `/dw-secure-audit` e `/dw-secure-audit --plan`:
 
 | Linguagem | Indicadores |
 |-----------|-------------|
@@ -273,9 +273,9 @@ Secoes:
 7. **Audit Findings** (so `--audit`) — tabela de issues com severidade, file:line, recomendacao.
 8. **Next Steps:**
    - Para `--dev`: `cp .env.example .env` (se faltar), `docker compose -f docker-compose.dev.yml up -d`, depois smoke test do app.
-   - Para `--prod`: build local primeiro (`docker build -t <name>:dev .`), rode `/dw-security-check` no Dockerfile e compose, depois push pro registry.
+   - Para `--prod`: build local primeiro (`docker build -t <name>:dev .`), rode `/dw-secure-audit` no Dockerfile e compose, depois push pro registry.
    - Para `--audit`: aplique fixes manualmente ou rode com `--mode=force-overwrite`.
-   - Sempre: rode `/dw-deps-audit` antes de promover a imagem para prod.
+   - Sempre: rode `/dw-secure-audit --plan` antes de promover a imagem para prod.
 
 ## Flags
 
@@ -309,13 +309,13 @@ Secoes:
 
 ## Integracao com Outros dw-* Commands
 
-- **`/dw-security-check`** — rode APOS geracao `--prod` para escanear o novo Dockerfile + compose com Trivy IaC.
-- **`/dw-deps-audit`** — rode ANTES da geracao `--prod` para garantir que nenhuma dep vulneravel vai pra imagem.
+- **`/dw-secure-audit`** — rode APOS geracao `--prod` para escanear o novo Dockerfile + compose com Trivy IaC.
+- **`/dw-secure-audit --plan`** — rode ANTES da geracao `--prod` para garantir que nenhuma dep vulneravel vai pra imagem.
 - **`/dw-new-project`** — comando irmao. `/dw-new-project` ja inclui Docker do dia 1; `/dw-dockerize` retrofita. Compartilham a skill `docker-compose-recipes`.
-- **`/dw-fix-qa`** — se um `Dockerfile.dev` gerado quebra o hot-reload, `/dw-fix-qa` itera fixes com o usuario.
+- **`/dw-qa --fix`** — se um `Dockerfile.dev` gerado quebra o hot-reload, `/dw-qa --fix` itera fixes com o usuario.
 
 ## Inspirado em
 
-`dw-dockerize` e dev-workflow-native. A camada de deteccao reusa a matriz de linguagens de `/dw-security-check` e `/dw-deps-audit`. A camada de brainstorm pega a disciplina das tres opcoes (Conservadora/Balanceada/Ousada) emprestada do `/dw-brainstorm` e aplica em escolha de base. A camada de audit reusa `security-review/infrastructure/docker.md` para checks alinhados com OWASP. A composicao de compose esta delegada para a skill bundled `docker-compose-recipes` (compartilhada com `/dw-new-project`).
+`dw-dockerize` e dev-workflow-native. A camada de deteccao reusa a matriz de linguagens de `/dw-secure-audit` e `/dw-secure-audit --plan`. A camada de brainstorm pega a disciplina das tres opcoes (Conservadora/Balanceada/Ousada) emprestada do `/dw-brainstorm` e aplica em escolha de base. A camada de audit reusa `security-review/infrastructure/docker.md` para checks alinhados com OWASP. A composicao de compose esta delegada para a skill bundled `docker-compose-recipes` (compartilhada com `/dw-new-project`).
 
 </system_instructions>

package/scaffold/pt-br/commands/dw-find-skills.md

@@ -15,7 +15,7 @@ Voce e um assistente de descoberta de skills neste workspace. Sua funcao e ajuda
 
 ## Posicao no Pipeline
 
-**Predecessor:** qualquer pergunta exploratoria | **Sucessor:** nenhum (fluxo independente). Se nao achar skill, caia para `/dw-brainstorm` (explorar ideias) ou `/dw-run-task` (mudanca pequena one-off) quando aplicavel.
+**Predecessor:** qualquer pergunta exploratoria | **Sucessor:** nenhum (fluxo independente). Se nao achar skill, caia para `/dw-brainstorm` (explorar ideias) ou `/dw-run` (mudanca pequena one-off) quando aplicavel.
 
 ## Skills Complementares
 
@@ -81,7 +81,7 @@ Catalogo: https://skills.sh/
    - Reconheca que nao houve match, sem inventar
    - Ofereca ajudar direto com capacidades gerais
    - Sugira `/dw-brainstorm` se o usuario quer explorar antes de construir
-   - Sugira `/dw-run-task` se cabe em uma mudanca pequena (<= 3 arquivos, sem PRD)
+   - Sugira `/dw-run` se cabe em uma mudanca pequena (<= 3 arquivos, sem PRD)
    - Mencione `npx skills init <nome>` como caminho para criar a skill que falta
 
 ## Categorias Comuns
@@ -128,7 +128,7 @@ Pesquisei skills sobre "<query>" e nao achei match forte
 
 Posso ajudar direto. Ou:
   /dw-brainstorm "<sua ideia>"     — explorar abordagens antes
-  /dw-run-task "<mudanca pequena>" — se cabe em uma task curta (escreva PRD curto antes)
+  /dw-run "<mudanca pequena>" — se cabe em uma task curta (escreva PRD curto antes)
   npx skills init <nome>           — criar voce mesmo se vale a pena reutilizar
 ```
 
@@ -150,7 +150,7 @@ Posso ajudar direto. Ou:
 `dw-find-skills` porta a skill `find-skills` (do bundle superpowers do Claude, `~/.agents/skills/find-skills/SKILL.md`) para um comando do workflow `dw-*` — assim toda plataforma suportada (Claude Code, Codex, Copilot, OpenCode) ganha a mesma porta de descoberta. Adaptacoes para o dev-workflow:
 
 - Integracao com o pipeline: `/dw-help <keyword>` roteia para ca quando bate em `skill`/`find skill`/`install skill`/`extend agent`.
-- Fallback para `/dw-brainstorm` ou `/dw-run-task` quando nao acha skill — mantem o usuario dentro do workflow ao inves de despeja-lo de maos vazias.
+- Fallback para `/dw-brainstorm` ou `/dw-run` quando nao acha skill — mantem o usuario dentro do workflow ao inves de despeja-lo de maos vazias.
 - Pergunta explicita de escopo (`-g` vs local) antes de instalar, em vez de assumir global.
 
 Credito: skill `find-skills` do ecossistema superpowers do Claude e o projeto `npx skills` / [skills.sh](https://skills.sh/).

package/scaffold/pt-br/commands/dw-functional-doc.md

@@ -3,7 +3,7 @@ Você é um assistente especializado em mapear funcionalidades reais de telas, f
 
 ## Quando Usar
 - Use para mapear telas, fluxos ou módulos em um dossiê funcional abrangente com cobertura de testes E2E e tours em vídeo opcionais
-- NÃO use quando apenas executar testes QA contra requisitos existentes (use `/dw-run-qa`)
+- NÃO use quando apenas executar testes QA contra requisitos existentes (use `/dw-qa`)
 - NÃO use quando o projeto ainda não foi configurado
 
 ## Posição no Pipeline

package/scaffold/pt-br/commands/dw-generate-pr.md

@@ -4,10 +4,10 @@
     ## Quando Usar
     - Use para criar um Pull Request de uma branch de feature ou bugfix para main/develop
     - NÃO use quando as alterações ainda não foram commitadas (use `/dw-commit` primeiro)
-    - NÃO use quando o code review ainda não foi feito (use `/dw-code-review` primeiro)
+    - NÃO use quando o code review ainda não foi feito (use `/dw-review --code-only` primeiro)
 
     ## Posição no Pipeline
-    **Antecessor:** `/dw-code-review` ou `/dw-commit` | **Sucessor:** (merge)
+    **Antecessor:** `/dw-review --code-only` ou `/dw-commit` | **Sucessor:** (merge)
 
     ## Skills Complementares
 
@@ -15,11 +15,11 @@
     |-------|---------|
     | `dw-verify` | **SEMPRE** — invocada antes do `git push`. Sem VERIFICATION REPORT PASS na sessão após a última edição de código, o PR **NÃO** pode ser criado. |
     | `dw-git-discipline` | **SEMPRE** — valida naming de branch (`<tipo>/<escopo>` kebab-case), histórico atomic-commit (cada commit single-intent, mensagem conventional), tempo de vida da branch (flag se >7 dias) e escopo da PR (sugere split se diff > ~400 linhas). Descrição da PR segue summary + test plan, não dump de `git log`. |
-    | `/dw-security-check` | **SEMPRE para projetos TS/Python/C#/Rust** — `security-check.md` com status ≠ REJECTED é obrigatório para projetos em linguagem suportada. |
+    | `/dw-secure-audit` | **SEMPRE para projetos TS/Python/C#/Rust** — `security-check.md` com status ≠ REJECTED é obrigatório para projetos em linguagem suportada. |
 
     <critical>Hard gate 1 (verify): se a sessão atual não tem um VERIFICATION REPORT PASS de `dw-verify` produzido APÓS a última edição/commit, PARAR e invocar `dw-verify` antes de prosseguir. PR é um artefato permanente — exige o maior rigor de verificação.</critical>
 
-    <critical>Hard gate 2 (security): para projetos TS/Python/C#/Rust, se `{{PRD_PATH}}/security-check.md` não existir OU tiver status REJECTED, PARAR e invocar `/dw-security-check` antes de prosseguir. Vulnerabilidades HIGH/CRITICAL NÃO podem chegar ao PR. Para outras linguagens (Go, Java, etc.), este gate é pulado com nota.</critical>
+    <critical>Hard gate 2 (security): para projetos TS/Python/C#/Rust, se `{{PRD_PATH}}/security-check.md` não existir OU tiver status REJECTED, PARAR e invocar `/dw-secure-audit` antes de prosseguir. Vulnerabilidades HIGH/CRITICAL NÃO podem chegar ao PR. Para outras linguagens (Go, Java, etc.), este gate é pulado com nota.</critical>
 
     ## Uso