@brunosps00/dev-workflow 0.6.0 → 0.7.0

package/README.md

@@ -29,7 +29,7 @@ npx @brunosps00/dev-workflow install-deps
 ### Planning
 
 #### `/dw-brainstorm`
-Facilitates structured ideation before opening a PRD or implementation. Explores multiple directions — conservative, balanced, and bold — with trade-offs for each, then converges on concrete next steps. No code is written or files modified.
+Facilitates structured ideation before opening a PRD or implementation. Explores multiple directions — conservative, balanced, and bold — with trade-offs for each, then converges on concrete next steps. **Product-aware**: when PRDs or rules exist, automatically reads them to produce a Feature Inventory and tags each option as `[IMPROVES: <feature>]`, `[CONSOLIDATES: <A>+<B>]`, or `[NEW]`. With optional `--onepager` flag, generates a durable one-pager at `.dw/spec/ideas/<slug>.md` that `/dw-create-prd` can consume to reduce clarification questions. Inspired by [`addyosmani/agent-skills@idea-refine`](https://skills.sh/addyosmani/agent-skills/idea-refine), adapted to product-level (features) rather than code-level grounding. No code is written or project files modified by the brainstorm itself.
 
 #### `/dw-autopilot`
 Full pipeline orchestrator that takes a wish and automatically runs the entire development flow: codebase intelligence, research (conditional), brainstorm, PRD, techspec, tasks, execution, QA, review, and commit. Stops at 3 gates: PRD approval, tasks approval, and PR confirmation. With GSD installed, leverages plan verification and parallel execution.

package/lib/constants.js

@@ -1,61 +1,61 @@
 const COMMANDS = {
   en: [
-    { name: 'dw-adr', description: 'Record an Architecture Decision Record (ADR) for a non-trivial decision during PRD execution' },
-    { name: 'dw-analyze-project', description: 'Analyze repository stack, patterns, and conventions to generate project rules' },
-    { name: 'dw-autopilot', description: 'Full pipeline orchestrator from a wish to a PR with minimal intervention (research, PRD, tasks, execution, QA, review, commit)' },
-    { name: 'dw-brainstorm', description: 'Explore ideas and directions before starting implementation' },
-    { name: 'dw-bugfix', description: 'Analyze and fix bugs with automatic triage (bug vs feature vs scope)' },
-    { name: 'dw-code-review', description: 'Formal code review (Level 3) with persisted report' },
-    { name: 'dw-commit', description: 'Create semantic commits following Conventional Commits' },
-    { name: 'dw-create-prd', description: 'Create a Product Requirements Document with clarification questions' },
-    { name: 'dw-create-tasks', description: 'Break down PRD and TechSpec into implementable tasks' },
-    { name: 'dw-create-techspec', description: 'Create a Technical Specification from an existing PRD' },
-    { name: 'dw-deep-research', description: 'Conduct multi-source research with citation tracking and verification' },
-    { name: 'dw-fix-qa', description: 'Fix bugs found during QA and retest until stable' },
-    { name: 'dw-functional-doc', description: 'Generate functional documentation dossier with screen mapping, E2E flows, and Playwright validation' },
-    { name: 'dw-generate-pr', description: 'Generate a Pull Request with structured description' },
-    { name: 'dw-help', description: 'Show complete guide of available commands and workflows' },
-    { name: 'dw-intel', description: 'Query codebase intelligence to understand patterns, conventions, and architecture' },
-    { name: 'dw-quick', description: 'Execute a one-off task with workflow guarantees without requiring a full PRD' },
-    { name: 'dw-redesign-ui', description: 'Analyze, propose, and implement frontend page/component redesigns with design system integration' },
-    { name: 'dw-refactoring-analysis', description: 'Audit codebase for code smells and refactoring opportunities with prioritized report' },
-    { name: 'dw-resume', description: 'Restore session context and suggest the next workflow step' },
-    { name: 'dw-review-implementation', description: 'Review if all PRD requirements were correctly implemented' },
-    { name: 'dw-revert-task', description: 'Safely revert the commits of a specific task with dependency-aware checks' },
-    { name: 'dw-run-plan', description: 'Execute ALL tasks sequentially until the plan is complete' },
-    { name: 'dw-run-qa', description: 'Run visual QA with browser automation, E2E tests, and accessibility' },
-    { name: 'dw-run-task', description: 'Execute a single task with built-in validation and testing' },
-    { name: 'dw-security-check', description: 'Run a rigid multi-layer security check (OWASP static + Trivy SCA/IaC + native audit) for TS, Python, C#, or Rust projects' },
-    { name: 'dw-update', description: 'Update dev-workflow to the latest version published on npm without leaving the agent session' },
+    { name: 'dw-adr', description: 'Records an architectural decision and the trade-offs accepted, before they get lost.' },
+    { name: 'dw-analyze-project', description: 'Scans the repo to learn its stack and conventions, then writes the rules other commands rely on.' },
+    { name: 'dw-autopilot', description: 'Takes a wish and runs the full PRD-to-PR pipeline, stopping only at three approval gates.' },
+    { name: 'dw-brainstorm', description: 'Refines an idea using the product\'s existing features as ground truth, before any PRD.' },
+    { name: 'dw-bugfix', description: 'Triages a bug report, asks three sharp questions, then fixes it or routes it to a PRD.' },
+    { name: 'dw-code-review', description: 'Level-3 review against PRD, rules, tests, and security; saves a verdict you can act on.' },
+    { name: 'dw-commit', description: 'Groups changes by intent and writes Conventional Commits messages that read clean.' },
+    { name: 'dw-create-prd', description: 'Writes a PRD after asking the questions that would otherwise haunt the techspec later.' },
+    { name: 'dw-create-tasks', description: 'Breaks the PRD and techspec into tasks small enough to ship one at a time.' },
+    { name: 'dw-create-techspec', description: 'Translates a finished PRD into a techspec the team can actually build from.' },
+    { name: 'dw-deep-research', description: 'Researches a topic across sources, tracks citations, and flags claims that don\'t check out.' },
+    { name: 'dw-fix-qa', description: 'Fixes bugs found in QA and retests them with screenshot evidence until they stay fixed.' },
+    { name: 'dw-functional-doc', description: 'Maps screens and user flows into a functional doc, validated end-to-end with Playwright.' },
+    { name: 'dw-generate-pr', description: 'Pushes the branch and opens a PR with a body that explains what changed and how to test it.' },
+    { name: 'dw-help', description: 'Lists every command and the flows that connect them. Pass a keyword for a contextual shortcut.' },
+    { name: 'dw-intel', description: 'Answers questions about the codebase using its own rules and intel as the source of truth.' },
+    { name: 'dw-quick', description: 'Runs a small, well-defined change with workflow guarantees, no PRD needed.' },
+    { name: 'dw-redesign-ui', description: 'Audits a frontend page, proposes design directions you choose from, then ships the redesign.' },
+    { name: 'dw-refactoring-analysis', description: 'Catalogs code smells in Fowler\'s vocabulary and ranks them by impact, P0 to P3.' },
+    { name: 'dw-resume', description: 'Picks up where you left off — reads the active PRD, the last task, and tells you what\'s next.' },
+    { name: 'dw-review-implementation', description: 'Maps every PRD requirement to the code that delivers it, and lists what is still missing.' },
+    { name: 'dw-revert-task', description: 'Reverts the commits of one task, but only after checking nothing downstream depends on it.' },
+    { name: 'dw-run-plan', description: 'Runs every pending task in order, with PRD-compliance review at the end.' },
+    { name: 'dw-run-qa', description: 'Drives the browser to test happy paths, edge cases, and accessibility, with screenshot proof.' },
+    { name: 'dw-run-task', description: 'Implements one task, runs the validation that comes with it, and commits when it passes.' },
+    { name: 'dw-security-check', description: 'OWASP review plus Trivy CVE/secret/IaC scan for TS, Python, C#, or Rust. CRITICAL or HIGH blocks the PR.' },
+    { name: 'dw-update', description: 'Updates dev-workflow to the latest npm release in-place, with a snapshot you can roll back to.' },
   ],
   'pt-br': [
-    { name: 'dw-adr', description: 'Registrar um Architecture Decision Record (ADR) para uma decisao nao-trivial durante o PRD' },
-    { name: 'dw-analyze-project', description: 'Analisa stack, patterns e convencoes do repositorio para gerar regras do projeto' },
-    { name: 'dw-autopilot', description: 'Orquestrador completo de um desejo ate o PR com minima intervencao (pesquisa, PRD, tasks, execucao, QA, review, commit)' },
-    { name: 'dw-brainstorm', description: 'Explorar ideias e direcoes antes de comecar a implementacao' },
-    { name: 'dw-bugfix', description: 'Analisar e corrigir bugs com triagem automatica (bug vs feature vs escopo)' },
-    { name: 'dw-code-review', description: 'Code review formal (Nivel 3) com relatorio persistido' },
-    { name: 'dw-commit', description: 'Criar commits semanticos seguindo Conventional Commits' },
-    { name: 'dw-create-prd', description: 'Criar um Product Requirements Document com perguntas de clarificacao' },
-    { name: 'dw-create-tasks', description: 'Quebrar PRD e TechSpec em tasks implementaveis' },
-    { name: 'dw-create-techspec', description: 'Criar uma Especificacao Tecnica a partir de um PRD existente' },
-    { name: 'dw-deep-research', description: 'Pesquisa multi-fonte com rastreamento de citacoes e verificacao' },
-    { name: 'dw-fix-qa', description: 'Corrigir bugs encontrados no QA e retestar ate estabilizar' },
-    { name: 'dw-functional-doc', description: 'Gerar dossie funcional com mapeamento de telas, fluxos E2E e validacao com Playwright' },
-    { name: 'dw-generate-pr', description: 'Gerar um Pull Request com descricao estruturada' },
-    { name: 'dw-help', description: 'Mostrar guia completo dos comandos e fluxos disponiveis' },
-    { name: 'dw-intel', description: 'Consultar inteligencia do codebase para entender padroes, convencoes e arquitetura' },
-    { name: 'dw-quick', description: 'Executar uma task pontual com garantias do workflow sem precisar de PRD completo' },
-    { name: 'dw-redesign-ui', description: 'Analisar, propor e implementar redesign de paginas/componentes frontend com integracao de design system' },
-    { name: 'dw-refactoring-analysis', description: 'Auditar codebase para code smells e oportunidades de refatoracao com relatorio priorizado' },
-    { name: 'dw-resume', description: 'Restaurar contexto da sessao e sugerir o proximo passo do workflow' },
-    { name: 'dw-review-implementation', description: 'Revisar se todos os requisitos do PRD foram implementados corretamente' },
-    { name: 'dw-revert-task', description: 'Reverter com seguranca os commits de uma task especifica com checks de dependencia' },
-    { name: 'dw-run-plan', description: 'Executar TODAS as tasks sequencialmente ate completar o plano' },
-    { name: 'dw-run-qa', description: 'Executar QA visual com automacao de browser, testes E2E e acessibilidade' },
-    { name: 'dw-run-task', description: 'Executar uma task com validacao e testes integrados' },
-    { name: 'dw-security-check', description: 'Check de seguranca rigido multi-camada (OWASP estatico + Trivy SCA/IaC + audit nativo) para projetos TS, Python, C# ou Rust' },
-    { name: 'dw-update', description: 'Atualizar o dev-workflow para a versao mais recente publicada no npm sem sair da sessao do agente' },
+    { name: 'dw-adr', description: 'Registra uma decisao arquitetural e os trade-offs aceitos, antes que se percam.' },
+    { name: 'dw-analyze-project', description: 'Escaneia o repo para aprender stack e convencoes, e escreve as regras que os outros commands usam.' },
+    { name: 'dw-autopilot', description: 'Pega um desejo e roda do PRD ao PR, parando so em tres gates de aprovacao.' },
+    { name: 'dw-brainstorm', description: 'Refina uma ideia usando as features existentes do produto como base, antes de qualquer PRD.' },
+    { name: 'dw-bugfix', description: 'Tria um bug, faz tres perguntas certas, e entao corrige ou redireciona para PRD.' },
+    { name: 'dw-code-review', description: 'Review Nivel 3 contra PRD, rules, testes e seguranca; gera um veredicto acionavel.' },
+    { name: 'dw-commit', description: 'Agrupa as mudancas por intencao e escreve mensagens Conventional Commits limpas.' },
+    { name: 'dw-create-prd', description: 'Escreve um PRD depois de fazer as perguntas que assombrariam o techspec depois.' },
+    { name: 'dw-create-tasks', description: 'Quebra PRD e techspec em tasks pequenas o suficiente para entregar uma de cada vez.' },
+    { name: 'dw-create-techspec', description: 'Traduz um PRD pronto em um techspec que o time consegue construir de fato.' },
+    { name: 'dw-deep-research', description: 'Pesquisa um topico em varias fontes, rastreia citacoes e marca o que nao confere.' },
+    { name: 'dw-fix-qa', description: 'Corrige bugs do QA e retesta com evidencia em screenshot ate ficarem estaveis.' },
+    { name: 'dw-functional-doc', description: 'Mapeia telas e fluxos em um dossie funcional, validado E2E com Playwright.' },
+    { name: 'dw-generate-pr', description: 'Faz push da branch e abre um PR com corpo explicando o que mudou e como testar.' },
+    { name: 'dw-help', description: 'Lista todos os commands e os fluxos que os conectam. Passe uma keyword para atalho contextual.' },
+    { name: 'dw-intel', description: 'Responde perguntas sobre o codebase usando suas proprias rules e intel como fonte.' },
+    { name: 'dw-quick', description: 'Roda uma mudanca pequena e bem definida com garantias do workflow, sem precisar de PRD.' },
+    { name: 'dw-redesign-ui', description: 'Audita uma pagina frontend, propoe direcoes de design que voce escolhe, e entrega o redesign.' },
+    { name: 'dw-refactoring-analysis', description: 'Cataloga code smells no vocabulario de Fowler e ranqueia por impacto, P0 a P3.' },
+    { name: 'dw-resume', description: 'Retoma de onde voce parou — le o PRD ativo, a ultima task, e diz qual o proximo passo.' },
+    { name: 'dw-review-implementation', description: 'Mapeia cada requisito do PRD ao codigo que o entrega, e lista o que ainda falta.' },
+    { name: 'dw-revert-task', description: 'Reverte os commits de uma task, mas so depois de checar que nada a frente depende dela.' },
+    { name: 'dw-run-plan', description: 'Roda todas as tasks pendentes em ordem, com review de PRD compliance no final.' },
+    { name: 'dw-run-qa', description: 'Pilota o browser para testar fluxo feliz, edge cases e acessibilidade, com screenshot.' },
+    { name: 'dw-run-task', description: 'Implementa uma task, roda a validacao que vem com ela, e commita quando passa.' },
+    { name: 'dw-security-check', description: 'Review OWASP + scan Trivy CVE/secret/IaC para TS, Python, C# ou Rust. CRITICAL ou HIGH bloqueia PR.' },
+    { name: 'dw-update', description: 'Atualiza o dev-workflow para o release mais recente no npm, com snapshot para rollback.' },
   ],
 };
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brunosps00/dev-workflow",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "description": "AI-driven development workflow commands for any project. Scaffolds a complete PRD-to-PR pipeline with multi-platform AI assistant support.",
   "bin": {
     "dev-workflow": "./bin/dev-workflow.js"

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

@@ -13,8 +13,10 @@ You are a brainstorming facilitator for the current workspace. This command exis
 
 ## Flags
 
-- **(default)**: normal brainstorm with 3-7 options (conservative, balanced, bold) and trade-offs
+- **(default)**: normal brainstorm with 3-7 options (conservative, balanced, bold) and trade-offs. If the product has PRDs or rules, a **Product Inventory** is produced automatically and each option carries a classification tag.
+- **`--onepager`**: at the end of the brainstorm, generate a durable one-pager at `.dw/spec/ideas/<slug>.md` (using `.dw/templates/idea-onepager.md`) with Feature Inventory + Classification & Rationale + MVP Scope + Not Doing + Assumptions. Use when you want a persisted product artifact before moving to `/dw-create-prd`.
 - **`--council`**: after the normal brainstorm, invoke the `dw-council` skill to stress-test the top 2-3 options via 3-5 archetypes (pragmatic-engineer, architect-advisor, security-advocate, product-mind, devils-advocate). Useful when the choice is high-impact and there is genuine dissent between paths.
+- Flags are composable: `--onepager --council` produces the one-pager after the council debate.
 
 ## Decision Flowchart: Brainstorm vs Direct PRD
 
@@ -46,6 +48,7 @@ When available in the project under `./.agents/skills/`, use these skills to enr
 ## Template Reference
 
 - Brainstorm matrix template: `.dw/templates/brainstorm-matrix.md` (relative to workspace root)
+- Durable one-pager template: `.dw/templates/idea-onepager.md` (used with `--onepager` flag)
 
 Use this command when the user wants to:
 - Generate ideas for product, UX, architecture, or automation
@@ -56,37 +59,57 @@ Use this command when the user wants to:
 
 ## Required Behavior
 
+<critical>The brainstorm is a **product-level** phase, not technical. DO NOT dive into architecture, stack, endpoints, schemas. That's the techspec's job. Here we work user journeys, value, features, and boundaries.</critical>
+
 1. Start by summarizing the problem in 1 to 3 sentences.
-2. If essential context is missing, ask short and objective questions before expanding.
-3. Structure the brainstorm into multiple directions, avoiding locking in too early on a single answer.
-4. For each direction, make explicit:
-   - Core idea
+2. **Reframe as "How Might We"**: turn the raw idea into `How might we [verb] for [user] so that [outcome]?`. This pulls the team out of premature "solution mode".
+3. **Product Inventory (required if the product exists)**:
+   - If `.dw/spec/prd-*/` has PRDs OR `.dw/rules/index.md` exists, read these artifacts to map the **current product's feature inventory** (product level, not code level).
+   - Sources to consult: `.dw/spec/prd-*/prd.md` (Overview / Main Features / User Stories sections), `.dw/rules/index.md` and `.dw/rules/<module>.md`, `.planning/intel/` if present.
+   - Produce a **short Feature Inventory (5-12 bullets)** before diverging: "the product today does X, Y, Z".
+   - If the project is greenfield (no PRDs or rules), record: "Feature Inventory: greenfield — no product artifacts yet".
+4. If essential context is missing for the user (problem, persona, expected value), ask short and objective questions before expanding.
+5. Structure the brainstorm into multiple directions, avoiding locking in too early on a single answer.
+6. For each direction (3-7), make explicit:
+   - **Required classification tag**: `[IMPROVES: <existing feature>]` | `[CONSOLIDATES: <feat A> + <feat B>]` | `[NEW]`
+   - Core idea (in product language — journey, value, boundary)
    - Benefits
    - Risks or limitations
    - Approximate effort level
-5. Whenever it makes sense, include conservative, balanced, and bold alternatives.
-6. If the topic involves the current workspace, use repository context to make the ideas more concrete.
-7. Close with a pragmatic recommendation and clear next steps.
+7. Whenever it makes sense, include conservative, balanced, and bold alternatives.
+8. Close with a pragmatic recommendation and clear next steps.
+9. **If the `--onepager` flag is present**: at the end, generate `.dw/spec/ideas/<slug>.md` using `.dw/templates/idea-onepager.md`, filling Feature Inventory, Classification & Rationale, Recommended Direction (product language), MVP Scope (user stories), Not Doing, Key Assumptions, and Open Questions. Report the path to the user.
 
 ## Preferred Response Format
 
-### 1. Framing
+### 1. How Might We
+- Reframed sentence
+
+### 2. Product Inventory
+- 5-12 bullets of mapped existing features (or "greenfield")
+
+### 3. Framing
 - Objective
 - Constraints
 - Decision criteria
 
-### 2. Options
-- Present 3 to 7 distinct options
+### 4. Options (matrix `brainstorm-matrix.md`)
+- 3 to 7 distinct options
+- Each option with `[IMPROVES] / [CONSOLIDATES] / [NEW]` tag
 - Avoid listing superficial variations of the same idea
 
-### 3. Convergence
+### 5. Convergence
 - Recommend 1 or 2 paths
 - Explain why they win in the current context
 
-### 4. Next Steps
+### 6. One-pager (if `--onepager`)
+- Path of the created file at `.dw/spec/ideas/<slug>.md`
+
+### 7. Next Steps
 - Short and actionable list
 - If appropriate, suggest which command to use next:
-  - `/dw-create-prd`
+  - `/dw-create-prd` (main successor; accepts the one-pager as input, reducing clarification questions)
+  - `/dw-quick` (if it's a small IMPROVES that fits in a single task, ≤3 files)
   - `/dw-create-techspec`
   - `/dw-create-tasks`
   - `/dw-bugfix`
@@ -113,8 +136,20 @@ Depending on the request, this command may produce:
 ## Closing
 
 At the end, always leave the user in one of these situations:
-- With a clear recommendation
+- With a clear recommendation (including an IMPROVES/CONSOLIDATES/NEW classification)
 - With better questions to decide
 - With a next workspace command to follow
+- With the one-pager at `.dw/spec/ideas/<slug>.md` (if `--onepager` was used)
+
+## Inspired by
+
+The codebase-grounded idea refinement pattern is inspired by [`addyosmani/agent-skills@idea-refine`](https://skills.sh/addyosmani/agent-skills/idea-refine) (Addy Osmani, Google — 1.4K+ installs). Adaptations for dev-workflow:
+
+- **Product level, not code level**: while `idea-refine` uses Glob/Grep/Read over `src/*`, here we read **PRDs + rules + intel** to map the **feature inventory** of the product. The brainstorm stays product-focused.
+- **Explicit classification** (IMPROVES / CONSOLIDATES / NEW) as dev-workflow-native discipline — forces the team to decide whether the idea is new, consolidates existing features, or improves one, before opening a PRD.
+- Output at `.dw/spec/ideas/<slug>.md` (sibling of `prd-<slug>/`) instead of `docs/ideas/` — preserves dev-workflow path conventions.
+- Integration with the existing pipeline: `/dw-create-prd` accepts the one-pager as input, reducing clarification questions.
+
+Credit: Addy Osmani and the `idea-refine` pattern.
 
 </system_instructions>

package/scaffold/en/commands/dw-create-prd.md

@@ -9,7 +9,15 @@
     - Do NOT use when requirements are still vague and unexplored (use `/dw-brainstorm` first)
 
     ## Pipeline Position
-    **Predecessor:** `/dw-brainstorm` (optional) | **Successor:** `/dw-create-techspec`
+    **Predecessor:** `/dw-brainstorm` (optional; may pass a one-pager as input) | **Successor:** `/dw-create-techspec`
+
+    ## One-pager as Input (optional)
+
+    If `.dw/spec/ideas/<slug>.md` exists (produced by `/dw-brainstorm --onepager`), **read it before asking questions**. The one-pager already provides: Problem Statement, product Feature Inventory, Classification (IMPROVES/CONSOLIDATES/NEW), Recommended Direction, MVP Scope, Not Doing, Key Assumptions, and Open Questions.
+
+    With a valid one-pager (all fields filled), **reduce the minimum clarification questions from 7 to 4** — focus only on remaining gaps (e.g., specific acceptance criteria, concrete success metrics, error flows, edge cases). DO NOT repeat questions already answered in the one-pager.
+
+    In the final PRD, add an "Idea Origin" section citing the one-pager and preserving the classification tag.
 
     ## Requirement Clarity Guide
 
@@ -71,6 +79,7 @@
     - What is NOT in scope
     - **Impacted projects** (consult `.dw/rules/index.md` to identify which systems are affected)
     - <critical>DO NOT GENERATE THE PRD WITHOUT FIRST ASKING AT LEAST 7 CLARIFICATION QUESTIONS</critical>
+    - <critical>**EXCEPTION**: If a one-pager at `.dw/spec/ideas/<slug>.md` was passed as input and all its fields are filled, the minimum drops to **4 questions** — focus on gaps (acceptance criteria, metrics, edge cases). DO NOT repeat questions already answered in the one-pager.</critical>
 
     ### 2. Plan (Required)
     Create a PRD development plan including:

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

@@ -26,6 +26,7 @@ You are a workspace help assistant. When invoked, present the user with a comple
 | decision, adr, architecture | `/dw-adr` | Record an Architecture Decision Record |
 | debate, council, stress-test, opinions | `/dw-brainstorm --council` or `/dw-create-techspec --council` | Invokes `dw-council` for a multi-advisor debate |
 | security, vulnerability, owasp, trivy, cve | `/dw-security-check` | Rigid multi-layer check (OWASP static + Trivy SCA/IaC + native audit) for TS/Python/C#/Rust |
+| refine, refinement, idea, one-pager | `/dw-brainstorm --onepager` | Idea refinement with Product Inventory + classification (IMPROVES/CONSOLIDATES/NEW) + durable one-pager |
 | revert, rollback task | `/dw-revert-task` | Safe revert with dependency checks |
 | hotfix, quick change | `/dw-quick` | One-off task with guarantees, no PRD |
 | resume, where I left off | `/dw-resume` | Restore previous session context |

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

@@ -7,6 +7,7 @@ You are a quick task executor. This command exists to implement one-off changes
 ## 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
+- Use when invoked after `/dw-brainstorm --onepager` and the one-pager carries `[IMPROVES]` classification with an MVP Scope fitting in ≤3 files (skip-PRD path)
 - Do NOT use for new features with multiple requirements (use `/dw-create-prd`)
 - Do NOT use for complex bugs (use `/dw-bugfix`)
 
@@ -28,13 +29,14 @@ You are a quick task executor. This command exists to implement one-off changes
 ## 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. Invoke `dw-verify` and include the VERIFICATION REPORT in the output before committing. Without PASS, DO NOT commit.
-8. Create atomic semantic commit with the change
+2. **If a one-pager exists** at `.dw/spec/ideas/<slug>.md` and was passed as input, read it first. If classification is `[IMPROVES]` and MVP Scope fits in ≤3 files, proceed. If `[NEW]` or `[CONSOLIDATES]` with larger scope, warn and redirect to `/dw-create-prd`.
+3. Summarize the change in 1-2 sentences and confirm scope with the user
+4. If the change seems too large (>3 files, >100 lines), warn and suggest `/dw-create-prd`
+5. Implement the change following project conventions
+6. Run relevant existing tests (unit, integration)
+7. Run lint if configured in the project
+8. Invoke `dw-verify` and include the VERIFICATION REPORT in the output before committing. Without PASS, DO NOT commit.
+9. Create atomic semantic commit with the change
 
 ## GSD Integration
 

package/scaffold/en/templates/brainstorm-matrix.md

@@ -4,16 +4,24 @@
 
 {{CONTEXT_DESCRIPTION}}
 
+## Product Inventory
+
+<!-- Existing product features mapped (product level, not code level). Fill in by reading .dw/spec/prd-*/prd.md and .dw/rules/index.md. If greenfield, write "greenfield". -->
+
+- **[feature 1]** — `.dw/spec/prd-<slug>/prd.md` — status
+- **[feature 2]** — `.dw/rules/index.md#module-Y`
+- ...
+
 ## Options Matrix
 
 | Criteria | Option A: {{NAME_A}} | Option B: {{NAME_B}} | Option C: {{NAME_C}} |
 |----------|----------------------|----------------------|----------------------|
-| **Approach** | | | |
+| **Type & Related Feature** | `[IMPROVES: <feat>]` \| `[CONSOLIDATES: <A>+<B>]` \| `[NEW]` | same | same |
+| **Approach (product)** | | | |
 | **Effort** | Low / Medium / High | Low / Medium / High | Low / Medium / High |
 | **Risk** | Low / Medium / High | Low / Medium / High | Low / Medium / High |
-| **Scalability** | | | |
-| **Maintainability** | | | |
-| **Dependencies** | | | |
+| **User value** | | | |
+| **Dependencies (on other features)** | | | |
 
 ## Trade-offs
 

package/scaffold/en/templates/idea-onepager.md

@@ -0,0 +1,90 @@
+---
+type: idea-onepager
+schema_version: "1.0"
+status: draft
+date: YYYY-MM-DD
+classification: improves | consolidates | new
+---
+
+# Idea: [Short, imperative title]
+
+## Problem Statement
+
+[Reframe the raw idea as a "How might we" sentence:
+**How might we** [verb] **for** [user/segment] **so that** [outcome/measurable value]?
+
+Focus on the problem, not the solution. Avoid jumping into "how to implement".]
+
+## Product Context (mapped existing features)
+
+[Inventory of product features relevant to this idea. **Product level, not code level.** List what the product already delivers today that relates to the idea.
+
+Sources:
+- PRDs in `.dw/spec/prd-*/prd.md` (features already delivered or in development)
+- `.dw/rules/index.md` (product overview)
+- `.planning/intel/` if GSD is installed
+
+Format:]
+
+- **[feature A name]** — `.dw/spec/prd-<slug>/prd.md` — status: live / in development
+- **[feature B name]** — `.dw/rules/index.md#module-Y` — status: live
+- **[feature C name]** — PRD in progress, see `tasks.md`
+
+> If the product is greenfield (no PRDs or rules yet), write: "Feature Inventory: greenfield — no product artifacts yet. This is the first recorded idea."
+
+## Classification & Rationale
+
+**Type:** IMPROVES | CONSOLIDATES | NEW
+
+[Pick ONE of the three and justify:]
+
+- **If IMPROVES** — which existing feature is being improved and why improving is worth more than creating a separate feature. Cite the original PRD.
+- **If CONSOLIDATES** — which features are being merged, the gain from unifying (more cohesive UX, less duplicate code, consolidated data). List the original PRDs that become "superseded" (or under review).
+- **If NEW** — why the product needs this capability now, where it connects to existing features (even new features are rarely fully isolated), and which gap it fills.
+
+## Recommended Direction
+
+[The recommended approach, 1 paragraph, in **product language**:
+- User journey (who does what, when, why)
+- Value delivered
+- Boundary (what this idea covers and what's explicitly out)
+
+**DO NOT write technical architecture here** — that's the techspec's job.]
+
+## MVP Scope
+
+[The smallest version that delivers real value. Thought in **user stories**, not technical tasks.
+
+- As a [persona], I can [action] so that [benefit]
+- As a [persona], I can [action] so that [benefit]
+
+Ideally 2-4 stories. If it's more than 5, it's probably not MVP.]
+
+## Not Doing (explicit)
+
+[Tempting items that landed OUT of scope — and why. Forces scope discipline:]
+
+- **[tempting item 1]** — reason: [out of scope because...]
+- **[tempting item 2]** — reason: [could become v2 if hypothesis X validates]
+
+## Key Assumptions to Validate
+
+[What must be true for this direction to work. Each assumption with a test — ideally **with a user**, not with code.]
+
+- **[assumption 1]** — test: [interview 5 users in segment X / market research / low-fidelity prototype]
+- **[assumption 2]** — test: [metric Y rises by Z% within 2 weeks of release]
+
+## Open Questions
+
+[Questions that don't yet have an answer and that the user (or stakeholder) must answer before the PRD:]
+
+- [Question 1 affecting scope]
+- [Question 2 affecting priority]
+
+## Next Step
+
+Pick ONE:
+
+- **`/dw-create-prd`** using this one-pager as input — when the direction is clear but we need to detail user stories, acceptance criteria, and hand off to techspec
+- **`/dw-quick`** — when it's an IMPROVES so small that it fits in a single task (up to 3 files, no new endpoint/screen)
+- **Stop here** — if any "Open Question" is blocking, stop and resolve with the stakeholder before advancing

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

@@ -13,8 +13,10 @@ Você é um facilitador de brainstorming para o workspace atual. Este comando ex
 
 ## Flags
 
-- **(padrão)**: brainstorm normal com 3-7 opções (conservadora, equilibrada, ousada) e trade-offs
+- **(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.
 
 ## Fluxograma de Decisão: Brainstorm vs PRD Direto
 
@@ -46,6 +48,7 @@ Quando disponíveis no projeto em `./.agents/skills/`, use para enriquecer a ide
 ## 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`)
 
 Use este comando quando o usuario quiser:
 - gerar ideias para produto, UX, arquitetura ou automacao
@@ -56,37 +59,57 @@ Use este comando quando o usuario quiser:
 
 ## Comportamento obrigatorio
 
+<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>
+
 1. Comece resumindo o problema em 1 a 3 frases.
-2. Se faltar contexto essencial, faca perguntas curtas e objetivas antes de expandir.
-3. Estruture o brainstorming em multiplas direcoes, evitando fixar cedo demais em uma unica resposta.
-4. Para cada direcao, explicite:
-   - ideia central
-   - beneficios
-   - riscos ou limitacoes
-   - nivel de esforco aproximado
-5. Sempre que fizer sentido, inclua alternativas conservadora, equilibrada e ousada.
-6. Se o tema envolver o workspace atual, use contexto do repositorio para deixar as ideias mais concretas.
-7. Feche com recomendacao pragmatica e proximos passos claros.
+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)**:
+   - Se `.dw/spec/prd-*/` tem PRDs OU `.dw/rules/index.md` existe, leia esses artefatos para mapear o **inventário de features do produto atual** (nível de produto, não de código).
+   - Fontes a consultar: `.dw/spec/prd-*/prd.md` (seções Overview / Main Features / User Stories), `.dw/rules/index.md` e `.dw/rules/<modulo>.md`, `.planning/intel/` se existir.
+   - Produza um **Feature Inventory curto (5-12 bullets)** antes de divergir: "o produto hoje faz X, Y, Z".
+   - Se o projeto é greenfield (sem PRDs nem rules), registre: "Feature Inventory: greenfield — nenhum artefato de produto ainda".
+4. Se faltar contexto essencial para o usuário (problema, persona, valor esperado), faça perguntas curtas e objetivas antes de expandir.
+5. Estruture o brainstorming em multiplas direcoes, evitando fixar cedo demais em uma unica resposta.
+6. Para cada direção (3-7), explicite:
+   - **Tag de classificação obrigatória**: `[IMPROVES: <feature existente>]` | `[CONSOLIDATES: <feat A> + <feat B>]` | `[NEW]`
+   - ideia central (em linguagem de produto — jornada, valor, fronteira)
+   - benefícios
+   - riscos ou limitações
+   - 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.
 
 ## Formato de resposta preferido
 
-### 1. Enquadramento
+### 1. How Might We
+- frase reformulada
+
+### 2. Product Inventory
+- 5-12 bullets de features existentes mapeadas (ou "greenfield")
+
+### 3. Enquadramento
 - objetivo
 - restricoes
 - criterios de decisao
 
-### 2. Opcoes
-- apresente de 3 a 7 opcoes distintas
-- evite listar variacoes superficiais da mesma ideia
+### 4. Opções (matriz `brainstorm-matrix.md`)
+- 3 a 7 opções distintas
+- cada opção com tag `[IMPROVES] / [CONSOLIDATES] / [NEW]`
+- evite listar variações superficiais da mesma ideia
 
-### 3. Convergencia
+### 5. Convergência
 - recomende 1 ou 2 caminhos
 - diga por que eles vencem no contexto atual
 
-### 4. Proximos passos
+### 6. One-pager (se `--onepager`)
+- 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`
+  - `/dw-create-prd` (principal sucessor; aceita one-pager como input reduzindo perguntas de clarificação)
+  - `/dw-quick` (se é IMPROVES pequeno que cabe em task única, ≤3 arquivos)
   - `/dw-create-techspec`
   - `/dw-create-tasks`
   - `/dw-bugfix`
@@ -113,8 +136,20 @@ Dependendo do pedido, o comando pode produzir:
 ## Encerramento
 
 Ao final, sempre deixe o usuario em uma destas situacoes:
-- com uma recomendacao clara
+- 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)
+
+## Inspired by
+
+O padrão de codebase-grounded idea refinement é inspirado em [`addyosmani/agent-skills@idea-refine`](https://skills.sh/addyosmani/agent-skills/idea-refine) (Addy Osmani, Google — 1.4K+ installs). Adaptações para o dev-workflow:
+
+- **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.
+
+Crédito: Addy Osmani e o padrão `idea-refine`.
 
 </system_instructions>

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

@@ -9,7 +9,15 @@
     - NÃO use quando os requisitos ainda estão vagos e inexplorados (use `/dw-brainstorm` primeiro)
 
     ## Posição no Pipeline
-    **Antecessor:** `/dw-brainstorm` (opcional) | **Sucessor:** `/dw-create-techspec`
+    **Antecessor:** `/dw-brainstorm` (opcional; pode passar one-pager como input) | **Sucessor:** `/dw-create-techspec`
+
+    ## One-pager como Input (opcional)
+
+    Se existir `.dw/spec/ideas/<slug>.md` produzido por `/dw-brainstorm --onepager`, **leia-o antes de fazer perguntas**. O one-pager já traz: Problem Statement, Feature Inventory do produto, Classification (IMPROVES/CONSOLIDATES/NEW), Recommended Direction, MVP Scope, Not Doing, Key Assumptions e Open Questions.
+
+    Com um one-pager válido (todos os campos preenchidos), **reduza o mínimo de perguntas de clarificação de 7 para 4** — foque apenas em lacunas remanescentes (ex: acceptance criteria específicos, métricas de sucesso concretas, fluxos de erro, edge cases). NÃO repita perguntas já respondidas no one-pager.
+
+    No PRD final, adicionar seção "Origem da Ideia" citando o one-pager e preservando a classification tag.
 
     ## Guia de Clareza de Requisitos
 
@@ -71,6 +79,7 @@
     - O que NÃO está no escopo
     - **Projetos impactados** (consulte `.dw/rules/index.md` para identificar quais sistemas são afetados)
     - <critical>NÃO GERE O PRD SEM ANTES FAZER NO MINIMO 7 PERGUNTAS DE CLARIFICAÇÃO</critical>
+    - <critical>**EXCEÇÃO**: Se um one-pager `.dw/spec/ideas/<slug>.md` foi passado como input e tem todos os campos preenchidos, o mínimo cai para **4 perguntas** — foque em lacunas (acceptance criteria, métricas, edge cases). NÃO repita perguntas já respondidas no one-pager.</critical>
 
     ### 2. Planejar (Obrigatório)
     Crie um plano de desenvolvimento do PRD incluindo:

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

@@ -26,6 +26,7 @@ Você é um assistente de ajuda do workspace. Quando invocado, apresente ao usu
 | decisão, adr, arquitetura | `/dw-adr` | Registrar Architecture Decision Record |
 | debate, council, stress-test, opiniões | `/dw-brainstorm --council` ou `/dw-create-techspec --council` | Invoca `dw-council` para debate multi-advisor |
 | security, segurança, vulnerabilidade, owasp, trivy, cve | `/dw-security-check` | Check multi-camada rígido (OWASP estático + Trivy SCA/IaC + audit nativo) para TS/Python/C#/Rust |
+| refinamento, refine, idea, one-pager, ideia | `/dw-brainstorm --onepager` | Refinamento de ideia com Product Inventory + classification (IMPROVES/CONSOLIDATES/NEW) + one-pager durável |
 | reverter, rollback de task | `/dw-revert-task` | Revert seguro com check de dependências |
 | hotfix, mudança rápida | `/dw-quick` | Task pontual com garantias sem PRD |
 | retomar, onde parei | `/dw-resume` | Restaura contexto da sessão anterior |

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

@@ -7,6 +7,7 @@ Voce e um executor de tasks rapidas. Este comando existe para implementar mudanc
 ## Quando Usar
 - Use para mudancas pequenas que nao justificam o pipeline completo (PRD -> TechSpec -> Tasks)
 - Use para hotfixes, ajustes de config, atualizacoes de dependencias, refatoracoes pontuais
+- Use quando invocado apos `/dw-brainstorm --onepager` e o one-pager tem classificacao `[IMPROVES]` com MVP Scope cabendo em ≤3 arquivos (skip-PRD path)
 - NAO use para features novas com multiplos requisitos (use `/dw-create-prd`)
 - NAO use para bugs complexos (use `/dw-bugfix`)
 
@@ -28,13 +29,14 @@ Voce e um executor de tasks rapidas. Este comando existe para implementar mudanc
 ## Comportamento Obrigatorio
 
 1. Leia `.dw/rules/` para entender padroes e convencoes do projeto
-2. Resuma a mudanca em 1-2 frases e confirme escopo com o usuario
-3. Se a mudanca parecer grande demais (>3 arquivos, >100 linhas), alerte e sugira `/dw-create-prd`
-4. Implemente a mudanca seguindo convencoes do projeto
-5. Execute testes existentes relevantes (unit, integration)
-6. Execute lint se configurado no projeto
-7. Invoque `dw-verify` e inclua o VERIFICATION REPORT no output antes de commitar. Sem PASS, NAO commit.
-8. Crie commit atomico semantico com a mudanca
+2. **Se um one-pager existe** em `.dw/spec/ideas/<slug>.md` e foi passado como input, leia-o primeiro. Se classification for `[IMPROVES]` e MVP Scope cabe em ≤3 arquivos, prosseguir. Se for `[NEW]` ou `[CONSOLIDATES]` de escopo maior, alertar e redirecionar para `/dw-create-prd`.
+3. Resuma a mudanca em 1-2 frases e confirme escopo com o usuario
+4. Se a mudanca parecer grande demais (>3 arquivos, >100 linhas), alerte e sugira `/dw-create-prd`
+5. Implemente a mudanca seguindo convencoes do projeto
+6. Execute testes existentes relevantes (unit, integration)
+7. Execute lint se configurado no projeto
+8. Invoque `dw-verify` e inclua o VERIFICATION REPORT no output antes de commitar. Sem PASS, NAO commit.
+9. Crie commit atomico semantico com a mudanca
 
 ## Integracao GSD
 

package/scaffold/pt-br/templates/brainstorm-matrix.md

@@ -4,16 +4,24 @@
 
 {{CONTEXT_DESCRIPTION}}
 
+## Product Inventory
+
+<!-- Features existentes mapeadas no produto (nível de produto, não de código). Preencher lendo .dw/spec/prd-*/prd.md e .dw/rules/index.md. Se greenfield, escrever "greenfield". -->
+
+- **[feature 1]** — `.dw/spec/prd-<slug>/prd.md` — status
+- **[feature 2]** — `.dw/rules/index.md#modulo-Y`
+- ...
+
 ## Matriz de Opções
 
 | Critério | Opção A: {{NAME_A}} | Opção B: {{NAME_B}} | Opção C: {{NAME_C}} |
 |----------|---------------------|---------------------|---------------------|
-| **Abordagem** | | | |
+| **Tipo & Feature Relacionada** | `[IMPROVES: <feat>]` \| `[CONSOLIDATES: <A>+<B>]` \| `[NEW]` | idem | idem |
+| **Abordagem (produto)** | | | |
 | **Esforço** | Baixo / Médio / Alto | Baixo / Médio / Alto | Baixo / Médio / Alto |
 | **Risco** | Baixo / Médio / Alto | Baixo / Médio / Alto | Baixo / Médio / Alto |
-| **Escalabilidade** | | | |
-| **Manutenibilidade** | | | |
-| **Dependências** | | | |
+| **Valor para usuário** | | | |
+| **Dependências (outras features)** | | | |
 
 ## Trade-offs
 

package/scaffold/pt-br/templates/idea-onepager.md

@@ -0,0 +1,90 @@
+---
+type: idea-onepager
+schema_version: "1.0"
+status: draft
+date: YYYY-MM-DD
+classification: improves | consolidates | new
+---
+
+# Ideia: [Título curto e imperativo]
+
+## Problem Statement
+
+[Reformule a ideia bruta como uma frase "How might we":
+**How might we** [verbo] **para** [usuário/segmento] **de forma que** [resultado/valor mensurável]?
+
+Foque no problema, não na solução. Evite entrar em "como implementar".]
+
+## Product Context (features existentes mapeadas)
+
+[Inventário das features do produto relevantes para esta ideia. **Nível de produto, não de código.** Liste o que o produto já entrega hoje que se relaciona com a ideia.
+
+Fontes:
+- PRDs em `.dw/spec/prd-*/prd.md` (features já entregues ou em desenvolvimento)
+- `.dw/rules/index.md` (overview do produto)
+- `.planning/intel/` se GSD estiver instalado
+
+Formato:]
+
+- **[nome da feature A]** — `.dw/spec/prd-<slug>/prd.md` — status: live / em desenvolvimento
+- **[nome da feature B]** — `.dw/rules/index.md#modulo-Y` — status: live
+- **[nome da feature C]** — PRD em progresso, ver `tasks.md`
+
+> Se o produto é greenfield (sem PRDs nem rules), escreva: "Feature Inventory: greenfield — nenhum artefato de produto ainda. Esta é a primeira ideia registrada."
+
+## Classification & Rationale
+
+**Tipo:** IMPROVES | CONSOLIDATES | NEW
+
+[Escolha UM dos três e justifique:]
+
+- **Se IMPROVES** — qual feature existente está sendo aprimorada e por quê aprimorar vale mais do que criar feature separada. Cite o PRD original da feature.
+- **Se CONSOLIDATES** — quais features se fundem, o ganho ao unificar (UX mais coesa, menos código duplicado, dados consolidados). Liste os PRDs originais que ficam "superseded" (ou em revisão).
+- **Se NEW** — por que o produto precisa dessa capacidade agora, onde ela se conecta às features existentes (mesmo sendo nova, raramente está completamente isolada), e qual gap ela preenche.
+
+## Recommended Direction
+
+[A abordagem recomendada, 1 parágrafo, em **linguagem de produto**:
+- Jornada do usuário (quem faz o quê, quando, por quê)
+- Valor entregue
+- Boundary (o que essa ideia cobre e o que fica de fora)
+
+**NÃO escreva arquitetura técnica aqui** — isso é trabalho do techspec.]
+
+## MVP Scope
+
+[A menor versão que entrega valor real. Pensada em **user stories**, não tasks técnicas.
+
+- Como [persona], eu posso [ação] para [benefício]
+- Como [persona], eu posso [ação] para [benefício]
+
+Idealmente 2-4 stories. Se são mais de 5, provavelmente não é MVP.]
+
+## Not Doing (explícito)
+
+[Itens tentadores que ficaram FORA do escopo — e por quê. Força disciplina de scope:]
+
+- **[item tentador 1]** — razão: [fora de escopo porque...]
+- **[item tentador 2]** — razão: [pode virar v2 se hipótese X validar]
+
+## Key Assumptions to Validate
+
+[O que precisa ser verdade para essa direção funcionar. Cada assumption com um teste — idealmente **com usuário**, não com código.]
+
+- **[assumption 1]** — teste: [entrevista com 5 usuários do segmento X / pesquisa de mercado / protótipo de baixa fidelidade]
+- **[assumption 2]** — teste: [métrica Y aumenta em Z% em 2 semanas após release]
+
+## Open Questions
+
+[Questões que ainda não têm resposta e que o usuário (ou stakeholder) precisa responder antes do PRD:]
+
+- [Pergunta 1 que afeta escopo]
+- [Pergunta 2 que afeta prioridade]
+
+## Next Step
+
+Escolha UM:
+
+- **`/dw-create-prd`** com este one-pager como input — quando a direção está clara mas precisamos detalhar user stories, acceptance criteria e passar ao techspec
+- **`/dw-quick`** — quando é um IMPROVES tão pequeno que cabe em task única (até 3 arquivos, sem novo endpoint/tela)
+- **Parar aqui** — se alguma "Open Question" é bloqueante, parar e resolver com stakeholder antes de avançar

package/scaffold/skills/dw-council/SKILL.md

@@ -1,13 +1,6 @@
 ---
 name: dw-council
-description: |
-  Orchestrates a multi-advisor debate (3-5 archetypes) to stress-test
-  high-stakes product, architecture, or scope decisions. Uses parallel
-  subagents with steel-manning, concession tracking, and dissent-preserving
-  synthesis. Invoked opt-in via `--council` flag from dw-brainstorm and
-  dw-create-techspec, or standalone when the user explicitly needs a
-  rigorous debate. Do not use for small decisions, routine implementation,
-  or when a single answer is already obvious.
+description: Multi-advisor debate (3-5 archetypes) with steel-manning and dissent preserved, for high-stakes product or architecture calls.
 allowed-tools:
   - Read
   - Task

package/scaffold/skills/dw-memory/SKILL.md

@@ -1,13 +1,6 @@
 ---
 name: dw-memory
-description: |
-  Maintains workflow-scoped memory for dev-workflow PRD runs using
-  .dw/spec/prd-<name>/MEMORY.md (shared) and .dw/spec/prd-<name>/tasks/<N>_memory.md
-  (task-local). Use when a dev-workflow command needs to persist or recall
-  durable cross-task context (decisions, constraints, risks) across task
-  executions. Invoked from dw-run-task, dw-run-plan, dw-autopilot, and
-  dw-resume. Do not use for PR review remediation, user preferences, or
-  event-log summarization.
+description: Two-tier workflow memory (shared + per-task) with promotion test, so cross-task context survives without bloating files.
 allowed-tools:
   - Read
   - Write

package/scaffold/skills/dw-review-rigor/SKILL.md

@@ -1,12 +1,6 @@
 ---
 name: dw-review-rigor
-description: |
-  Applies review discipline to code-review and analysis commands:
-  de-duplicates issues, orders by severity, verifies intent before flagging,
-  prioritizes signal over volume, and skips concerns that linters already
-  catch. Invoked from dw-code-review, dw-review-implementation, and
-  dw-refactoring-analysis. Do not use for fetching reviews from external
-  providers or for executing fixes.
+description: Five rules for review output — dedupe, severity-order, verify intent, skip linter noise, prefer signal over volume.
 allowed-tools:
   - Read
   - Grep

package/scaffold/skills/dw-verify/SKILL.md

@@ -1,11 +1,6 @@
 ---
 name: dw-verify
-description: |
-  Enforces fresh verification evidence before any completion, fix, or passing
-  claim — and before commits or PR creation. Use when a dev-workflow command
-  is about to report success, hand off work, or commit code. Invoked from
-  dw-run-task, dw-run-plan, dw-fix-qa, dw-bugfix, dw-code-review, dw-generate-pr,
-  and dw-quick. Do not use for early planning or brainstorming.
+description: Demands fresh verification evidence before any success claim or commit. No PASS report, no claim — no exceptions.
 allowed-tools:
   - Bash
   - Read