@brunosps00/dev-workflow 0.15.0 → 1.0.0

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

@@ -15,18 +15,18 @@ A step that invokes a `/dw-xxx` command is ONLY considered complete when the art
 | Thought | Reality |
 |---------|---------|
 | "I already ran the tests manually" | The command produces structured artifacts. Run the command. |
-| "I validated via ad-hoc Playwright" | `/dw-run-qa` requires RF matrix, bugs.md, screenshots, scripts, logs, checklist. Run the command. |
-| "The implementation is obviously correct" | `/dw-review-implementation` requires a compliance matrix per RF/endpoint/task. Run the command. |
+| "I validated via ad-hoc Playwright" | `/dw-qa` requires RF matrix, bugs.md, screenshots, scripts, logs, checklist. Run the command. |
+| "The implementation is obviously correct" | `/dw-review --coverage-only` requires a compliance matrix per RF/endpoint/task. Run the command. |
 | "A strong manual validation is enough" | NO. Technical equivalence DOES NOT replace formal execution. |
 | "I already checked build and lint, that's enough" | Build/lint DO NOT replace review nor QA. Run the commands. |
-| "I wrote a summarized qa-report.md by hand" | A loose file IS NOT execution of `/dw-run-qa`. The full `QA/` tree is mandatory. |
+| "I wrote a summarized qa-report.md by hand" | A loose file IS NOT execution of `/dw-qa`. The full `QA/` tree is mandatory. |
 | "The autopilot already advanced, I don't need to go back" | If the artifact doesn't exist, the step didn't run. Go back and execute. |
-| "I fixed bugs along the way, so QA is already ok" | Fixing bugs does not replace running formal QA. Run `/dw-run-qa`. |</critical>
+| "I fixed bugs along the way, so QA is already ok" | Fixing bugs does not replace running formal QA. Run `/dw-qa`. |</critical>
 
 ## When to Use
 - Use when you want to go from an idea to a PR with minimal manual intervention
 - Use for complete features that go through the entire pipeline (research, planning, execution, quality)
-- Do NOT use for small, well-scoped one-off tasks — use `/dw-run-task` directly with a quick PRD instead
+- Do NOT use for small, well-scoped one-off tasks — use `/dw-run` directly with a quick PRD instead
 - Do NOT use to fix bugs (use `/dw-bugfix`)
 - Do NOT use when you want manual control between each phase (use individual commands)
 
@@ -72,12 +72,12 @@ If this command is re-invoked on the same PRD after interruption:
 
 - Query `.dw/intel/` via `/dw-intel` to understand project context
 - Identify: tech stack, existing patterns, related features
-- If `.dw/intel/` is absent, suggest running `/dw-map-codebase` first for richer downstream context
+- If `.dw/intel/` is absent, suggest running `/dw-intel --build` first for richer downstream context
 
 ### Step 2: Research (Conditional)
 
 Evaluate whether the topic requires deep research:
-- **YES** (run `/dw-deep-research`): new technology for the project, unknown domain, external API integrations, critical architectural decisions
+- **YES** (run `/dw-brainstorm --research`): new technology for the project, unknown domain, external API integrations, critical architectural decisions
 - **NO** (skip to step 3): simple feature in an already mapped domain, refactoring existing code, basic CRUD
   - If skipping, DOCUMENT the reason in the progress block. E.g.: "Research skipped — domain already mapped in .dw/rules/[file].md". The user must see the justification.
 
@@ -94,7 +94,7 @@ Run `/dw-brainstorm` with accumulated context (intel + research).
 
 <critical>The PRD MUST include an interactive interview with the user. Ask AT LEAST 7 clarification questions BEFORE writing the PRD. Do NOT answer questions automatically based on context — the user MUST respond.</critical>
 
-Run `/dw-create-prd` using brainstorm findings.
+Run `/dw-plan prd` using brainstorm findings.
 - Follow ALL command instructions, especially the clarification questions section
 - Ask at least 7 questions about: problem, target users, critical features, scope, constraints, design, integration
 - In each question, present a recommendation grounded in brainstorm and deep-research findings (if executed). E.g.: "Based on the research, I recommend X because [evidence]. Do you agree or prefer a different direction?"
@@ -115,7 +115,7 @@ Present to the user:
 
 <critical>The TechSpec MUST include an interactive interview with the user. Ask AT LEAST 7 technical clarification questions BEFORE writing the TechSpec. Do NOT answer questions automatically — the user MUST respond.</critical>
 
-Run `/dw-create-techspec` from the approved PRD.
+Run `/dw-plan techspec` from the approved PRD.
 - Follow ALL command instructions, especially the clarification questions section
 - Ask at least 7 questions about: preferred architecture, existing vs new libs, testing strategy, integration with existing systems, infrastructure constraints, performance, security
 - In each question, present a technical recommendation grounded in brainstorm, deep-research, and approved PRD findings. E.g.: "Research indicated lib X has better performance for this case [source]. Want to use X or have another preference?"
@@ -125,7 +125,7 @@ Run `/dw-create-techspec` from the approved PRD.
 
 ### Step 6: Tasks
 
-Run `/dw-create-tasks` from PRD + TechSpec.
+Run `/dw-plan tasks` from PRD + TechSpec.
 - Follow all command instructions
 - Generate individual tasks in `.dw/spec/prd-[name]/`
 
@@ -148,9 +148,9 @@ Evaluate whether tasks involve frontend:
 
 ### Step 8: Execution
 
-Run `/dw-run-plan` with the PRD path.
+Run `/dw-run` with the PRD path.
 - Follow ALL command instructions, including the native plan-checker gate (PASS required) and wave-based parallel execution via the bundled `dw-execute-phase` skill agents
-- Each task follows `/dw-run-task` with Level 1 validation
+- Each task follows `/dw-run` with Level 1 validation
 
 ### Step 9: Implementation Review (Loop)
 
@@ -164,7 +164,7 @@ Run the project's build and lint:
 5. Repeat until both build AND lint pass without errors
 6. Only then proceed to the review
 
-Run `/dw-review-implementation` to verify PRD compliance (Level 2).
+Run `/dw-review --coverage-only` to verify PRD compliance (Level 2).
 - If gaps found: fix automatically and re-run the review
 - Maximum 3 correction cycles
 - Do NOT advance to QA until the review passes
@@ -177,7 +177,7 @@ A short text review, a "looks good", or a conclusion "implementation is correct"
 
 ### Step 10: Visual QA
 
-Run `/dw-run-qa` with Playwright MCP.
+Run `/dw-qa` with Playwright MCP.
 - Test happy paths, edge cases, negative flows, accessibility
 - Document bugs with screenshots
 
@@ -188,12 +188,12 @@ Run `/dw-run-qa` with Playwright MCP.
 - `{{PRD_PATH}}/QA/screenshots/` — directory exists and contains at least 1 PNG per RF tested (format `RF-XX-[slug]-PASS.png` or `-FAIL.png`)
 - `{{PRD_PATH}}/QA/scripts/` — directory exists and contains Playwright `.spec.ts`/`.spec.js` scripts per RF
 - `{{PRD_PATH}}/QA/logs/` — directory exists with captured console/network logs
-Running Playwright ad-hoc, taking a few loose screenshots, or writing a short qa-report.md by hand DOES NOT replace this structure. If any artifact is missing or incomplete, the command did NOT run — invoke `/dw-run-qa` formally and follow its flow to completion.</critical>
+Running Playwright ad-hoc, taking a few loose screenshots, or writing a short qa-report.md by hand DOES NOT replace this structure. If any artifact is missing or incomplete, the command did NOT run — invoke `/dw-qa` formally and follow its flow to completion.</critical>
 
 ### Step 11: Fix QA (Conditional)
 
 If QA found bugs:
-- Run `/dw-fix-qa` to fix and retest
+- Run `/dw-qa --fix` to fix and retest
 - Loop until stable (maximum 5 cycles). After 5 cycles, STOP and ask the user how to proceed.
 
 ### Step 12: Implementation Review (Post-QA)
@@ -205,7 +205,7 @@ Run the project's build and lint (same sequence as Step 9):
 2. Build
 3. If any fail: fix and re-run until they pass
 
-Run `/dw-review-implementation` again to confirm QA fixes did not break PRD compliance.
+Run `/dw-review --coverage-only` again to confirm QA fixes did not break PRD compliance.
 - If gaps found: fix and re-run
 - Maximum 3 cycles
 
@@ -213,7 +213,7 @@ Run `/dw-review-implementation` again to confirm QA fixes did not break PRD comp
 
 ### Step 13: Code Review
 
-Run `/dw-code-review` (Level 3) for formal review.
+Run `/dw-review --code-only` (Level 3) for formal review.
 - Generate persisted report
 
 ### Step 14: Commit
@@ -227,7 +227,7 @@ Run `ls` on each path below and confirm existence. If ANY is missing, DO NOT com
 - `{{PRD_PATH}}/QA/screenshots/` (non-empty)
 - `{{PRD_PATH}}/QA/scripts/` (non-empty with `.spec.*` files)
 - `{{PRD_PATH}}/QA/logs/`
-- Evidence of the last `/dw-review-implementation` run with RF-by-RF matrix (session output or reference in `autopilot-state.json`)
+- Evidence of the last `/dw-review --coverage-only` run with RF-by-RF matrix (session output or reference in `autopilot-state.json`)
 
 Also verify `autopilot-state.json`:
 - Every step 1 through 13 that is NOT in `skipped_steps` must be in `completed_steps`
@@ -250,7 +250,7 @@ Ask the user: **"Commits completed. Do you want to generate the Pull Request?"**
 
 ## Native Engine
 
-The autopilot relies on dev-workflow-native infrastructure for codebase intelligence (`/dw-map-codebase` + `/dw-intel`) and bundled phase execution agents (plan-checker + executor in `.agents/skills/dw-execute-phase/agents/`). All bundled and require no external dependencies. See the `dw-codebase-intel` and `dw-execute-phase` bundled skills under `.agents/skills/` for details.
+The autopilot relies on dev-workflow-native infrastructure for codebase intelligence (`/dw-intel --build` + `/dw-intel`) and bundled phase execution agents (plan-checker + executor in `.agents/skills/dw-execute-phase/agents/`). All bundled and require no external dependencies. See the `dw-codebase-intel` and `dw-execute-phase` bundled skills under `.agents/skills/` for details.
 
 ## State Persistence
 

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

@@ -9,14 +9,16 @@ You are a brainstorming facilitator for the current workspace. This command exis
 - Do NOT use when you already have clear requirements ready for a PRD, or when you need to implement code
 
 ## Pipeline Position
-**Predecessor:** (user idea) | **Successor:** `/dw-create-prd`
+**Predecessor:** (user idea) | **Successor:** `/dw-plan prd`
 
 ## Flags
 
 - **(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`.
+- **`--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-plan 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.
+- **`--research`**: heavyweight multi-source research mode. Pipeline: scope → plan → retrieve (parallel sources) → triangulate → outline-refine → synthesize → critique → refine → report. Output: cited research document. Use for state-of-the-art reviews, technology comparisons, regulatory landscape mapping. Sub-modes: `quick` (3 phases, 2-5min), `standard` (default, 6 phases, 5-10min), `deep` (8 phases, 10-20min), `ultradeep` (8+ phases, 20-45min).
+- **`--refactor`**: code-smell catalog mode. Audits a target directory or PRD scope for code smells using Martin Fowler's taxonomy (bloaters, change preventers, dispensables, couplers, conditional complexity, DRY violations). Maps each smell to a concrete refactoring technique with before/after sketches. Severity-ordered P0-P3 plan. Output: refactoring opportunities document.
+- Flags are composable where it makes sense: `--onepager --council` produces the one-pager after the council debate. `--research --onepager` saves the research output as a durable one-pager. `--refactor --onepager` saves the refactor plan as a durable one-pager. `--research --refactor` is NOT supported (pick one or the other — different ideation surfaces).
 
 ## Decision Flowchart: Brainstorm vs Direct PRD
 
@@ -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 this command when the user wants to:
 ### 7. Next Steps
 - Short and actionable list
 - If appropriate, suggest which command to use next:
-  - `/dw-create-prd` (main successor; accepts the one-pager as input, reducing clarification questions)
-  - `/dw-run-task` (if it's a small IMPROVES that fits in a single task with a quick PRD)
-  - `/dw-create-techspec`
-  - `/dw-create-tasks`
+  - `/dw-plan prd` (main successor; accepts the one-pager as input, reducing clarification questions)
+  - `/dw-run` (if it's a small IMPROVES that fits in a single task with a quick PRD)
+  - `/dw-plan techspec`
+  - `/dw-plan tasks`
   - `/dw-bugfix`
 
 ## Heuristics
@@ -140,6 +142,155 @@ At the end, always leave the user in one of these situations:
 - 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)
+- With the research report at `~/Documents/<Topic>_Research_<date>/` (if `--research`)
+- With the refactor plan at `<target>/refactor-plan.md` (if `--refactor`)
+
+## Mode: `--research` (multi-source research)
+
+Activated by the `--research` flag. Replaces the default brainstorm with a structured research pipeline that produces a cited document with verified claims.
+
+<critical>Every factual claim MUST be cited immediately with [N] in the same sentence</critical>
+<critical>NEVER fabricate citations — if no source is found, say so explicitly</critical>
+<critical>The bibliography MUST contain EVERY citation used in the body, no abbreviations or ranges</critical>
+
+### When to use research mode
+- Multi-source comparisons (e.g., "compare React Server Components vs Astro Islands").
+- State-of-the-art reviews of a topic.
+- Regulatory or industry context mapping.
+- Decisions needing cited evidence (not just an opinion).
+- Do NOT use research mode for simple lookups, debugging, or questions answerable in 1-2 web searches.
+
+### Sub-modes (research depth)
+
+```
+Selection
+├── Initial exploration → quick (3 phases, 2-5 min)
+├── Standard research → standard (6 phases, 5-10 min) [DEFAULT for --research]
+├── Critical decision → deep (8 phases, 10-20 min)
+└── Comprehensive review → ultradeep (8+ phases, 20-45 min)
+```
+
+### Required reading
+
+Complementary skill **`dw-source-grounding`**: **ALWAYS** — apply Detect → Fetch → Implement → Cite protocol with strict source hierarchy (official versioned docs > changelogs > web standards > compat tables; Stack Overflow / blogs / training data are discovery only). Every finding ends with `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`; bibliography built from these citations.
+
+### Pipeline phases
+
+**Phase 1 — SCOPE** | Frame the question. Decompose into core components. Identify stakeholder perspectives. Define scope boundaries. List key assumptions to validate.
+
+**Phase 2 — PLAN** | Identify primary + secondary sources. Map knowledge dependencies. Create search strategy with variants. Plan triangulation approach. Define quality gates.
+
+**Phase 3 — RETRIEVE** | Parallel information gathering. Decompose into 5-10 independent search angles (semantic, keyword, date-filtered, academic, alternative perspectives, statistics, industry analysis, critical analysis). Execute ALL searches in parallel via multiple tool calls in a single message. First Finish Search pattern: proceed when first threshold reached (quick: 10+ sources avg credibility >60/100; standard: 15+ >60; deep: 25+ >70; ultradeep: 30+ >75).
+
+**Phase 4 — TRIANGULATE** | Identify claims requiring verification. Cross-check facts across 3+ independent sources. Flag contradictions. Document verification status per claim.
+
+**Phase 5 — OUTLINE REFINEMENT** | Compare initial scope to actual findings. Adapt structure based on evidence. Targeted searches to fill gaps.
+
+**Phase 6 — SYNTHESIZE** | Identify cross-source patterns. Map concept relationships. Generate insights beyond source material. Build evidence hierarchies.
+
+**Phase 7 — CRITIQUE** (deep/ultradeep only) | Review logical consistency. Verify citation completeness. Identify gaps or weaknesses. Simulate 2-3 critic personas.
+
+**Phase 8 — REFINE** (deep/ultradeep) | Strengthen weak arguments. Add missing perspectives. Resolve contradictions.
+
+**Phase 9 — PACKAGE** | Generate report progressively, section by section.
+
+### Output
+
+Saved to `~/Documents/<Topic>_Research_<YYYYMMDD>/`. Mandatory sections:
+1. Executive Summary (200-400 words)
+2. Introduction (scope, methodology, assumptions)
+3. Main Analysis (4-8 findings, 600-2000 words each, all cited)
+4. Synthesis and Insights
+5. Limitations and Caveats
+6. Recommendations
+7. Bibliography (COMPLETE — every citation, no placeholders)
+8. Methodological Appendix
+
+Target lengths: quick 2-4k words; standard 4-8k; deep 8-15k; ultradeep 15-20k+.
+
+### Quality standards
+- Narrative: flowing prose, beginning/middle/end. Min 80% prose, max 20% bullets.
+- Each factual statement cited immediately with [N].
+- Distinguish fact from synthesis.
+- No vague attributions ("studies show...", "experts believe..." without citation).
+- Label speculation explicitly.
+- Admit uncertainty: "No sources found for X."
+
+## Mode: `--refactor` (code-smell catalog)
+
+Activated by the `--refactor` flag. Audits a target codebase area for refactoring opportunities using Martin Fowler's smell taxonomy.
+
+<critical>ASK EXACTLY 3 CLARIFICATION QUESTIONS BEFORE STARTING THE ANALYSIS</critical>
+
+### When to use refactor mode
+- Pre-implementation audit of tech debt in the area you're about to touch.
+- Quarterly code-health review.
+- Pre-migration scoping (e.g., before a framework upgrade).
+- Do NOT use refactor mode if `/dw-review` already flagged the same area (avoid duplicate findings).
+
+### Required reading
+
+Complementary skills:
+- **`dw-review-rigor`**: **ALWAYS** — applies de-duplication (same smell in N files = 1 entry with affected list), severity ordering P0-P3, signal-over-volume (max ~20 findings; keep criticals, prune marginal ones). Smells with a justifying ADR drop to `low` at most.
+- **`dw-simplification`**: **ALWAYS** — every flagged smell is filtered through Chesterton's Fence (what does the construct DO, why was it added, what breaks if removed). Smells with no clear "why-was-it-there" answer get downgraded to `info` with a research note instead of a refactor proposal. Complexity metrics (cognitive complexity ≥16 or nesting depth ≥4 = `high` candidate; <10 = `low` at most) anchor severity.
+- **`security-review`**: defer security concerns to this skill — do not duplicate.
+- **`vercel-react-best-practices`** + its `perf-discipline.md`: defer React/Next.js performance patterns to this skill.
+
+### Pipeline
+
+1. Three clarification questions (scope, priorities, constraints).
+2. Identify the target area (PRD-scoped directory, specific module, or whole codebase).
+3. Scan for smells using Fowler's taxonomy:
+   - **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** — high cyclomatic/cognitive, deep nesting.
+4. Apply `dw-review-rigor` de-duplication + `dw-simplification` Chesterton filter.
+5. For each surviving smell, map to a refactoring technique with before/after sketches.
+6. Severity-order P0-P3 (impact × likelihood × maintenance cost).
+7. Plus: coupling/cohesion metrics, SOLID analysis.
+
+### Output
+
+Saved to `<target>/refactor-plan.md`:
+
+```markdown
+# Refactoring Opportunities — <target>
+
+## Summary
+- Smells found: N (after de-dup)
+- P0 (do this sprint): N
+- P1 (this quarter): N
+- P2 (when convenient): N
+- P3 (informational): N
+
+## Findings (severity-ordered)
+
+### P0 — <smell name>
+**Files:** <list> (de-duplicated)
+**Symptom:** <description>
+**Why fix:** <impact analysis>
+**Suggested refactor:** <Fowler technique>
+**Before:** <code sketch>
+**After:** <code sketch>
+**Effort:** S / M / L
+**Risk:** Low / Medium / High
+**Tests required:** <list>
+
+...
+```
+
+### Analysis tools
+- React projects: `npx react-doctor@latest --verbose` for health score.
+- Angular projects: `ng lint` for static issues.
+
+### Anti-patterns
+- Listing every cyclomatic complexity hit > threshold without context → noise.
+- Suggesting "extract method" everywhere a function is over N lines → mechanical, not insight.
+- Proposing refactors that aren't tested or testable → high risk, won't ship.
+- Ignoring documented architectural decisions in `.dw/rules/` → flagging intentional design as smell.
 
 ## Inspired by
 
@@ -148,7 +299,7 @@ The codebase-grounded idea refinement pattern is inspired by [`addyosmani/agent-
 - **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.
+- Integration with the existing pipeline: `/dw-plan prd` accepts the one-pager as input, reducing clarification questions.
 
 Credit: Addy Osmani and the `idea-refine` pattern.
 

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

@@ -5,8 +5,8 @@
 
     ## When to Use
     - Use when fixing a reported bug with automatic triage to distinguish bug vs feature vs excessive scope
-    - Do NOT use when implementing a new feature (use `/dw-create-prd` instead)
-    - Do NOT use when fixing bugs found during QA testing (use `/dw-fix-qa` instead)
+    - Do NOT use when implementing a new feature (use `/dw-plan prd` instead)
+    - Do NOT use when fixing bugs found during QA testing (use `/dw-qa --fix` instead)
 
     ## Pipeline Position
     **Predecessor:** (bug report) | **Successor:** `/dw-commit` then `/dw-generate-pr`
@@ -48,7 +48,7 @@
     In this mode:
     1. Follow the normal question and analysis flow
     2. Instead of executing, generate a document at `.dw/spec/dw-bugfix-[name]/prd.md`
-    3. The file is named `prd.md` to maintain compatibility with the create-techspec/dw-create-tasks pipeline
+    3. The file is named `prd.md` to maintain compatibility with the create-techspec/dw-plan tasks pipeline
     4. Then the user can run `create-techspec .dw/spec/dw-bugfix-[name]`
     5. And then `create-tasks .dw/spec/dw-bugfix-[name]`
 
@@ -109,7 +109,7 @@
     ---
 
     **Do you want me to start the PRD creation flow?**
-    - `yes` - I will follow `.dw/commands/dw-create-prd.md` for this feature
+    - `yes` - I will follow `.dw/commands/dw-plan prd.md` for this feature
     - `no, it's a bug` - Explain further why you consider it a bug
     - `no, cancel` - End
 
@@ -361,7 +361,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/en/commands/dw-commit.md

@@ -7,7 +7,7 @@
     - Do NOT use when creating a PR (use `/dw-generate-pr` instead)
 
     ## Pipeline Position
-    **Predecessor:** `/dw-run-task` or `/dw-bugfix` | **Successor:** `/dw-generate-pr`
+    **Predecessor:** `/dw-run` or `/dw-bugfix` | **Successor:** `/dw-generate-pr`
 
     ## Complementary Skills
 

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

@@ -16,12 +16,12 @@ This command is **complementary** to `/dw-new-project`:
 - You want a `--prod` Dockerfile distinct from your `--dev` setup, with proper multi-stage builds and non-root users
 - Onboarding a teammate to a project where local-dev "just works" via `docker compose up`
 - NOT for scaffolding a new project — use `/dw-new-project`
-- NOT for vulnerability scanning Dockerfiles — `/dw-security-check` covers Trivy IaC scanning of Dockerfile/compose
+- NOT for vulnerability scanning Dockerfiles — `/dw-secure-audit` covers Trivy IaC scanning of Dockerfile/compose
 - NOT for orchestration (k8s manifests, helm charts) — out of scope; the report can include notes pointing to those tools
 
 ## Pipeline Position
 
-**Predecessor:** any project with a manifest (`package.json`, `pyproject.toml`, `*.csproj`, `Cargo.toml`) | **Successor:** `/dw-security-check` (run Trivy on the new Dockerfile + compose), `/dw-deps-audit` (audit deps before baking them into a production image)
+**Predecessor:** any project with a manifest (`package.json`, `pyproject.toml`, `*.csproj`, `Cargo.toml`) | **Successor:** `/dw-secure-audit` (run Trivy on the new Dockerfile + compose), `/dw-secure-audit --plan` (audit deps before baking them into a production image)
 
 ## Complementary Skills
 
@@ -58,7 +58,7 @@ Detect language(s), framework, package manager, runtime infra deps, and existing
 
 #### 0.1 Language matrix
 
-Same matrix as `/dw-security-check` and `/dw-deps-audit`:
+Same matrix as `/dw-secure-audit` and `/dw-secure-audit --plan`:
 
 | Language | Indicators |
 |----------|------------|
@@ -273,9 +273,9 @@ Sections:
 7. **Audit Findings** (only `--audit` mode) — table of issues with severity, file:line, recommendation.
 8. **Next Steps:**
    - For `--dev`: `cp .env.example .env` (if missing), `docker compose -f docker-compose.dev.yml up -d`, then smoke test the app.
-   - For `--prod`: build the image locally first (`docker build -t <name>:dev .`), run `/dw-security-check` on the Dockerfile and compose, then push to registry.
+   - For `--prod`: build the image locally first (`docker build -t <name>:dev .`), run `/dw-secure-audit` on the Dockerfile and compose, then push to registry.
    - For `--audit`: apply suggested fixes manually or run with `--mode=force-overwrite`.
-   - Always: run `/dw-deps-audit` against the project before promoting the image to production.
+   - Always: run `/dw-secure-audit --plan` against the project before promoting the image to production.
 
 ## Flags
 
@@ -309,13 +309,13 @@ Sections:
 
 ## Integration With Other dw-* Commands
 
-- **`/dw-security-check`** — run AFTER `--prod` generation to scan the new Dockerfile + compose with Trivy IaC.
-- **`/dw-deps-audit`** — run BEFORE `--prod` generation to ensure no vulnerable deps go into the image.
+- **`/dw-secure-audit`** — run AFTER `--prod` generation to scan the new Dockerfile + compose with Trivy IaC.
+- **`/dw-secure-audit --plan`** — run BEFORE `--prod` generation to ensure no vulnerable deps go into the image.
 - **`/dw-new-project`** — sister command. `/dw-new-project` bakes Docker in from day one; `/dw-dockerize` retrofits it. They share the `docker-compose-recipes` skill.
-- **`/dw-fix-qa`** — if a generated `Dockerfile.dev` causes hot-reload to break, `/dw-fix-qa` can iterate fixes with the user.
+- **`/dw-qa --fix`** — if a generated `Dockerfile.dev` causes hot-reload to break, `/dw-qa --fix` can iterate fixes with the user.
 
 ## Inspired by
 
-`dw-dockerize` is dev-workflow-native. The detection layer reuses the language matrix from `/dw-security-check` and `/dw-deps-audit`. The brainstorm layer borrows the three-option (Conservative/Balanced/Bold) discipline from `/dw-brainstorm` and applies it to base-image choice. The audit layer reuses `security-review/infrastructure/docker.md` for OWASP-aligned checks. The compose composition is delegated to the `docker-compose-recipes` bundled skill (shared with `/dw-new-project`).
+`dw-dockerize` is dev-workflow-native. The detection layer reuses the language matrix from `/dw-secure-audit` and `/dw-secure-audit --plan`. The brainstorm layer borrows the three-option (Conservative/Balanced/Bold) discipline from `/dw-brainstorm` and applies it to base-image choice. The audit layer reuses `security-review/infrastructure/docker.md` for OWASP-aligned checks. The compose composition is delegated to the `docker-compose-recipes` bundled skill (shared with `/dw-new-project`).
 
 </system_instructions>

package/scaffold/en/commands/dw-find-skills.md

@@ -15,7 +15,7 @@ You are an agent skills discovery helper for this workspace. Your job is to help
 
 ## Pipeline Position
 
-**Predecessor:** any exploratory question | **Successor:** none (independent flow). If no skill is found, fall back to `/dw-brainstorm` (idea exploration) or `/dw-run-task` (small one-off task) when applicable.
+**Predecessor:** any exploratory question | **Successor:** none (independent flow). If no skill is found, fall back to `/dw-brainstorm` (idea exploration) or `/dw-run` (small one-off task) when applicable.
 
 ## Complementary Skills
 
@@ -81,7 +81,7 @@ Browse skills at: https://skills.sh/
    - Acknowledge no match was found, no fabrication
    - Offer to help directly with general capabilities
    - Suggest `/dw-brainstorm` if the user wants to explore options before building it themselves
-   - Suggest `/dw-run-task` if the request fits a small one-off change (≤ 3 files, no PRD)
+   - Suggest `/dw-run` if the request fits a small one-off change (≤ 3 files, no PRD)
    - Mention `npx skills init <name>` as a path to author the missing skill
 
 ## Common Skill Categories
@@ -128,7 +128,7 @@ I searched for skills related to "<query>" and didn't find a strong match
 
 I can still help directly with general capabilities. Or:
   /dw-brainstorm "<your idea>"   — if you want to explore approaches first
-  /dw-run-task "<small change>"  — if it's a tiny change that fits one task (write quick PRD first)
+  /dw-run "<small change>"  — if it's a tiny change that fits one task (write quick PRD first)
   npx skills init <name>         — if this would be valuable as a reusable skill
 ```
 
@@ -150,7 +150,7 @@ I can still help directly with general capabilities. Or:
 `dw-find-skills` ports the `find-skills` skill (from the Claude superpowers bundle, `~/.agents/skills/find-skills/SKILL.md`) into a `dw-*` workflow command so every supported platform (Claude Code, Codex, Copilot, OpenCode) gets the same discovery on-ramp. Adaptations for dev-workflow:
 
 - Pipeline integration: `/dw-help <keyword>` routes here when the keyword matches `skill`/`find skill`/`install skill`/`extend agent`.
-- Fallback to `/dw-brainstorm` or `/dw-run-task` when no skill matches — keeps the user inside the workflow instead of dumping them empty-handed.
+- Fallback to `/dw-brainstorm` or `/dw-run` when no skill matches — keeps the user inside the workflow instead of dumping them empty-handed.
 - Explicit scope question (`-g` vs local) before installing, instead of always installing globally.
 
 Credit: the `find-skills` skill from the Claude superpowers ecosystem and the `npx skills` / [skills.sh](https://skills.sh/) project.

package/scaffold/en/commands/dw-functional-doc.md

@@ -3,7 +3,7 @@ You are an assistant specialized in mapping real functionalities of screens, flo
 
 ## When to Use
 - Use when mapping screens, flows, or modules into a comprehensive functional dossier with E2E test coverage and optional video tours
-- Do NOT use when only running QA tests against existing requirements (use `/dw-run-qa`)
+- Do NOT use when only running QA tests against existing requirements (use `/dw-qa`)
 - Do NOT use when the project has not been set up yet
 
 ## Pipeline Position

package/scaffold/en/commands/dw-generate-pr.md

@@ -4,10 +4,10 @@ You are an assistant specialized in creating well-documented Pull Requests. Your
 ## When to Use
 - Use when creating a Pull Request from a feature or bugfix branch to main/develop
 - Do NOT use when changes are not yet committed (use `/dw-commit` first)
-- Do NOT use when code review has not been done (use `/dw-code-review` first)
+- Do NOT use when code review has not been done (use `/dw-review --code-only` first)
 
 ## Pipeline Position
-**Predecessor:** `/dw-code-review` or `/dw-commit` | **Successor:** (merge)
+**Predecessor:** `/dw-review --code-only` or `/dw-commit` | **Successor:** (merge)
 
 ## Complementary Skills
 
@@ -15,11 +15,11 @@ You are an assistant specialized in creating well-documented Pull Requests. Your
 |-------|---------|
 | `dw-verify` | **ALWAYS** — invoked before `git push`. Without a VERIFICATION REPORT PASS in the current session AFTER the last code edit, the PR **CANNOT** be created. |
 | `dw-git-discipline` | **ALWAYS** — validates branch naming (`<type>/<scope>` kebab-case), atomic-commit history (each commit single-intent, conventional message), branch lifetime (flag if >7 days old), and PR scope (suggest split if diff > ~400 lines). PR description follows summary + test plan structure, not a `git log` dump. |
-| `/dw-security-check` | **ALWAYS for TS/Python/C#/Rust projects** — `security-check.md` with status ≠ REJECTED is required for supported-language projects. |
+| `/dw-secure-audit` | **ALWAYS for TS/Python/C#/Rust projects** — `security-check.md` with status ≠ REJECTED is required for supported-language projects. |
 
 <critical>Hard gate 1 (verify): if the current session has no VERIFICATION REPORT PASS from `dw-verify` produced AFTER the last edit/commit, STOP and invoke `dw-verify` before proceeding. A PR is a permanent artifact — it demands the highest verification standard.</critical>
 
-<critical>Hard gate 2 (security): for TS/Python/C#/Rust projects, if `{{PRD_PATH}}/security-check.md` is missing OR has REJECTED status, STOP and invoke `/dw-security-check` before proceeding. HIGH/CRITICAL vulnerabilities CANNOT reach the PR. For other languages (Go, Java, etc.), this gate is skipped with a note.</critical>
+<critical>Hard gate 2 (security): for TS/Python/C#/Rust projects, if `{{PRD_PATH}}/security-check.md` is missing OR has REJECTED status, STOP and invoke `/dw-secure-audit` before proceeding. HIGH/CRITICAL vulnerabilities CANNOT reach the PR. For other languages (Go, Java, etc.), this gate is skipped with a note.</critical>
 
 ## Usage