@brunosps00/dev-workflow 0.13.0 → 1.0.0

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

@@ -94,12 +94,12 @@ services: []
 
 ## Escopo MVP
 
-[A primeira feature menor que voce vai entregar. Pensada como user stories — vai dirigir a primeira rodada de /dw-create-prd.]
+[A primeira feature menor que voce vai entregar. Pensada como user stories — vai dirigir a primeira rodada de /dw-plan prd.]
 
 - Como [persona], eu posso [acao] para que [beneficio]
 - Como [persona], eu posso [acao] para que [beneficio]
 
-Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholder e roda o /dw-create-prd quando tiver.
+Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholder e roda o /dw-plan prd quando tiver.
 
 ## Nao Estou Fazendo (explicito)
 
@@ -115,7 +115,7 @@ Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholde
 
 ## Perguntas em Aberto
 
-[O que este one-pager nao consegue responder sozinho. Resolva antes do /dw-create-prd ou escale para um stakeholder.]
+[O que este one-pager nao consegue responder sozinho. Resolva antes do /dw-plan prd ou escale para um stakeholder.]
 
 - [pergunta 1]
 - [pergunta 2]
@@ -124,6 +124,6 @@ Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholde
 
 Escolha UM:
 
-- **`/dw-create-prd`** — quando voce tem a primeira feature em mente e quer rascunhar o PRD em cima deste stack
+- **`/dw-plan prd`** — quando voce tem a primeira feature em mente e quer rascunhar o PRD em cima deste stack
 - **`/dw-analyze-project`** — apos primeiro commit substancial, para enriquecer `.dw/rules/` com convencoes por modulo
-- **`/dw-deps-audit --scan-only`** — para confirmar que nenhuma dep vulneravel veio dos templates `create-*`
+- **`/dw-secure-audit --plan --scan-only`** — para confirmar que nenhuma dep vulneravel veio dos templates `create-*`

package/scaffold/pt-br/templates/tasks-template.md

@@ -34,7 +34,7 @@ feat/prd-[nome-funcionalidade]
 ## Workflow
 
 Cada task segue o fluxo:
-1. `/dw-run-task [N]_task.md` - Implementa a task
+1. `/dw-run [N]_task.md` - Implementa a task
 2. Testes unitários incluídos na implementação
 3. Commit ao final da task (sem push)
 4. Próxima task ou `/dw-generate-pr [branch-alvo]` quando todas concluídas

package/scaffold/skills/api-testing-recipes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: api-testing-recipes
-description: Validated API-testing snippets (.http, pytest+httpx, supertest, WebApplicationFactory, reqwest) used by /dw-run-qa and /dw-fix-qa when the project has no UI. Default format is .http (REST Client) for IDE portability.
+description: Use for API testing recipes (.http, pytest+httpx, supertest, WebApplicationFactory, reqwest). Invoked by /dw-qa in API mode and when authoring API tests. Default format is .http for IDE portability.
 allowed-tools:
   - Read
   - Write
@@ -10,7 +10,7 @@ allowed-tools:
 
 # api-testing-recipes
 
-Curated library of **API-testing snippets** that `/dw-run-qa` and `/dw-fix-qa` use when a project is API-only (no Playwright). Each recipe is a ready-to-customize block per stack; the default is `.http` (REST Client) for maximum portability across IDEs.
+Curated library of **API-testing snippets** that `/dw-qa` and `/dw-qa --fix` use when a project is API-only (no Playwright). Each recipe is a ready-to-customize block per stack; the default is `.http` (REST Client) for maximum portability across IDEs.
 
 ## Why a skill (not inline)
 
@@ -22,14 +22,14 @@ Curated library of **API-testing snippets** that `/dw-run-qa` and `/dw-fix-qa` u
 
 Read this skill when:
 
-- `/dw-run-qa` detected API mode (no UI deps in the manifest) or was invoked with `--api`.
-- `/dw-fix-qa` is retesting a bug whose `evidence_type` is `api-log`.
+- `/dw-qa` detected API mode (no UI deps in the manifest) or was invoked with `--api`.
+- `/dw-qa --fix` is retesting a bug whose `evidence_type` is `api-log`.
 - Generating a baseline test suite from an OpenAPI spec.
 - Authoring contract checks against a backend.
 
 Do NOT use when:
 
-- The project has a UI and `/dw-run-qa` is in UI mode → use Playwright MCP instead.
+- The project has a UI and `/dw-qa` is in UI mode → use Playwright MCP instead.
 - The user wants browser-level acceptance (forms, navigation, accessibility) — that's Playwright territory.
 
 ## Available Recipes
@@ -49,7 +49,7 @@ Picking order:
 
 ## How to Compose
 
-The composing command (`/dw-run-qa` API mode) follows this loop:
+The composing command (`/dw-qa` API mode) follows this loop:
 
 1. **Pick the recipe** based on the rules above.
 2. **Read the recipe file** (`recipes/<name>.md`) for the variable conventions, test-matrix shape, and an example block.

package/scaffold/skills/api-testing-recipes/references/auth-patterns.md

@@ -135,4 +135,4 @@ Add one env var per role; the recipe reads them as needed. Tests that don't need
 
 ## What `dw-run-qa` does
 
-In API mode, `/dw-run-qa` reads `QA/test-credentials.md` (or `.env`) for the env var names, picks the recipe, and substitutes variables at test-generation time. The script files reference `@variable` references only — never raw tokens.
+In API mode, `/dw-qa` reads `QA/test-credentials.md` (or `.env`) for the env var names, picks the recipe, and substitutes variables at test-generation time. The script files reference `@variable` references only — never raw tokens.

package/scaffold/skills/api-testing-recipes/references/matrix-conventions.md

@@ -65,4 +65,4 @@ That's 9 test cases for one RF — the floor for a real API surface, not the cei
 
 ## How `dw-run-qa` uses this
 
-When in API mode, `/dw-run-qa` walks each `RF-XX` in the PRD, runs through this matrix, and emits PASS/FAIL per RF — not per test case. A single FAIL in any tier marks the RF as FAIL and lands a `BUG-NN` entry pointing to the failing log line.
+When in API mode, `/dw-qa` walks each `RF-XX` in the PRD, runs through this matrix, and emits PASS/FAIL per RF — not per test case. A single FAIL in any tier marks the RF as FAIL and lands a `BUG-NN` entry pointing to the failing log line.

package/scaffold/skills/api-testing-recipes/references/openapi-driven.md

@@ -1,6 +1,6 @@
 # OpenAPI-driven mode — generating tests from a spec
 
-When the project exposes an OpenAPI spec (static `openapi.yaml`/`openapi.json`, or dynamic `/openapi.json` for FastAPI), `/dw-run-qa` can derive a baseline test suite directly from it. This catches contract drift between code and spec for free.
+When the project exposes an OpenAPI spec (static `openapi.yaml`/`openapi.json`, or dynamic `/openapi.json` for FastAPI), `/dw-qa` can derive a baseline test suite directly from it. This catches contract drift between code and spec for free.
 
 ## When to use this mode
 
@@ -20,13 +20,13 @@ The generated tests live alongside hand-written ones in `{{PRD_PATH}}/QA/scripts
 
 ## How to run it
 
-`/dw-run-qa --from-openapi <spec-path-or-url>` — explicit. The `<spec-path-or-url>` can be:
+`/dw-qa --from-openapi <spec-path-or-url>` — explicit. The `<spec-path-or-url>` can be:
 
 - `./openapi.yaml`
 - `http://localhost:3000/openapi.json` (FastAPI default)
 - `http://localhost:3000/swagger/v1/swagger.json` (ASP.NET Core default)
 
-Without the flag, `/dw-run-qa` auto-detects:
+Without the flag, `/dw-qa` auto-detects:
 
 - File at repo root: `openapi.yaml`, `openapi.json`, `swagger.yaml`, `swagger.json`.
 - Project running locally: `GET /openapi.json`, `GET /swagger/v1/swagger.json`, `GET /api-docs`.

package/scaffold/skills/docker-compose-recipes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: docker-compose-recipes
-description: Validated docker-compose service blocks (postgres, redis, mailhog, minio, meilisearch, jaeger, traefik, etc.) for dev and prod, composed by /dw-new-project and /dw-dockerize. Each service is a standalone YAML with healthcheck, named volume, and env conventions.
+description: Use for docker-compose service blocks (postgres, redis, mailhog, minio, meilisearch, jaeger, traefik). Invoked by /dw-new-project, /dw-dockerize, or when composing dev/prod compose files.
 allowed-tools:
   - Read
   - Write

package/scaffold/skills/dw-codebase-intel/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dw-codebase-intel
-description: Codebase intelligence for dev-workflow. The intel-updater agent maintains a queryable index in .dw/intel/ (stack.json, files.json, apis.json, deps.json, arch.md) that other commands read instead of doing expensive codebase exploration. Used by /dw-intel and /dw-map-codebase. Adapted from get-shit-done-cc (MIT).
+description: Use to query or build codebase intel (.dw/intel/ — stack, files, apis, deps, arch). Powers /dw-intel queries and /dw-intel --build. Invoke on 'where is X', 'what uses Y', or after refactors.
 allowed-tools:
   - Read
   - Write
@@ -11,7 +11,7 @@ allowed-tools:
 
 # dw-codebase-intel
 
-Bundled skill that gives dev-workflow native **codebase intelligence** — a queryable knowledge base of the project's stack, file graph, API surface, dependencies, and architecture. Other commands (`/dw-create-prd`, `/dw-create-techspec`, `/dw-code-review`, `/dw-refactoring-analysis`, `/dw-brainstorm`, etc.) read from this index instead of re-exploring the codebase on every invocation.
+Bundled skill that gives dev-workflow native **codebase intelligence** — a queryable knowledge base of the project's stack, file graph, API surface, dependencies, and architecture. Other commands (`/dw-plan prd`, `/dw-plan techspec`, `/dw-review --code-only`, `/dw-brainstorm --refactor`, `/dw-brainstorm`, etc.) read from this index instead of re-exploring the codebase on every invocation.
 
 ## Why a skill (not inline)
 
@@ -23,7 +23,7 @@ Bundled skill that gives dev-workflow native **codebase intelligence** — a que
 
 Read this skill when:
 
-- `/dw-map-codebase` is invoked (full or partial codebase analysis).
+- `/dw-intel --build` is invoked (full or partial codebase analysis).
 - `/dw-intel "<query>"` is invoked (query existing intel).
 - `/dw-analyze-project` runs after first commit and wants to enrich `.dw/rules/` with structural facts from `.dw/intel/`.
 - Any other `dw-*` command wants to look up "where is X used", "what frameworks are in this stack", "what's the architecture pattern" without re-scanning files.
@@ -53,25 +53,25 @@ Schemas are documented in `references/intel-format.md`.
 
 | Agent | Responsibility | Spawn from |
 |-------|----------------|------------|
-| `agents/intel-updater.md` | Reads source files, writes structured intel to `.dw/intel/`. Supports `full` or `partial --files <paths>` updates. | `/dw-map-codebase` |
+| `agents/intel-updater.md` | Reads source files, writes structured intel to `.dw/intel/`. Supports `full` or `partial --files <paths>` updates. | `/dw-intel --build` |
 
 This skill ships ONE agent — `intel-updater` — which produces machine-readable JSON for `/dw-intel` queries. Human-readable architecture analysis (per-module conventions, anti-patterns, code smells) lives in `.dw/rules/` and is generated by `/dw-analyze-project`. The two are complementary: `.dw/intel/` answers "what's in this codebase right now?" and `.dw/rules/` answers "how should we write code here?".
 
 ## How to Compose (the typical flow)
 
-1. **`/dw-map-codebase`** is invoked.
+1. **`/dw-intel --build`** is invoked.
 2. The command spawns `intel-updater` with `focus: full` (first run) or `focus: partial --files <paths>` (incremental).
 3. The agent reads source files (using Glob/Read/Grep; no Bash file listing for cross-platform safety) and writes the 5 intel files.
 4. The agent writes `.last-refresh.json` with timestamps + hashes for incremental change detection on the next run.
-5. `/dw-map-codebase` reports completion and invites the user to query via `/dw-intel "<question>"`.
+5. `/dw-intel --build` reports completion and invites the user to query via `/dw-intel "<question>"`.
 
-For human-readable analysis (architecture overview, module conventions, anti-patterns), run `/dw-analyze-project` after `/dw-map-codebase` — it reads `.dw/intel/` as input and produces `.dw/rules/`.
+For human-readable analysis (architecture overview, module conventions, anti-patterns), run `/dw-analyze-project` after `/dw-intel --build` — it reads `.dw/intel/` as input and produces `.dw/rules/`.
 
 ## How `/dw-intel` Reads This
 
 `/dw-intel "auth flow"` does:
 
-1. Check `.dw/intel/.last-refresh.json` — is the index fresh (within last 7 days)? If stale, suggest re-running `/dw-map-codebase`.
+1. Check `.dw/intel/.last-refresh.json` — is the index fresh (within last 7 days)? If stale, suggest re-running `/dw-intel --build`.
 2. Search `apis.json` for matching paths/descriptions.
 3. Search `files.json` for matching exports.
 4. Search `arch.md` (full-text) for the keyword.
@@ -95,7 +95,7 @@ If no `.dw/intel/` exists at all, `/dw-intel` falls back to `.dw/rules/` (seeded
 - `references/intel-format.md` — schema for each `.dw/intel/` file with examples.
 - `references/incremental-update.md` — how partial updates work (which files to re-read, how to merge with existing entries).
 - `references/query-patterns.md` — how `/dw-intel` answers different question shapes (where-is, what-uses, architecture-of, dependency-of).
-- `references/api-design-discipline.md` — Hyrum's Law, contract-first design, error semantics, boundary validation, versioning. Use when intel feeds techspec authoring (`/dw-create-techspec`) for endpoints — design must respect existing project conventions surfaced in `apis.json`. Adapted from [`addyosmani/agent-skills/api-design`](https://github.com/addyosmani/agent-skills/tree/main/api-design) (MIT).
+- `references/api-design-discipline.md` — Hyrum's Law, contract-first design, error semantics, boundary validation, versioning. Use when intel feeds techspec authoring (`/dw-plan techspec`) for endpoints — design must respect existing project conventions surfaced in `apis.json`. Adapted from [`addyosmani/agent-skills/api-design`](https://github.com/addyosmani/agent-skills/tree/main/api-design) (MIT).
 
 ## Inspired by
 

package/scaffold/skills/dw-codebase-intel/agents/intel-updater.md

@@ -26,7 +26,7 @@ This ensures project-specific patterns, conventions, and best practices are appl
 # dw-intel-updater
 
 <role>
-You are **dw-intel-updater**, the codebase intelligence agent for dev-workflow. You read project source files and write structured intel to `.dw/intel/`. Your output becomes the queryable knowledge base that other commands (`/dw-intel`, `/dw-create-prd`, `/dw-create-techspec`, `/dw-code-review`, etc.) use instead of doing expensive codebase exploration reads.
+You are **dw-intel-updater**, the codebase intelligence agent for dev-workflow. You read project source files and write structured intel to `.dw/intel/`. Your output becomes the queryable knowledge base that other commands (`/dw-intel`, `/dw-plan prd`, `/dw-plan techspec`, `/dw-review --code-only`, etc.) use instead of doing expensive codebase exploration reads.
 
 ## Core Principle
 
@@ -42,15 +42,15 @@ Write machine-parseable, evidence-based intelligence. Every claim references act
 <upstream_input>
 ## Upstream Input
 
-### From `/dw-map-codebase` Command
+### From `/dw-intel --build` Command
 
-- **Spawned by:** `/dw-map-codebase` command
+- **Spawned by:** `/dw-intel --build` command
 - **Receives:** Focus directive — either `full` (all 5 files) or `partial --files <paths>` (update specific file entries only)
 - **Input format:** Spawn prompt with `focus: full|partial` directive and project root path
 
 ### Trigger gate
 
-`/dw-map-codebase` confirms the command is enabled and the project has source files before spawning this agent. Proceed directly to Step 1.
+`/dw-intel --build` confirms the command is enabled and the project has source files before spawning this agent. Proceed directly to Step 1.
 </upstream_input>
 
 ## Project Scope

package/scaffold/skills/dw-codebase-intel/references/api-design-discipline.md

@@ -135,4 +135,4 @@ If `.dw/intel/apis.json` shows a strong existing pattern (e.g., all endpoints us
 
 ## Integration with dev-workflow
 
-Use this discipline when authoring techspecs (`/dw-create-techspec`) or refactoring API surfaces. Cite `apis.json` evidence in the techspec — "existing endpoints use cursor pagination (apis.json:42); this endpoint follows the same pattern."
+Use this discipline when authoring techspecs (`/dw-plan techspec`) or refactoring API surfaces. Cite `apis.json` evidence in the techspec — "existing endpoints use cursor pagination (apis.json:42); this endpoint follows the same pattern."

package/scaffold/skills/dw-codebase-intel/references/incremental-update.md

@@ -9,15 +9,15 @@ A full scan of a 50K-line repo takes minutes and burns context. Incremental upda
 - After 30+ days since last refresh (file structure has likely drifted)
 - When `/dw-intel` queries return obviously stale results
 
-Trigger via `/dw-map-codebase` (no flag) or `/dw-map-codebase --full`.
+Trigger via `/dw-intel --build` (no flag) or `/dw-intel --build --full`.
 
 ## When to run a partial update
 
 - A single PR / feature branch touched 1-20 files
-- After `/dw-run-task` completes (touched files are known via git)
+- After `/dw-run` completes (touched files are known via git)
 - After `dw-deps-audit --execute` updates dependencies (only `deps.json` needs refresh)
 
-Trigger via `/dw-map-codebase --files src/foo.ts src/bar.ts` (explicit list) or `/dw-map-codebase --since HEAD~5` (from git diff).
+Trigger via `/dw-intel --build --files src/foo.ts src/bar.ts` (explicit list) or `/dw-intel --build --since HEAD~5` (from git diff).
 
 ## Partial update protocol
 
@@ -33,7 +33,7 @@ The `intel-updater` agent receives `focus: partial --files <paths>` and:
 4. **Bump** `_meta.version` by 1, set `_meta.updated_at` to now.
 5. **Update** `.last-refresh.json` with the new hashes for `files.json`, `apis.json`, `deps.json` (the three that were touched).
 
-If you run a partial update on a project where `.dw/intel/` doesn't exist, abort with: `"No .dw/intel/ found. Run /dw-map-codebase first for a full scan."`
+If you run a partial update on a project where `.dw/intel/` doesn't exist, abort with: `"No .dw/intel/ found. Run /dw-intel --build first for a full scan."`
 
 ## How `intel-updater` knows what's "key" in a partial
 
@@ -72,7 +72,7 @@ If a full update is triggered while a partial update is in flight (rare but poss
 ## What incremental updates do NOT cover
 
 - New `package.json` (e.g., user added `express` to deps but no source file imports it yet) — `deps.json` won't get the entry until that package is imported AND the importing file is in `--files`.
-  - Mitigation: when running `/dw-deps-audit --execute`, follow up with `/dw-map-codebase --full` to capture new deps.
+  - Mitigation: when running `/dw-secure-audit --plan --execute`, follow up with `/dw-intel --build --full` to capture new deps.
 - New file with a brand-new API route, when neither the new file nor any registration site was in `--files`.
   - Mitigation: include `src/routes/index.ts` (or your project's route registration entry point) in every partial update that mentions any route file.
 - Architectural changes (the kind that would update `arch.md`) — partial updates leave `arch.md` stale.

package/scaffold/skills/dw-codebase-intel/references/intel-format.md

@@ -194,7 +194,7 @@ The project follows a layered architecture: HTTP routes → application services
 }
 ```
 
-Hashes are SHA-256 of file contents at the moment of refresh. Used by `/dw-map-codebase` to detect drift on the next run and decide whether a partial update is enough.
+Hashes are SHA-256 of file contents at the moment of refresh. Used by `/dw-intel --build` to detect drift on the next run and decide whether a partial update is enough.
 
 ## Validation rules
 

package/scaffold/skills/dw-codebase-intel/references/query-patterns.md

@@ -126,8 +126,8 @@ Orders (5) ...
 
 Before answering, check `.dw/intel/.last-refresh.json`:
 
-- If `updated_at` is more than 7 days old → prefix the answer with: `⚠ Index last refreshed YYYY-MM-DD (X days ago). Run /dw-map-codebase to refresh.`
-- If `.last-refresh.json` is absent → prefix with: `⚠ No refresh metadata. Index may be stale; run /dw-map-codebase.`
+- If `updated_at` is more than 7 days old → prefix the answer with: `⚠ Index last refreshed YYYY-MM-DD (X days ago). Run /dw-intel --build to refresh.`
+- If `.last-refresh.json` is absent → prefix with: `⚠ No refresh metadata. Index may be stale; run /dw-intel --build.`
 
 Don't refuse to answer — return the best info available, but flag the staleness so the user can decide whether to trust it.
 
@@ -138,7 +138,7 @@ If `.dw/intel/` doesn't exist at all:
 1. Check `.dw/rules/` (from `/dw-analyze-project` or `/dw-new-project` seeding)
 2. If `.dw/rules/index.md` exists, search there for the query keywords
 3. Otherwise, do a direct `grep -r` over the project source (excluding `node_modules`, `.git`, etc.)
-4. Suggest at the end: `Tip: run /dw-map-codebase to build a queryable index. Subsequent /dw-intel queries will be much faster.`
+4. Suggest at the end: `Tip: run /dw-intel --build to build a queryable index. Subsequent /dw-intel queries will be much faster.`
 
 ## Don't
 

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

@@ -140,7 +140,7 @@ Record as:
 
 ## Output Location
 
-- **Embedded mode** (invoked by `/dw-brainstorm --council` or `/dw-create-techspec --council`): return the synthesis inline; the caller extracts what it needs for the parent artifact (PRD, techspec, ADR).
+- **Embedded mode** (invoked by `/dw-brainstorm --council` or `/dw-plan techspec --council`): return the synthesis inline; the caller extracts what it needs for the parent artifact (PRD, techspec, ADR).
 - **Standalone mode**: save to `.dw/spec/<prd-slug>/council-YYYYMMDD.md` (if a PRD is active) or present inline if no PRD context exists. If the decision warrants a permanent record, suggest `/dw-adr` as the next step.
 
 ## Debate Protocols (non-negotiable)
@@ -160,7 +160,7 @@ Record as:
 ## Integration With Other dw-* Commands
 
 - **`/dw-brainstorm --council`** (opt-in): invokes the council after the normal brainstorm to stress-test the top 2-3 options before recommending
-- **`/dw-create-techspec --council`** (opt-in): invokes the council on the primary architectural decision of the techspec before finalizing
+- **`/dw-plan techspec --council`** (opt-in): invokes the council on the primary architectural decision of the techspec before finalizing
 - **Standalone** `/dw-council "<dilemma>"` (if registered as a command — currently this is a bundled skill invoked by the two above; it can be promoted to a command in a future release if direct usage becomes common)
 
 The `--council` flag is **additive**: omitting it produces the normal brainstorm/techspec flow. Including it adds a debate section to the output.

package/scaffold/skills/dw-debug-protocol/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: dw-debug-protocol
-description: Use when investigating a bug — applies stop-the-line discipline plus a six-step triage (reproduce → localize → reduce → fix root cause → guard → verify) so you fix what's actually broken instead of papering over symptoms.
+description: Use when investigating a bug. Stop-the-line discipline + six-step triage (reproduce → localize → reduce → fix root cause → guard → verify). Triggers on every bug report, test failure, or /dw-bugfix.
+allowed-tools:
+  - Read
 ---
 
 # Debug Protocol
@@ -93,8 +95,8 @@ If any are missing, the bug is "fixed pending verification," not "fixed."
 ## Integration with dev-workflow commands
 
 - `/dw-bugfix` runs this skill end-to-end. The bug report is decomposed into steps 1-6 and progressed atomically.
-- `/dw-fix-qa` uses this skill when QA findings are bug-shaped (failing scenario rather than missing feature). Each finding becomes a six-step run.
-- `/dw-code-review` flags fixes that skipped step 5 (no regression test) as REJECTED.
+- `/dw-qa --fix` uses this skill when QA findings are bug-shaped (failing scenario rather than missing feature). Each finding becomes a six-step run.
+- `/dw-review --code-only` flags fixes that skipped step 5 (no regression test) as REJECTED.
 
 ## When to escalate / pair
 

package/scaffold/skills/dw-execute-phase/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dw-execute-phase
-description: Phase execution and plan verification for dev-workflow. Two agents (executor for wave-based parallel task dispatch with deviation handling, plan-checker for goal-backward plan verification before execution). Used by /dw-execute-phase, /dw-plan-checker, /dw-run-plan, /dw-autopilot. Adapted from get-shit-done-cc (MIT).
+description: "Use for task execution. Two agents: executor (wave-based parallel dispatch + deviation handling) and plan-checker (goal-backward verification). Invoked by /dw-run and /dw-autopilot."
 allowed-tools:
   - Read
   - Write
@@ -16,8 +16,8 @@ Bundled skill providing **phase-level execution discipline** for dev-workflow: p
 
 ## Why a skill (not inline)
 
-- The execution discipline (wave coordination, deviation rules, checkpoint protocol) is a separate concern from the commands that invoke it. Bundling it as a skill lets multiple commands (`/dw-run-plan`, `/dw-autopilot`, `/dw-execute-phase` itself) reuse the same discipline.
-- The plan-checker is a verification GATE — it must run before `/dw-run-plan`/`/dw-execute-phase` mutate code, and bundling it makes that contract visible.
+- The execution discipline (wave coordination, deviation rules, checkpoint protocol) is a separate concern from the commands that invoke it. Bundling it as a skill lets multiple commands (`/dw-run`, `/dw-autopilot`, `/dw-execute-phase` itself) reuse the same discipline.
+- The plan-checker is a verification GATE — it must run before `/dw-run`/`/dw-execute-phase` mutate code, and bundling it makes that contract visible.
 - The agents own the protocol; the orchestrating commands just wire them up.
 
 ## When to Use
@@ -26,30 +26,30 @@ Read this skill when:
 
 - `/dw-execute-phase` is invoked to run a batch of tasks in parallel waves.
 - `/dw-plan-checker` is invoked to verify a `tasks.md` file will achieve its PRD goal before execution.
-- `/dw-run-plan` is invoked (it spawns the executor agent for each wave).
+- `/dw-run` is invoked (it spawns the executor agent for each wave).
 - `/dw-autopilot` enters the execution stage (it gates on plan-checker before invoking the executor).
 
 Do NOT use when:
 
-- A single one-off change is being made (use `/dw-run-task` directly — no waves needed).
+- A single one-off change is being made (use `/dw-run` directly — no waves needed).
 - The user is exploring/brainstorming, not executing (use `/dw-brainstorm`).
-- The plan hasn't been created yet (use `/dw-create-tasks` first).
+- The plan hasn't been created yet (use `/dw-plan tasks` first).
 
 ## Agents
 
 | Agent | Responsibility | Spawn from |
 |-------|----------------|------------|
-| `agents/executor.md` | Runs tasks in waves, atomic commit per task, handles deviations (3 deviation rules), respects checkpoint markers, writes `SUMMARY.md` per phase | `/dw-execute-phase`, `/dw-run-plan` |
-| `agents/plan-checker.md` | Goal-backward verification of `tasks.md` before execution. Checks: requirement coverage, task completeness, dependency soundness, artifact wiring, context budget. Returns PASS / REVISE / BLOCK. | `/dw-plan-checker`, `/dw-create-tasks` (auto-gate before declaring tasks ready) |
+| `agents/executor.md` | Runs tasks in waves, atomic commit per task, handles deviations (3 deviation rules), respects checkpoint markers, writes `SUMMARY.md` per phase | `/dw-execute-phase`, `/dw-run` |
+| `agents/plan-checker.md` | Goal-backward verification of `tasks.md` before execution. Checks: requirement coverage, task completeness, dependency soundness, artifact wiring, context budget. Returns PASS / REVISE / BLOCK. | `/dw-plan-checker`, `/dw-plan tasks` (auto-gate before declaring tasks ready) |
 
 ## How the Two Agents Compose
 
 The expected flow:
 
-1. `/dw-create-tasks` produces `.dw/spec/prd-<slug>/tasks.md` from PRD + TechSpec.
+1. `/dw-plan tasks` produces `.dw/spec/prd-<slug>/tasks.md` from PRD + TechSpec.
 2. **Plan-checker GATE** — `/dw-plan-checker .dw/spec/prd-<slug>/` spawns the plan-checker agent. The agent reads PRD/TechSpec/tasks.md and verifies tasks WILL achieve the goal. Returns one of: `PASS` (proceed), `REVISE` (issues found, planner re-runs), `BLOCK` (fundamental gap, abort).
 3. `/dw-execute-phase` spawns the executor agent ONLY if plan-checker returned `PASS`. The executor runs tasks in waves, commits atomically, handles deviations.
-4. `/dw-run-qa` runs after all waves complete to validate the implementation against PRD.
+4. `/dw-qa` runs after all waves complete to validate the implementation against PRD.
 
 `/dw-autopilot` orchestrates this entire flow with hard gates between stages.
 
@@ -106,10 +106,10 @@ If the executor exhausts its context budget mid-phase OR the user signals stop:
 
 | File | Read by | Written by |
 |------|---------|------------|
-| `prd.md` | plan-checker, executor | `/dw-create-prd` |
-| `techspec.md` | plan-checker, executor | `/dw-create-techspec` |
-| `tasks.md` | plan-checker (verifies), executor (executes) | `/dw-create-tasks` |
-| `<NN>_task.md` | executor (per-task detail) | `/dw-create-tasks` |
+| `prd.md` | plan-checker, executor | `/dw-plan prd` |
+| `techspec.md` | plan-checker, executor | `/dw-plan techspec` |
+| `tasks.md` | plan-checker (verifies), executor (executes) | `/dw-plan tasks` |
+| `<NN>_task.md` | executor (per-task detail) | `/dw-plan tasks` |
 | `deviations.md` | plan-checker (next iteration), executor | executor (rule 1/2 deviations) |
 | `active-session.md` | `/dw-resume`, executor (continuation) | executor (checkpoint) |
 | `SUMMARY.md` | `/dw-generate-pr` | executor (after final wave) |
@@ -122,7 +122,7 @@ If the executor exhausts its context budget mid-phase OR the user signals stop:
 
 ## Rules
 
-- **No execution without plan-checker PASS.** `/dw-execute-phase` and `/dw-run-plan` must call plan-checker first; if it returns REVISE or BLOCK, abort.
+- **No execution without plan-checker PASS.** `/dw-execute-phase` and `/dw-run` must call plan-checker first; if it returns REVISE or BLOCK, abort.
 - **One commit per task, no exceptions.** Even trivial tasks commit. This drives traceability and revert safety.
 - **Deviations are recorded, not silenced.** Every adjustment beyond the plan goes in `deviations.md` with reason.
 - **Checkpoint > timeout.** When context budget is low, checkpoint cleanly rather than running tasks half-way.
@@ -130,4 +130,4 @@ If the executor exhausts its context budget mid-phase OR the user signals stop:
 
 ## Inspired by
 
-Adapted from [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`gsd-executor`, `gsd-plan-checker`) by gsd-build (MIT license). Core protocols (goal-backward verification, atomic commits, deviation handling, checkpoint resume) preserved. Path conventions changed from `.planning/<phase>/` to `.dw/spec/prd-<slug>/`. SDK CLI calls (`gsd-sdk query init.execute-phase`) replaced by inline operations. The companion `gsd-debugger` agent (1452 lines) was NOT ported — its scope overlaps with the existing `/dw-bugfix` and `/dw-fix-qa` commands.
+Adapted from [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`gsd-executor`, `gsd-plan-checker`) by gsd-build (MIT license). Core protocols (goal-backward verification, atomic commits, deviation handling, checkpoint resume) preserved. Path conventions changed from `.planning/<phase>/` to `.dw/spec/prd-<slug>/`. SDK CLI calls (`gsd-sdk query init.execute-phase`) replaced by inline operations. The companion `gsd-debugger` agent (1452 lines) was NOT ported — its scope overlaps with the existing `/dw-bugfix` and `/dw-qa --fix` commands.

package/scaffold/skills/dw-execute-phase/agents/executor.md

@@ -14,7 +14,7 @@ CRITICAL: If your spawn prompt contains a required_reading block, you MUST Read
 <role>
 You are **dw-executor**, the phase execution agent for dev-workflow. You execute the tasks in `.dw/spec/prd-<slug>/tasks.md` atomically, in waves, with one git commit per task. You handle deviations mid-execution per the three deviation rules. You checkpoint cleanly when context budget gets tight.
 
-Spawned by `/dw-execute-phase` or `/dw-run-plan` orchestrator with a PRD path.
+Spawned by `/dw-execute-phase` or `/dw-run` orchestrator with a PRD path.
 
 Your job: run every task in the phase to completion, commit each one, write `SUMMARY.md` at the end, update `active-session.md` for resume.
 </role>
@@ -28,7 +28,7 @@ Before executing, discover project context:
 
 **`.dw/rules/`**: project conventions (from `/dw-analyze-project`). Read `index.md` first; load module-specific rules as relevant per task.
 
-**`.dw/intel/`**: machine-readable codebase intel (from `/dw-map-codebase`). Read `arch.md` for architecture overview; query `files.json`/`apis.json` when implementing.
+**`.dw/intel/`**: machine-readable codebase intel (from `/dw-intel --build`). Read `arch.md` for architecture overview; query `files.json`/`apis.json` when implementing.
 </project_context>
 
 ## Execution Flow
@@ -224,8 +224,8 @@ duration_minutes: <N>
 
 ## Next Steps
 
-- Run `/dw-run-qa` to validate against PRD
-- Run `/dw-code-review` for the formal Level 3 review
+- Run `/dw-qa` to validate against PRD
+- Run `/dw-review --code-only` for the formal Level 3 review
 - Then `/dw-commit` (consolidates) and `/dw-generate-pr`
 ```
 
@@ -251,7 +251,7 @@ The orchestrator pattern-matches on these — emit exactly one:
 - <critical>Deviations are recorded. Every Rule-1/2/3 adjustment goes in `deviations.md` with the linked commit.</critical>
 - <critical>CLAUDE.md > plan. If plan and CLAUDE.md conflict, CLAUDE.md wins (Rule 1 deviation).</critical>
 - <critical>Atomic edits to tasks.md. Mark `[x]` for the just-committed task BEFORE moving to the next.</critical>
-- Do NOT push to remote. The orchestrator runs `/dw-generate-pr` after `/dw-run-qa`.
+- Do NOT push to remote. The orchestrator runs `/dw-generate-pr` after `/dw-qa`.
 - Do NOT skip waves. Tasks within a wave run in parallel; waves run sequentially.
 
 ## Anti-Patterns

package/scaffold/skills/dw-execute-phase/agents/plan-checker.md

@@ -14,7 +14,7 @@ CRITICAL: If your spawn prompt contains a required_reading block, you MUST Read
 <role>
 You are **dw-plan-checker**, the plan verification agent for dev-workflow. You verify that `.dw/spec/prd-<slug>/tasks.md` WILL achieve the PRD goal — not just that it looks complete.
 
-Spawned by `/dw-plan-checker` (manual gate) or `/dw-create-tasks` (auto-gate before declaring tasks ready) or `/dw-autopilot` (gate before execution).
+Spawned by `/dw-plan-checker` (manual gate) or `/dw-plan tasks` (auto-gate before declaring tasks ready) or `/dw-autopilot` (gate before execution).
 
 Goal-backward verification of plans BEFORE execution. Start from what the PRD SHOULD deliver, verify the tasks address it.
 
@@ -187,7 +187,7 @@ After running all 6 dimensions:
 ## Recommendation
 
 - PASS → proceed to `/dw-execute-phase .dw/spec/prd-<slug>/`
-- REVISE → re-run `/dw-create-tasks` with the issues above as input
+- REVISE → re-run `/dw-plan tasks` with the issues above as input
 - BLOCK → resolve the locked-decision conflict before re-planning
 
 ## Status Marker
@@ -204,12 +204,12 @@ After running all 6 dimensions:
 - <critical>Cite file paths and line numbers in every issue. The planner re-running needs to know exactly where to look.</critical>
 - <critical>The status marker is the final line. Orchestrators pattern-match on it.</critical>
 - Do NOT modify files. Plan-checker is read-only.
-- Do NOT verify implementation correctness. That's the executor's job and `/dw-run-qa`'s job. You only verify the PLAN.
+- Do NOT verify implementation correctness. That's the executor's job and `/dw-qa`'s job. You only verify the PLAN.
 
 ## Anti-Patterns
 
 1. DO NOT skip dimensions because the plan "looks fine"
 2. DO NOT classify locked-decision conflicts as REVISE — they are BLOCK
-3. DO NOT include code-quality nitpicks (linting, formatting) — that's `/dw-code-review`'s domain
+3. DO NOT include code-quality nitpicks (linting, formatting) — that's `/dw-review --code-only`'s domain
 4. DO NOT modify `tasks.md`; only verify it
 5. DO NOT silently downgrade BLOCK to REVISE because "the user might fix it later"

package/scaffold/skills/dw-execute-phase/references/atomic-commits.md

@@ -26,7 +26,7 @@ Closes RF-XX (partial — full close on tasks.md completion).
 | Type | Use |
 |------|-----|
 | `feat` | New user-facing capability (default for most PRD tasks) |
-| `fix` | Bug fix discovered during the phase (rare in `/dw-execute-phase`; common in `/dw-fix-qa`) |
+| `fix` | Bug fix discovered during the phase (rare in `/dw-execute-phase`; common in `/dw-qa --fix`) |
 | `refactor` | Code reshape without behavior change |
 | `test` | Tests-only task |
 | `docs` | Docs-only task |

package/scaffold/skills/dw-execute-phase/references/plan-verification.md

@@ -143,9 +143,9 @@ After running all 6 dimensions:
 
 The plan-checker is part of a bounded quality loop:
 
-1. `/dw-create-tasks` produces v1 of `tasks.md`
+1. `/dw-plan tasks` produces v1 of `tasks.md`
 2. `/dw-plan-checker` runs → REVISE
-3. `/dw-create-tasks --revise` produces v2 (consumes plan-checker's issues as input)
+3. `/dw-plan tasks --revise` produces v2 (consumes plan-checker's issues as input)
 4. `/dw-plan-checker` runs → PASS or REVISE again
 5. After 3 revisions without reaching PASS → escalate to user (something fundamental is wrong)
 

package/scaffold/skills/dw-execute-phase/references/wave-coordination.md

@@ -81,7 +81,7 @@ This means: subagents return their changes (files written, but NOT committed). T
 
 ## When to NOT use waves
 
-Single-task changes (`/dw-quick`, `/dw-run-task`) bypass waves entirely. Waves are for `/dw-run-plan` and `/dw-execute-phase` — phase-scale execution.
+Single-task changes (`/dw-quick`, `/dw-run`) bypass waves entirely. Waves are for `/dw-run` and `/dw-execute-phase` — phase-scale execution.
 
 ## Verification of wave structure (pre-execution)
 

package/scaffold/skills/dw-git-discipline/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: dw-git-discipline
-description: Use when committing or opening a PR — applies trunk-based development, atomic commit discipline (one intent per commit, refactor separate from feature), conventional commit messages, and branch hygiene so history is bisectable and reviewable.
+description: Use when committing or opening a PR. Atomic commits (one intent), Conventional Commits, trunk-based pattern, branch hygiene. Triggers before /dw-commit, /dw-generate-pr, or any git operation.
+allowed-tools:
+  - Read
+  - Bash
 ---
 
 # Git Discipline
@@ -87,7 +90,7 @@ When wired into `/dw-generate-pr`, every PR must:
 
 - `/dw-commit` runs this skill — verifies lint/tests/build green, drafts a Conventional Commits message, splits commits if multi-intent detected.
 - `/dw-generate-pr` uses this skill to validate branch naming, PR body structure, and scope.
-- `/dw-run-task` and `/dw-run-plan` follow the atomic-commit discipline when their executor commits work — one task = one commit (or one logical sub-task).
+- `/dw-run` and `/dw-run` follow the atomic-commit discipline when their executor commits work — one task = one commit (or one logical sub-task).
 
 ## Anti-patterns this skill prevents