@brunosps00/dev-workflow 0.15.0 → 1.0.0

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

@@ -15,18 +15,18 @@ Uma etapa que invoca um comando `/dw-xxx` SO e considerada completa quando os ar
 | Pensamento | Realidade |
 |------------|-----------|
 | "Ja rodei os testes manualmente" | O comando produz artefatos estruturados. Rode o comando. |
-| "Validei via Playwright ad-hoc" | `/dw-run-qa` exige matriz por RF, bugs.md, screenshots, scripts, logs, checklist. Rode o comando. |
-| "A implementacao esta obviamente correta" | `/dw-review-implementation` exige matriz de compliance por RF/endpoint/task. Rode o comando. |
+| "Validei via Playwright ad-hoc" | `/dw-qa` exige matriz por RF, bugs.md, screenshots, scripts, logs, checklist. Rode o comando. |
+| "A implementacao esta obviamente correta" | `/dw-review --coverage-only` exige matriz de compliance por RF/endpoint/task. Rode o comando. |
 | "Validacao manual forte ja basta" | NAO. Equivalencia tecnica NAO substitui a execucao formal. |
 | "Ja conferi build e lint, e suficiente" | Build/lint NAO substituem review nem QA. Rode os comandos. |
-| "Gerei um qa-report.md resumido a mao" | Um arquivo solto NAO e execucao de `/dw-run-qa`. A arvore `QA/` completa e obrigatoria. |
+| "Gerei um qa-report.md resumido a mao" | Um arquivo solto NAO e execucao de `/dw-qa`. A arvore `QA/` completa e obrigatoria. |
 | "O autopilot ja avancou, nao preciso voltar" | Se o artefato nao existe, a etapa nao rodou. Volte e execute. |
-| "Corrigi bugs no caminho, entao o QA ja esta ok" | Corrigir bugs nao substitui rodar o QA formal. Rode `/dw-run-qa`. |</critical>
+| "Corrigi bugs no caminho, entao o QA ja esta ok" | Corrigir bugs nao substitui rodar o QA formal. Rode `/dw-qa`. |</critical>
 
 ## Quando Usar
 - Use quando quiser ir de uma ideia ate um PR com minima intervencao manual
 - Use para features completas que passam por todo o pipeline (pesquisa, planejamento, execucao, qualidade)
-- NAO use para tasks pequenas e bem-escopadas — use `/dw-run-task` direto com um PRD curto
+- NAO use para tasks pequenas e bem-escopadas — use `/dw-run` direto com um PRD curto
 - NAO use para corrigir bugs (use `/dw-bugfix`)
 - NAO use quando quiser controle manual entre cada fase (use os comandos individuais)
 
@@ -72,12 +72,12 @@ Se este comando for re-invocado no mesmo PRD apos interrupcao:
 
 - Consulte `.dw/intel/` via `/dw-intel` para entender o contexto do projeto
 - Identifique: stack tecnologica, padroes existentes, features relacionadas
-- Se `.dw/intel/` esta ausente, sugira rodar `/dw-map-codebase` primeiro para contexto downstream mais rico
+- Se `.dw/intel/` esta ausente, sugira rodar `/dw-intel --build` primeiro para contexto downstream mais rico
 
 ### Etapa 2: Pesquisa (Condicional)
 
 Avalie se o topico necessita de pesquisa profunda:
-- **SIM** (execute `/dw-deep-research`): tecnologia nova para o projeto, dominio desconhecido, integracoes com APIs externas, decisoes arquiteturais criticas
+- **SIM** (execute `/dw-brainstorm --research`): tecnologia nova para o projeto, dominio desconhecido, integracoes com APIs externas, decisoes arquiteturais criticas
 - **NAO** (pule para etapa 3): feature simples no dominio ja mapeado, refatoracao de algo existente, CRUD basico
   - Se pular, DOCUMENTE o motivo no bloco de progresso. Ex: "Pesquisa pulada — dominio ja mapeado em .dw/rules/[arquivo].md". O usuario deve ver a justificativa.
 
@@ -94,7 +94,7 @@ Execute `/dw-brainstorm` com o contexto acumulado (intel + pesquisa).
 
 <critical>O PRD DEVE incluir entrevista interativa com o usuario. Faca NO MINIMO 7 perguntas de esclarecimento ANTES de redigir o PRD. NAO responda as perguntas automaticamente com base no contexto — o usuario DEVE responder.</critical>
 
-Execute `/dw-create-prd` usando os findings do brainstorm.
+Execute `/dw-plan prd` usando os findings do brainstorm.
 - Siga TODAS as instrucoes do comando, especialmente a secao de perguntas de esclarecimento
 - Faca pelo menos 7 perguntas ao usuario sobre: problema, usuarios-alvo, funcionalidades criticas, escopo, restricoes, design, integracao
 - Em cada pergunta, apresente uma recomendacao embasada nos findings do brainstorm e do deep-research (se executado). Ex: "Com base na pesquisa, recomendo X porque [evidencia]. Concorda ou prefere outra direcao?"
@@ -115,7 +115,7 @@ Apresente ao usuario:
 
 <critical>O TechSpec DEVE incluir entrevista interativa com o usuario. Faca NO MINIMO 7 perguntas de esclarecimento tecnico ANTES de redigir o TechSpec. NAO responda as perguntas automaticamente — o usuario DEVE responder.</critical>
 
-Execute `/dw-create-techspec` a partir do PRD aprovado.
+Execute `/dw-plan techspec` a partir do PRD aprovado.
 - Siga TODAS as instrucoes do comando, especialmente a secao de perguntas de esclarecimento
 - Faca pelo menos 7 perguntas ao usuario sobre: arquitetura preferida, libs existentes vs novas, estrategia de testes, integracao com sistemas existentes, restricoes de infraestrutura, performance, seguranca
 - Em cada pergunta, apresente uma recomendacao tecnica embasada nos findings do brainstorm, deep-research e PRD aprovado. Ex: "A pesquisa indicou que a lib X tem melhor performance para este caso [fonte]. Quer usar X ou tem outra preferencia?"
@@ -125,7 +125,7 @@ Execute `/dw-create-techspec` a partir do PRD aprovado.
 
 ### Etapa 6: Tasks
 
-Execute `/dw-create-tasks` a partir do PRD + TechSpec.
+Execute `/dw-plan tasks` a partir do PRD + TechSpec.
 - Siga todas as instrucoes do comando
 - Gere tasks individuais em `.dw/spec/prd-[nome]/`
 
@@ -148,9 +148,9 @@ Avalie se as tasks envolvem frontend:
 
 ### Etapa 8: Execucao
 
-Execute `/dw-run-plan` com o path do PRD.
+Execute `/dw-run` com o path do PRD.
 - Siga TODAS as instrucoes do comando, incluindo o gate nativo do plan-checker (PASS obrigatorio) e execucao paralela em waves via os agentes da skill bundled `dw-execute-phase`
-- Cada task segue `/dw-run-task` com validacao Level 1
+- Cada task segue `/dw-run` com validacao Level 1
 
 ### Etapa 9: Review de Implementacao (Loop)
 
@@ -164,7 +164,7 @@ Execute build e lint do projeto:
 5. Repita ate que build E lint passem sem erros
 6. So entao prossiga para o review
 
-Execute `/dw-review-implementation` para verificar PRD compliance (Level 2).
+Execute `/dw-review --coverage-only` para verificar PRD compliance (Level 2).
 - Se encontrar gaps: corrija automaticamente e re-execute o review
 - Maximo 3 ciclos de correcao
 - NAO avance para QA ate que o review passe
@@ -177,7 +177,7 @@ Um review textual curto, um "parece ok" ou conclusao "implementacao correta" SEM
 
 ### Etapa 10: QA Visual
 
-Execute `/dw-run-qa` com Playwright MCP.
+Execute `/dw-qa` com Playwright MCP.
 - Teste happy paths, edge cases, fluxos negativos, acessibilidade
 - Documente bugs com screenshots
 
@@ -188,12 +188,12 @@ Execute `/dw-run-qa` com Playwright MCP.
 - `{{PRD_PATH}}/QA/screenshots/` — diretorio existe e contem pelo menos 1 PNG por RF testado (formato `RF-XX-[slug]-PASS.png` ou `-FAIL.png`)
 - `{{PRD_PATH}}/QA/scripts/` — diretorio existe e contem scripts Playwright `.spec.ts`/`.spec.js` por RF
 - `{{PRD_PATH}}/QA/logs/` — diretorio existe com logs de console/rede capturados
-Rodar Playwright ad-hoc, tirar algumas screenshots soltas ou escrever um qa-report.md curto a mao NAO substitui esta estrutura. Se qualquer artefato estiver ausente ou incompleto, o comando NAO rodou — invoque `/dw-run-qa` formalmente e siga o fluxo dele ate o fim.</critical>
+Rodar Playwright ad-hoc, tirar algumas screenshots soltas ou escrever um qa-report.md curto a mao NAO substitui esta estrutura. Se qualquer artefato estiver ausente ou incompleto, o comando NAO rodou — invoque `/dw-qa` formalmente e siga o fluxo dele ate o fim.</critical>
 
 ### Etapa 11: Fix QA (Condicional)
 
 Se o QA encontrou bugs:
-- Execute `/dw-fix-qa` para corrigir e retestar
+- Execute `/dw-qa --fix` para corrigir e retestar
 - Loop ate estabilizar (maximo 5 ciclos). Apos 5 ciclos, PARE e pergunte ao usuario como deseja prosseguir.
 
 ### Etapa 12: Review de Implementacao (Pos-QA)
@@ -205,7 +205,7 @@ Execute build e lint do projeto (mesma sequencia da Etapa 9):
 2. Build
 3. Se falhar: corrija e re-execute ate passar
 
-Execute `/dw-review-implementation` novamente para confirmar que as correcoes do QA nao quebraram PRD compliance.
+Execute `/dw-review --coverage-only` novamente para confirmar que as correcoes do QA nao quebraram PRD compliance.
 - Se encontrar gaps: corrija e re-execute
 - Maximo 3 ciclos
 
@@ -213,7 +213,7 @@ Execute `/dw-review-implementation` novamente para confirmar que as correcoes do
 
 ### Etapa 13: Code Review
 
-Execute `/dw-code-review` (Level 3) para review formal.
+Execute `/dw-review --code-only` (Level 3) para review formal.
 - Gere relatorio persistido
 
 ### Etapa 14: Commit
@@ -227,7 +227,7 @@ Rode `ls` em cada caminho abaixo e confirme existencia. Se QUALQUER um faltar, N
 - `{{PRD_PATH}}/QA/screenshots/` (nao vazio)
 - `{{PRD_PATH}}/QA/scripts/` (nao vazio com arquivos `.spec.*`)
 - `{{PRD_PATH}}/QA/logs/`
-- Evidencia do ultimo `/dw-review-implementation` com matriz RF-by-RF (output da sessao ou referencia em `autopilot-state.json`)
+- Evidencia do ultimo `/dw-review --coverage-only` com matriz RF-by-RF (output da sessao ou referencia em `autopilot-state.json`)
 
 Verifique tambem `autopilot-state.json`:
 - Toda etapa de 1 a 13 que NAO esta em `skipped_steps` deve estar em `completed_steps`
@@ -250,7 +250,7 @@ Pergunte ao usuario: **"Commits realizados. Deseja gerar o Pull Request?"**
 
 ## Engine Nativo
 
-O autopilot depende de infraestrutura dev-workflow-native para inteligencia de codebase (`/dw-map-codebase` + `/dw-intel`) e dos agentes bundled de execucao de fase (plan-checker + executor em `.agents/skills/dw-execute-phase/agents/`). Tudo bundled, sem dependencias externas. Veja as skills bundled `dw-codebase-intel` e `dw-execute-phase` em `.agents/skills/` para detalhes.
+O autopilot depende de infraestrutura dev-workflow-native para inteligencia de codebase (`/dw-intel --build` + `/dw-intel`) e dos agentes bundled de execucao de fase (plan-checker + executor em `.agents/skills/dw-execute-phase/agents/`). Tudo bundled, sem dependencias externas. Veja as skills bundled `dw-codebase-intel` e `dw-execute-phase` em `.agents/skills/` para detalhes.
 
 ## Persistencia de Estado
 

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

@@ -9,14 +9,16 @@ 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
 
 - **(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`.
+- **`--onepager`**: ao final do brainstorm, gera 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 artefato persistido antes de seguir para `/dw-plan 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.
+- **`--research`**: modo de research multi-source. Pipeline: scope → plan → retrieve (sources paralelos) → triangulate → outline-refine → synthesize → critique → refine → report. Output: documento citado. Use pra state-of-the-art reviews, comparações de tech, regulatory landscape mapping. Sub-modos: `quick` (3 fases, 2-5min), `standard` (default, 6 fases, 5-10min), `deep` (8 fases, 10-20min), `ultradeep` (8+ fases, 20-45min).
+- **`--refactor`**: modo catálogo de code smells. Audita um diretório-alvo ou escopo de PRD por smells usando taxonomia de Martin Fowler (bloaters, change preventers, dispensables, couplers, complexidade condicional, violações DRY). Mapeia cada smell pra técnica de refactoring com sketches before/after. Plano severity-ordered P0-P3. Output: documento de oportunidades de refactor.
+- Flags combináveis onde faz sentido: `--onepager --council` produz one-pager após debate. `--research --onepager` salva research como one-pager durável. `--refactor --onepager` salva plano de refactor como one-pager. `--research --refactor` NÃO suportado (escolha um — surfaces de ideação diferentes).
 
 ## Fluxograma de Decisão: Brainstorm vs PRD Direto
 
@@ -27,7 +29,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"];
@@ -108,10 +110,10 @@ Use este comando quando o usuario quiser:
 ### 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
@@ -140,6 +142,155 @@ Ao final, sempre deixe o usuario em uma destas situacoes:
 - 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 relatório de research em `~/Documents/<Tópico>_Research_<data>/` (se `--research`)
+- com o plano de refactor em `<target>/refactor-plan.md` (se `--refactor`)
+
+## Modo: `--research` (research multi-fonte)
+
+Ativado pela flag `--research`. Substitui o brainstorm 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` (catálogo de code smells)
+
+Ativado pela flag `--refactor`. Audita uma área-alvo do codebase por oportunidades de refactoring usando taxonomia de smells de Martin Fowler.
+
+<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.
 
 ## Inspired by
 
@@ -148,7 +299,7 @@ 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.
 
 Crédito: Addy Osmani e o padrão `idea-refine`.
 

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