@brunosps00/dev-workflow 0.15.0 → 1.0.0

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
 

package/scaffold/skills/dw-incident-response/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: dw-incident-response
-description: Use when a production incident is reported, when writing a postmortem, or when an on-call handoff is needed. Five-phase guided workflow (triage → investigation → resolution → communication → postmortem) with checkpoints between phases and structured output files persisted to .dw/incidents/.
+description: Use when production breaks or for postmortems. 5 phases (triage → investigation → resolution → comms → postmortem), runbook templates. Triggers on outage, SEV-1, SEV-2, on-call handoff.
+allowed-tools:
+  - Read
+  - Write
+  - Bash
 ---
 
 # Incident Response

package/scaffold/skills/dw-llm-eval/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: dw-llm-eval
-description: Use when authoring or reviewing AI/LLM features (chat, RAG, summarization, classifiers, agents) — enforces an oracle ladder (climb from exact match up to LLM-as-judge), reference-dataset discipline, judge calibration (Spearman ≥0.80), and trajectory-vs-outcome agent eval so AI features ship with measurable behavior instead of "looks good to me" QA.
+description: Use when authoring or reviewing AI/LLM features (chat, RAG, agents, classifiers). Oracle ladder, reference dataset, judge calibration (Spearman ≥0.80), trajectory eval. Triggers on every AI code path.
+allowed-tools:
+  - Read
 ---
 
 # LLM Evaluation
@@ -10,9 +12,9 @@ description: Use when authoring or reviewing AI/LLM features (chat, RAG, summari
 ## When this skill applies
 
 - Any feature that uses an LLM in production: chat, summarization, classification, RAG (retrieval-augmented generation), agents, tool-use, structured extraction, code generation.
-- `/dw-create-tasks` when the PRD mentions an AI feature — eval planning becomes a mandatory subtask.
-- `/dw-code-review` when the diff touches AI feature code paths.
-- `/dw-run-qa --ai` when validating an AI feature against its reference dataset.
+- `/dw-plan tasks` when the PRD mentions an AI feature — eval planning becomes a mandatory subtask.
+- `/dw-review --code-only` when the diff touches AI feature code paths.
+- `/dw-qa --ai` when validating an AI feature against its reference dataset.
 
 If the feature is fully deterministic (no LLM in the loop), use `dw-testing-discipline` instead — Iron rules and 25 anti-patterns. This skill is specifically for entropy-tolerant systems.
 
@@ -110,7 +112,7 @@ See `references/agent-eval.md` for examples and the decision tree.
 | RAG-specific feature | `references/rag-metrics.md` |
 | Agent / tool-use feature | `references/agent-eval.md` |
 
-## Anti-patterns (will block in `/dw-code-review`)
+## Anti-patterns (will block in `/dw-review --code-only`)
 
 - **LLM-as-judge without calibration evidence.** PR adds LLM-as-judge but the calibration Spearman score is missing or < 0.80. REJECTED.
 - **Same-model judge.** Judge model is the same as the system under test. REJECTED unless explicitly documented (and even then, results are suspect).
@@ -121,9 +123,9 @@ See `references/agent-eval.md` for examples and the decision tree.
 
 ## Integration with dev-workflow commands
 
-- `/dw-create-tasks`: when the PRD has an AI feature requirement, an eval-plan subtask is mandatory. The task references this skill's oracle ladder.
-- `/dw-code-review`: AI feature PRs require a reference dataset + ≥2 oracle rungs (lower rungs FIRST). The constitution gate also applies — if the project has principles about AI feature reliability, they're enforced here.
-- `/dw-run-qa --ai`: new mode (when this skill is bundled) — runs the reference dataset against the current implementation, logs to `QA/logs/ai/<feature>-<date>.jsonl`, computes precision@k / faithfulness / outcome accuracy per the feature type.
+- `/dw-plan tasks`: when the PRD has an AI feature requirement, an eval-plan subtask is mandatory. The task references this skill's oracle ladder.
+- `/dw-review --code-only`: AI feature PRs require a reference dataset + ≥2 oracle rungs (lower rungs FIRST). The constitution gate also applies — if the project has principles about AI feature reliability, they're enforced here.
+- `/dw-qa --ai`: new mode (when this skill is bundled) — runs the reference dataset against the current implementation, logs to `QA/logs/ai/<feature>-<date>.jsonl`, computes precision@k / faithfulness / outcome accuracy per the feature type.
 - `/dw-bugfix` when the bug is an AI failure mode (hallucination, tool misuse, classification error): adds the failing case to the reference dataset BEFORE fixing — the case is now a regression test forever.
 
 ## When the discipline bends

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

@@ -153,8 +153,8 @@ When flagged for compaction, apply inline:
 
 ## Integration With Other dev-workflow Commands
 
-- `/dw-run-task` — reads memory before coding; updates `<N>_memory.md` during; runs promotion test + updates `MEMORY.md` at the end.
-- `/dw-run-plan` — runs promotion + compaction between tasks, so each task starts with clean shared state.
+- `/dw-run` — reads memory before coding; updates `<N>_memory.md` during; runs promotion test + updates `MEMORY.md` at the end.
+- `/dw-run` — runs promotion + compaction between tasks, so each task starts with clean shared state.
 - `/dw-autopilot` — threads memory through every phase (brainstorm → PRD → techspec → tasks → execution); on re-invocation reads `MEMORY.md` first to reconstitute cross-session context.
 
 Callers should mention this skill in their "Skills Complementares" section.

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

@@ -14,7 +14,7 @@ A set of rules the caller applies while producing a review report. This skill do
 
 ## When Invoked
 
-By `/dw-code-review`, `/dw-review-implementation`, `/dw-refactoring-analysis`. The caller has already identified a scope (files, a PR, a codebase area). This skill governs how findings are selected, deduplicated, ordered, and phrased.
+By `/dw-review --code-only`, `/dw-review --coverage-only`, `/dw-brainstorm --refactor`. The caller has already identified a scope (files, a PR, a codebase area). This skill governs how findings are selected, deduplicated, ordered, and phrased.
 
 ## Required Inputs
 
@@ -122,9 +122,9 @@ The caller emits:
 
 ## Integration With Other dev-workflow Commands
 
-- `/dw-code-review` — applies all five rules to its Level-3 review output; uses prior reports in `.dw/spec/*/reviews/` to dedupe across rounds.
-- `/dw-review-implementation` — applies de-dup + severity-ordering when listing gaps between PRD requirements and code.
-- `/dw-refactoring-analysis` — applies rules 1, 2, 4, 5 when cataloging code smells (rule 3 adapts: a "smell" with a justifying ADR becomes a `low` finding at most).
+- `/dw-review --code-only` — applies all five rules to its Level-3 review output; uses prior reports in `.dw/spec/*/reviews/` to dedupe across rounds.
+- `/dw-review --coverage-only` — applies de-dup + severity-ordering when listing gaps between PRD requirements and code.
+- `/dw-brainstorm --refactor` — applies rules 1, 2, 4, 5 when cataloging code smells (rule 3 adapts: a "smell" with a justifying ADR becomes a `low` finding at most).
 
 Callers should mention this skill in their "Skills Complementares" section.
 
@@ -134,6 +134,6 @@ Ported from Compozy's `cy-review-round` skill (`/tmp/compozy/.agents/skills/cy-r
 
 - No `reviews-NNN/` directory convention — dev-workflow reviews already persist in `.dw/spec/*/reviews/` per command's existing contract.
 - The five rules are extracted here so three different dev-workflow review commands can share the discipline without duplicating it.
-- No issue-file frontmatter (Compozy uses it to interoperate with its remediation engine; dev-workflow's remediation is manual or via `/dw-fix-qa`).
+- No issue-file frontmatter (Compozy uses it to interoperate with its remediation engine; dev-workflow's remediation is manual or via `/dw-qa --fix`).
 
 Credit: Compozy project (https://github.com/compozy/compozy).

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

@@ -1,6 +1,6 @@
 ---
 name: dw-simplification
-description: Disciplined code simplification — understand WHY code exists before changing it (Chesterton's Fence), preserve behavior exactly, prefer clarity over cleverness, scope to recent changes. Used by /dw-code-review and /dw-refactoring-analysis. Adapted from addyosmani/agent-skills (MIT).
+description: Use when simplifying code. Chesterton's Fence (understand WHY first), behavior-preserving refactor, complexity metrics. Triggers from /dw-review --code-only and /dw-brainstorm --refactor.
 allowed-tools:
   - Read
   - Edit
@@ -17,10 +17,10 @@ Behavioral discipline for simplifying code without breaking it. The trap of refa
 
 Read this skill when:
 
-- `/dw-code-review` flagged a complexity issue (deep nesting, long function, duplication).
-- `/dw-refactoring-analysis` proposed a simplification target.
+- `/dw-review --code-only` flagged a complexity issue (deep nesting, long function, duplication).
+- `/dw-brainstorm --refactor` proposed a simplification target.
 - The user explicitly asks to "clean this up" / "simplify X".
-- During `/dw-run-task` if the implementation accidentally produced complex code that wants pre-commit cleanup.
+- During `/dw-run` if the implementation accidentally produced complex code that wants pre-commit cleanup.
 
 Do NOT use when:
 

package/scaffold/skills/dw-source-grounding/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dw-source-grounding
-description: Discipline of grounding architectural and dependency decisions in versioned official documentation, with mandatory citations. Other commands invoke this skill when they need to decide based on framework/library behavior — never on hallucinated APIs or stale Stack Overflow answers. Adapted from addyosmani/agent-skills (MIT).
+description: "Use when citing frameworks or libraries. Detect → Fetch → Implement → Cite with [source: url, version, retrieved]. Triggers on every framework decision in techspec, deps audit, research."
 allowed-tools:
   - Read
   - Bash

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

@@ -1,6 +1,8 @@
 ---
 name: dw-testing-discipline
-description: Use when authoring, reviewing, or debugging tests — enforces six core rules (assert behavior, push to lowest layer, fix prod first on red, real systems gate merge, mutation > coverage, no test backdoors), a catalog of anti-patterns, agent-authoring guardrails, and flaky-test discipline so tests reveal bugs instead of decorating CI.
+description: Use when authoring, reviewing, or debugging tests. Six core rules, 25 anti-patterns, 6 agent guardrails, flaky discipline. Triggers on every test diff, /dw-qa, or test-writing session.
+allowed-tools:
+  - Read
 ---
 
 # Testing Discipline
@@ -160,11 +162,11 @@ Any of these in a PR is enough to REJECT a verdict:
 
 ## Integration with dev-workflow commands
 
-- `/dw-create-tasks` applies the placement doctrine — each test-adding task names the invariant.
-- `/dw-run-task` runs the 6 agent guardrails when generating tests during implementation.
-- `/dw-code-review` runs the anti-pattern checks on diff hunks under test paths.
-- `/dw-fix-qa` applies the flaky-discipline taxonomy in retest cycles.
-- `/dw-run-qa` (UI mode) references `playwright-recipes.md` for concrete recipes.
+- `/dw-plan tasks` applies the placement doctrine — each test-adding task names the invariant.
+- `/dw-run` runs the 6 agent guardrails when generating tests during implementation.
+- `/dw-review --code-only` runs the anti-pattern checks on diff hunks under test paths.
+- `/dw-qa --fix` applies the flaky-discipline taxonomy in retest cycles.
+- `/dw-qa` (UI mode) references `playwright-recipes.md` for concrete recipes.
 
 ## Bottom line