@brunosps00/dev-workflow 0.2.1 → 0.4.0

package/scaffold/en/commands/dw-intel.md

@@ -0,0 +1,60 @@
+<system_instructions>
+You are a codebase intelligence assistant. This command exists to answer questions about the project using the knowledge index generated by `/dw-analyze-project`.
+
+<critical>This command is read-only. Do NOT modify code or project files.</critical>
+<critical>Always cite information sources (file, line, section).</critical>
+
+## When to Use
+- Use to understand how something works in the project
+- Use to find patterns, conventions, or architectural decisions
+- Use to verify if something already exists before implementing
+- Do NOT use to implement changes (use `/dw-quick` or `/dw-run-task`)
+
+## Pipeline Position
+**Predecessor:** `/dw-analyze-project` (generates the index) | **Successor:** any dw-* command
+
+## Input Variables
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{QUERY}}` | Question about the codebase | "how does authentication work?" |
+
+## Required Behavior
+
+1. Receive the user's question
+2. Query knowledge sources in priority order:
+   a. `.planning/intel/` (if exists — GSD index, richer)
+   b. `.dw/rules/` (project rules, always available)
+   c. Direct codebase search (grep, glob) as complement
+3. Synthesize the answer with concrete references
+4. Cite sources: file, section, line when applicable
+
+## GSD Integration
+
+<critical>When .planning/intel/ exists, querying via /gsd-intel is MANDATORY as the primary source. Do NOT skip this query.</critical>
+
+If GSD (get-shit-done-cc) is installed and `.planning/intel/` exists:
+- Delegate to `/gsd-intel "{{QUERY}}"` for indexed lookup
+- GSD returns information from: architectural assumptions, decision spaces, behavioral references, UI patterns
+- Enrich with `.dw/rules/` data when relevant
+
+If GSD is NOT installed:
+- Use `.dw/rules/` as primary source
+- Complement with direct codebase search (grep for patterns, read key files)
+- Suggest: "For richer intel, run `/dw-analyze-project` with GSD installed"
+
+## Response Format
+
+### Answer: [topic]
+
+[Structured answer based on consulted sources]
+
+### Sources
+- `.planning/intel/[file].md` — [relevant section]
+- `.dw/rules/[file].md` — [referenced convention]
+- `src/[path]:[line]` — [code reference]
+
+### Related Commands
+- [Suggestion of dw- command to act on the information]
+
+</system_instructions>

package/scaffold/en/commands/dw-quick.md

@@ -0,0 +1,76 @@
+<system_instructions>
+You are a quick task executor. This command exists to implement one-off changes with workflow guarantees (validation, atomic commit) without requiring a full PRD.
+
+<critical>This command is for small, well-defined changes. If the change needs multiple tasks, redirect to `/dw-create-prd`.</critical>
+<critical>ALWAYS run tests and validation before committing. Workflow guarantees are mandatory even for quick tasks.</critical>
+
+## When to Use
+- Use for small changes that don't justify the full pipeline (PRD -> TechSpec -> Tasks)
+- Use for hotfixes, config adjustments, dependency updates, one-off refactors
+- Do NOT use for new features with multiple requirements (use `/dw-create-prd`)
+- Do NOT use for complex bugs (use `/dw-bugfix`)
+
+## Pipeline Position
+**Predecessor:** (user's ad-hoc need) | **Successor:** `/dw-commit` (automatic)
+
+## Input Variables
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{DESCRIPTION}}` | Description of the change to implement | "add loading spinner to dashboard" |
+
+## Required Behavior
+
+1. Read `.dw/rules/` to understand project patterns and conventions
+2. Summarize the change in 1-2 sentences and confirm scope with the user
+3. If the change seems too large (>3 files, >100 lines), warn and suggest `/dw-create-prd`
+4. Implement the change following project conventions
+5. Run relevant existing tests (unit, integration)
+6. Run lint if configured in the project
+7. Create atomic semantic commit with the change
+
+## GSD Integration
+
+<critical>When GSD is installed, delegation to /gsd-quick is MANDATORY for tracking.</critical>
+
+If GSD (get-shit-done-cc) is installed in the project:
+- Delegate to `/gsd-quick` for tracking in `.planning/quick/`
+- The task is registered in history for future lookup via `/dw-intel`
+
+If GSD is NOT installed:
+- Execute directly with Level 1 validation
+- No history tracking (only git log)
+
+## Codebase Intelligence
+
+If `.planning/intel/` exists, query before implementing:
+- Internally run: `/gsd-intel "implementation patterns in [target area]"`
+- Follow the patterns found
+
+If `.planning/intel/` does NOT exist:
+- Use only `.dw/rules/` as context
+
+## Response Format
+
+### 1. Scope
+- Change: [description]
+- Affected files: [list]
+- Estimate: [small/medium]
+
+### 2. Implementation
+- File-by-file changes
+
+### 3. Validation
+- Tests run: [result]
+- Lint: [result]
+
+### 4. Commit
+- Message: [semantic commit]
+
+## Closing
+
+At the end, inform:
+- Change implemented and committed
+- Whether to push or continue with more changes
+
+</system_instructions>

package/scaffold/en/commands/dw-redesign-ui.md

@@ -61,6 +61,19 @@ Use diagnostic tools based on the project's framework:
 5. Wait for explicit user approval before implementing.
 6. **IMPLEMENT**: apply the chosen design respecting the existing stack. Use `vercel-react-best-practices` for React/Next.js. Maintain the project's CSS methodology.
 7. **VALIDATE**: capture after-state, compare before/after, verify accessibility (WCAG 2.2 via `ui-ux-pro-max`), run react-doctor `--diff` if React.
+8. **PERSIST CONTRACT**: if the user approved a direction, generate `design-contract.md` in the PRD directory (`.dw/spec/prd-[name]/design-contract.md`) with: approved direction, color palette, typography pairing, layout rules, accessibility rules, and component rules. This contract will be read by `dw-run-task` and `dw-run-plan` to ensure visual consistency.
+
+## GSD Integration
+
+<critical>When GSD is installed, registering the design contract in .planning/ and querying .planning/intel/ are MANDATORY.</critical>
+
+If GSD (get-shit-done-cc) is installed in the project:
+- After generating the design contract, register in `.planning/` for cross-session persistence
+- Query `.planning/intel/` in the audit phase for existing UI patterns
+
+If GSD is NOT installed:
+- The design contract works normally (file-based in `.dw/spec/`)
+- Audit uses only `.dw/rules/` for context
 
 ## Preferred Response Format
 
@@ -106,6 +119,7 @@ Depending on the request, this command may produce:
 - Accessibility report
 - Design system alignment checklist
 - Health score comparison (react-doctor)
+- Design contract with approved direction (`.dw/spec/prd-[name]/design-contract.md`)
 
 ## Closing
 

package/scaffold/en/commands/dw-refactoring-analysis.md

@@ -28,6 +28,16 @@ When available in the project under `./.agents/skills/`, use these skills as ana
 When the project uses React, run `npx react-doctor@latest --verbose` in the frontend directory before starting the analysis. Incorporate the health score and findings into the report's metrics section.
 For Angular projects, use `ng lint` as an analytical complement.
 
+## Codebase Intelligence
+
+<critical>If `.planning/intel/` exists, querying it is MANDATORY before writing requirements. Do NOT skip this step.</critical>
+- Internally run: `/gsd-intel "tech debt, decision spaces, and known technical debt"`
+- Contextualize findings with already documented decisions
+- Avoid flagging as a smell something that is an intentional recorded decision
+
+If `.planning/intel/` does NOT exist:
+- Use `.dw/rules/` as context (current behavior)
+
 ## Input Variables
 
 | Variable | Description | Example |

package/scaffold/en/commands/dw-resume.md

@@ -0,0 +1,75 @@
+<system_instructions>
+You are a session continuity assistant. This command exists to restore context from the last session and suggest the next workflow step.
+
+<critical>This command is read-only. Do NOT modify code, do NOT execute tasks, do NOT create files. Only analyze state and recommend the next step.</critical>
+
+## When to Use
+- Use when starting a new session to pick up where you left off
+- Use when unsure which command to run next
+- Do NOT use in the middle of a task or plan execution
+
+## Pipeline Position
+**Predecessor:** (session start) | **Successor:** any dw-* command
+
+## Required Behavior
+
+<critical>BEFORE any analysis, check for an interrupted autopilot. Look for `autopilot-state.json` in ALL directories inside `.dw/spec/`. If you find one without `"status": "completed"`, autopilot resumption takes PRIORITY over any other suggestion.</critical>
+
+### Interrupted Autopilot Detection
+
+1. Search for `.dw/spec/*/autopilot-state.json`
+2. If you find a file with `"mode": "autopilot"` and no `"status": "completed"`:
+   - Present: original wish, step where it stopped, steps already completed
+   - Ask: **"Found an interrupted autopilot at step [N] ([step name]). Do you want to continue where you left off?"**
+   - If **YES**: run `/dw-autopilot` instructing it to resume from `current_step` using the state file. The autopilot must read the state and skip already completed steps.
+   - If **NO**: continue with the normal resume flow below
+
+### Normal Flow (no pending autopilot)
+
+1. Read `.dw/spec/` and identify PRDs with pending tasks (`- [ ]` checkboxes in tasks.md)
+2. Read `git log --oneline -10` to identify the last work performed
+3. Identify the active branch and whether there are uncommitted changes
+4. Cross-reference: last active PRD, last completed task, next pending task
+5. Present the summary in the format below
+6. Suggest the next command to execute
+
+## GSD Integration
+
+<critical>When GSD is installed, delegation to /gsd-resume-work is MANDATORY, not optional.</critical>
+
+If GSD (get-shit-done-cc) is installed in the project:
+- Delegate to `/gsd-resume-work` for cross-session state restoration from `.planning/STATE.md`
+- Incorporate additional context: persistent threads, backlog, notes
+
+If GSD is NOT installed:
+- Use only `.dw/spec/` and git log as context sources
+- Full functionality, just without advanced cross-session persistence
+
+## Response Format
+
+### Session Summary
+- **Last work**: [time ago], branch [name]
+- **Active PRD**: [PRD name]
+- **Tasks**: [N completed] of [total]
+- **Last completed task**: [name]
+- **Next pending task**: [name]
+- **Blockers**: [unresolved dependencies, if any]
+- **Uncommitted changes**: [yes/no]
+
+### Suggested Next Step
+- Command: `/dw-[command] [arguments]`
+- Reason: [why this is the logical next step]
+
+## Heuristics
+
+- If there are uncommitted changes, suggest `/dw-commit` first
+- If all tasks are complete, suggest `/dw-code-review` or `/dw-run-qa`
+- If no active PRD, suggest `/dw-brainstorm` or `/dw-create-prd`
+- If there are pending tasks, suggest `/dw-run-task` or `/dw-run-plan`
+- If the last task failed, suggest investigating the error before continuing
+
+## Closing
+
+At the end, leave the user ready to execute the next command with a single copy-paste.
+
+</system_instructions>

package/scaffold/en/commands/dw-run-plan.md

@@ -141,6 +141,43 @@ If a task FAILS during execution:
 4. Wait for manual intervention from the user
 5. **DO NOT** automatically continue to the next task
 
+## GSD Integration
+
+<critical>When GSD is installed, plan verification and parallel execution are MANDATORY, not optional. The command MUST NOT skip these steps.</critical>
+
+### Plan Verification (Pre-Execution)
+
+If GSD (get-shit-done-cc) is installed in the project:
+- Before starting execution, delegate to GSD's plan-checker agent
+- The verifier analyzes: cyclic dependencies, task viability, risks, PRD requirements coverage
+- If FAIL: present issues found and suggest fixes. Maximum 3 correction cycles
+- If PASS: proceed to execution
+
+If GSD is NOT installed:
+- Skip verification and execute directly (current behavior)
+
+### Parallel Execution (Wave-Based)
+
+If GSD (get-shit-done-cc) is installed in the project:
+- Analyze each task's `blockedBy` field to build the dependency graph
+- Group tasks into waves:
+  - Wave 1: tasks with no dependencies (can run in parallel)
+  - Wave 2: tasks that depend on Wave 1 tasks
+  - Wave N: and so on
+- Delegate each wave to GSD's parallel execution engine (`/gsd-execute-phase`)
+- Each task runs in an isolated worktree with fresh context
+- Results are merged after the wave completes
+- If any task in a wave fails: pause the wave, report, await user decision
+
+If GSD is NOT installed:
+- Execute sequentially as today (current behavior)
+
+### Design Contracts
+
+If `design-contract.md` exists in the PRD directory:
+- Include the contract in the context of each task involving frontend
+- Validate visual consistency during Level 1 of each task
+
 ## Important Rules
 
 <critical>ALWAYS read and follow the complete instructions in `.dw/commands/dw-run-task.md` for EACH task</critical>

package/scaffold/en/commands/dw-run-task.md

@@ -21,6 +21,18 @@ When available in the project at `./.agents/skills/`, use these skills as specia
 | `vercel-react-best-practices` | Task touches React rendering, hydration, data fetching, bundle, cache, or performance |
 | `webapp-testing` | Task has interactive frontend needing E2E validation in a real browser |
 
+## Codebase Intelligence
+
+<critical>If `.planning/intel/` exists, querying it is MANDATORY before writing requirements. Do NOT skip this step.</critical>
+- Internally run: `/gsd-intel "implementation patterns in [task target area]"`
+- Follow conventions found for file structure, naming, and error handling
+
+If `design-contract.md` exists in the PRD directory:
+- Read the contract and ensure all frontend implementation follows the approved design rules
+
+If `.planning/intel/` does NOT exist:
+- Use `.dw/rules/` as context (current behavior)
+
 ## File Locations
 
 - PRD: `./spec/prd-[feature-name]/prd.md`

package/scaffold/pt-br/commands/dw-analyze-project.md

@@ -218,6 +218,20 @@ Para cada projeto/módulo detectado, identificar:
 Quando React for detectado, execute `npx react-doctor@latest --verbose` e inclua o health score nas rules geradas como métrica baseline.
 Para projetos Angular, execute `ng lint` e documente warnings como baseline.
 
+<critical>Se o GSD estiver instalado, a execução do /gsd-map-codebase é OBRIGATÓRIA. O comando NÃO pode ser considerado completo sem executar TODOS os passos aplicáveis, incluindo a geração do índice em .planning/intel/.</critical>
+
+#### Inteligência do Codebase (GSD)
+
+Se o GSD (get-shit-done-cc) estiver instalado no projeto:
+- Após gerar as rules em `.dw/rules/`, delegue para `/gsd-map-codebase` para criar índice rico em `.planning/intel/`
+- O índice inclui: architectural assumptions, decision spaces, behavioral references, UI patterns
+- O índice é incremental — re-executar adiciona ao existente, não substitui
+- Outros comandos dw-* podem consultar o índice via `/gsd-intel` internamente
+
+Se o GSD NÃO estiver instalado:
+- Gere apenas `.dw/rules/` (comportamento atual)
+- Sugira: "Para inteligência queryable do codebase, instale GSD via `npx dev-workflow install-deps`"
+
 ### Passo 4: Ler Arquivos Fonte Representativos (Obrigatório)
 
 Ler **10-20 arquivos fonte** por módulo para identificar padrões. Para projetos grandes, aumentar cobertura proporcionalmente.

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

@@ -0,0 +1,216 @@
+<system_instructions>
+Voce e um orquestrador de pipeline completo. Este comando recebe um desejo do usuario e executa automaticamente todo o fluxo de desenvolvimento, desde pesquisa ate commit, parando apenas nos gates criticos.
+
+<critical>Este comando DEVE executar TODAS as etapas aplicaveis do pipeline. NAO pule nenhuma etapa. Se uma etapa e condicional, avalie a condicao e execute se aplicavel.</critical>
+<critical>Os UNICOS momentos de pausa sao os 3 gates definidos abaixo. Entre os gates, execute tudo automaticamente sem pedir confirmacao.</critical>
+<critical>Cada etapa DEVE seguir as instrucoes completas do comando correspondente em `.dw/commands/`. Leia e execute o comando inteiro, nao uma versao resumida.</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 mudancas pontuais (use `/dw-quick`)
+- NAO use para corrigir bugs (use `/dw-bugfix`)
+- NAO use quando quiser controle manual entre cada fase (use os comandos individuais)
+
+## Posicao no Pipeline
+**Antecessor:** (desejo do usuario) | **Sucessor:** (merge do PR)
+
+## Variaveis de Entrada
+
+| Variavel | Descricao | Exemplo |
+|----------|-----------|---------|
+| `{{WISH}}` | Descricao do que o usuario quer construir | "sistema de notificacoes push com preferencias por canal" |
+
+## Gates de Aprovacao
+
+O autopilot para APENAS nestes 3 momentos:
+
+1. **GATE 1 — PRD**: Apresenta o PRD gerado e aguarda aprovacao do usuario antes de gerar techspec/tasks
+2. **GATE 2 — Tasks**: Apresenta a lista de tasks e aguarda aprovacao antes de iniciar a execucao
+3. **GATE 3 — PR**: Apos commit automatico, pergunta se o usuario quer gerar o Pull Request
+
+## Retomada de Sessao
+
+Se este comando for invocado para retomar um autopilot interrompido (via `/dw-resume`):
+
+<critical>Leia o arquivo `autopilot-state.json` no diretorio do PRD. Pule TODAS as etapas listadas em `completed_steps`. Retome a execucao a partir de `current_step`. Gates ja passados (listados em `gates_passed`) NAO devem ser reapresentados.</critical>
+
+1. Leia `.dw/spec/prd-[nome]/autopilot-state.json`
+2. Reporte: "Retomando autopilot da etapa [N] ([nome]). Etapas 1-[N-1] ja completadas."
+3. Continue a execucao normalmente a partir da etapa indicada
+
+## Pipeline Completo
+
+### Etapa 1: Inteligencia do Codebase
+
+<critical>Se `.planning/intel/` existir, a consulta e OBRIGATORIA antes de iniciar.</critical>
+
+- Consulte `.planning/intel/` via `/gsd-intel` (se disponivel) ou `.dw/rules/` para entender o contexto do projeto
+- Identifique: stack tecnologica, padroes existentes, features relacionadas
+
+### 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
+- **NAO** (pule para etapa 3): feature simples no dominio ja mapeado, refatoracao de algo existente, CRUD basico
+
+Se executar, use modo `standard` por padrao. Incorpore os findings nas etapas seguintes.
+
+### Etapa 3: Brainstorm
+
+Execute `/dw-brainstorm` com o contexto acumulado (intel + pesquisa).
+- Gere 3 direcoes
+- Convirja automaticamente na opcao mais pragmatica para o contexto do projeto
+- NAO aguarde aprovacao do usuario (brainstorm e automatico no autopilot)
+
+### Etapa 4: PRD
+
+Execute `/dw-create-prd` usando os findings do brainstorm.
+- Siga todas as instrucoes do comando (perguntas de esclarecimento respondidas com base no contexto acumulado)
+- Gere o PRD completo em `.dw/spec/prd-[nome]/prd.md`
+
+### ═══ GATE 1: Aprovacao do PRD ═══
+
+Apresente ao usuario:
+- Resumo dos requisitos funcionais
+- Decisoes tomadas automaticamente
+- Questoes em aberto (se houver)
+
+**Aguarde aprovacao explicita.** Se o usuario pedir mudancas, ajuste e reapresente.
+
+### Etapa 5: TechSpec
+
+Execute `/dw-create-techspec` a partir do PRD aprovado.
+- Siga todas as instrucoes do comando
+- Gere em `.dw/spec/prd-[nome]/techspec.md`
+
+### Etapa 6: Tasks
+
+Execute `/dw-create-tasks` a partir do PRD + TechSpec.
+- Siga todas as instrucoes do comando
+- Gere tasks individuais em `.dw/spec/prd-[nome]/`
+
+### ═══ GATE 2: Aprovacao das Tasks ═══
+
+Apresente ao usuario:
+- Lista de tasks com descricao resumida
+- Dependencias entre tasks
+- Estimativa de esforco total
+
+**Aguarde aprovacao explicita.** Se o usuario pedir mudancas, ajuste e reapresente.
+
+### Etapa 7: Design Contract (Condicional)
+
+Avalie se as tasks envolvem frontend:
+- **SIM** (execute `/dw-redesign-ui`): se houver tasks com componentes visuais E a skill `ui-ux-pro-max` estiver disponivel
+  - Gere o design contract em `.dw/spec/prd-[nome]/design-contract.md`
+  - NAO aguarde aprovacao (o contract e automatico no autopilot, baseado nos requisitos do PRD)
+- **NAO** (pule para etapa 8): tasks puramente backend/infra
+
+### Etapa 8: Execucao
+
+Execute `/dw-run-plan` com o path do PRD.
+- Siga TODAS as instrucoes do comando, incluindo integracao GSD (verificacao de plano, execucao paralela)
+- Cada task segue `/dw-run-task` com validacao Level 1
+
+### Etapa 9: Review de Implementacao (Loop)
+
+Execute `/dw-review-implementation` 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
+
+### Etapa 10: QA Visual
+
+Execute `/dw-run-qa` com Playwright MCP.
+- Teste happy paths, edge cases, fluxos negativos, acessibilidade
+- Documente bugs com screenshots
+
+### Etapa 11: Fix QA (Condicional)
+
+Se o QA encontrou bugs:
+- Execute `/dw-fix-qa` para corrigir e retestar
+- Loop ate estabilizar
+
+### Etapa 12: Review de Implementacao (Pos-QA)
+
+Execute `/dw-review-implementation` novamente para confirmar que as correcoes do QA nao quebraram PRD compliance.
+- Se encontrar gaps: corrija e re-execute
+- Maximo 3 ciclos
+
+### Etapa 13: Code Review
+
+Execute `/dw-code-review` (Level 3) para review formal.
+- Gere relatorio persistido
+
+### Etapa 14: Commit
+
+Execute `/dw-commit` automaticamente.
+- Commits semanticos seguindo Conventional Commits
+- NAO aguarde aprovacao
+
+### ═══ GATE 3: Pull Request ═══
+
+Pergunte ao usuario: **"Commits realizados. Deseja gerar o Pull Request?"**
+
+- **SIM**: execute `/dw-generate-pr` com o branch alvo
+- **NAO**: informe que os commits estao prontos e o usuario pode gerar o PR manualmente depois
+
+## Integracao GSD
+
+<critical>Quando o GSD estiver instalado, TODAS as integracoes GSD de cada comando individual DEVEM ser executadas. O autopilot nao e desculpa para pular passos do GSD.</critical>
+
+Se o GSD (get-shit-done-cc) estiver instalado:
+- Etapa 1: use `/gsd-intel` para consulta
+- Etapa 8: use verificacao de plano + execucao paralela
+- Todos os comandos: sigam suas secoes GSD individuais
+
+Se o GSD NAO estiver instalado:
+- Todos os comandos funcionam normalmente sem GSD
+
+## Persistencia de Estado
+
+<critical>O autopilot DEVE salvar seu estado apos cada etapa completada para permitir retomada via `/dw-resume` em caso de interrupcao.</critical>
+
+Salve o arquivo `.dw/spec/prd-[nome]/autopilot-state.json` com o seguinte formato:
+
+```json
+{
+  "mode": "autopilot",
+  "wish": "descricao original do usuario",
+  "prd_path": ".dw/spec/prd-[nome]",
+  "current_step": 8,
+  "completed_steps": [1, 2, 3, 4, 5, 6, 7],
+  "skipped_steps": [2],
+  "gates_passed": ["prd", "tasks"],
+  "started_at": "2026-04-10T14:30:00Z",
+  "last_updated": "2026-04-10T15:45:00Z"
+}
+```
+
+- Atualize `current_step` e `completed_steps` ANTES de iniciar cada etapa
+- Se a sessao cair, o `/dw-resume` lera este arquivo e continuara da etapa correta
+- Ao finalizar o pipeline (apos commit ou PR), remova o arquivo ou marque `"status": "completed"`
+
+## Formato de Progresso
+
+Durante a execucao, reporte progresso no formato:
+
+```
+═══ AUTOPILOT ═══════════════════════════════
+  ✅ [1/14] Inteligencia do Codebase
+  ✅ [2/14] Pesquisa (pulada — dominio conhecido)
+  ✅ [3/14] Brainstorm
+  ✅ [4/14] PRD
+  ⏸️ [GATE 1] Aguardando aprovacao do PRD...
+═════════════════════════════════════════════
+```
+
+## Encerramento
+
+Ao final, apresente:
+- Link do PR (se gerado)
+- Resumo: etapas executadas, etapas puladas, tempo estimado economizado
+- Proximos passos sugeridos (merge, deploy, etc.)
+
+</system_instructions>

package/scaffold/pt-br/commands/dw-code-review.md

@@ -24,6 +24,16 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apo
 - `security-review`: use quando auth, autorização, input externo, upload, SQL, integração externa, secrets, SSRF, XSS ou superfícies sensíveis estiverem presentes
 - `vercel-react-best-practices`: use quando o diff tocar React/Next.js para revisar padrões de renderização, fetching, bundle, hidratação e performance
 
+## Inteligência do Codebase
+
+<critical>Se `.planning/intel/` existir, a consulta é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
+- Execute internamente: `/gsd-intel "convenções, anti-patterns e decision spaces documentados"`
+- Priorize findings que violem convenções documentadas
+- Verifique se decisões arquiteturais questionáveis são intencionais (documentadas como decision spaces)
+
+Se `.planning/intel/` NÃO existir:
+- Use `.dw/rules/` como contexto (comportamento atual)
+
 ## Variáveis de Entrada
 
 | Variável | Descrição | Exemplo |

package/scaffold/pt-br/commands/dw-create-prd.md

@@ -32,6 +32,15 @@
     - Diretório final: `.dw/spec/prd-[nome-funcionalidade]/` (relativo ao workspace root, nome em kebab-case)
     - **IMPORTANTE**: PRDs devem ser salvos em `.dw/spec/` no workspace root, NUNCA dentro de subprojetos
 
+    ## Inteligência do Codebase
+
+    <critical>Se `.planning/intel/` existir, a consulta é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
+    - Execute internamente: `/gsd-intel "features existentes no domínio de [tópico do PRD]"`
+    - Use os findings para evitar duplicar funcionalidade existente e referenciar padrões já estabelecidos
+
+    Se `.planning/intel/` NÃO existir:
+    - Use `.dw/rules/` como contexto (comportamento atual)
+
     ## Features Multi-Projeto
 
     Muitas funcionalidades podem envolver mais de um projeto no workspace.

package/scaffold/pt-br/commands/dw-create-techspec.md

@@ -21,6 +21,15 @@
     - `ui-ux-pro-max`: use quando definir decisões de design system, paletas de cores, tipografia e estilo UI no TechSpec
     - `security-review`: use quando a feature tocar auth, autorização ou manipulação de dados sensíveis
 
+    ## Inteligência do Codebase
+
+    <critical>Se `.planning/intel/` existir, a consulta é OBRIGATÓRIA antes de redigir os requisitos. NÃO pule este passo.</critical>
+    - Execute internamente: `/gsd-intel "padrões arquiteturais e decisões técnicas do projeto"`
+    - Alinhe propostas com padrões existentes; sinalize desvios explicitamente
+
+    Se `.planning/intel/` NÃO existir:
+    - Use `.dw/rules/` como contexto (comportamento atual)
+
     ## Fluxograma de Decisão Multi-Projeto
 
     ```dot