@brunosps00/dev-workflow 0.15.0 → 1.0.0

package/scaffold/skills/dw-testing-discipline/references/agent-guardrails.md

@@ -2,7 +2,7 @@
 
 LLMs have characteristic failure modes when authoring tests. Six guardrails are forcing functions for the most common ones.
 
-Every test produced by an agent (via `/dw-run-task`, `/dw-bugfix`, `/dw-autopilot`, or any code-generating flow) must clear all six BEFORE the diff goes to review.
+Every test produced by an agent (via `/dw-run`, `/dw-bugfix`, `/dw-autopilot`, or any code-generating flow) must clear all six BEFORE the diff goes to review.
 
 ## Guardrail 1 — State the invariant, layer, and host suite first
 
@@ -25,7 +25,7 @@ If the agent can't fill any line, it stops and asks the user — it does NOT inv
 - "Owning layer" forces Rule 2 (lowest detectable layer).
 - "Existing suite" forces extending coverage rather than spawning orphan files.
 
-**Verification:** `/dw-code-review` looks for this 3-line preamble in the PR description or commit body. Missing = REJECTED.
+**Verification:** `/dw-review --code-only` looks for this 3-line preamble in the PR description or commit body. Missing = REJECTED.
 
 ## Guardrail 2 — Real execution somewhere
 
@@ -161,7 +161,7 @@ Tests violating guardrails without explicit SKIP-GUARDRAIL-N comments
 will be REJECTED at review.
 ```
 
-`/dw-run-task` and `/dw-bugfix` inject this prompt block before generating test code.
+`/dw-run` and `/dw-bugfix` inject this prompt block before generating test code.
 
 ## Why six and not more
 

package/scaffold/skills/dw-testing-discipline/references/anti-patterns.md

@@ -1,6 +1,6 @@
 # Anti-patterns — 25 smells across 4 families
 
-Each anti-pattern names the smell, shows the violation in pseudo-code, gives the fix, and notes how `/dw-code-review` detects it. Agent-specific failure modes are covered separately in `agent-guardrails.md`.
+Each anti-pattern names the smell, shows the violation in pseudo-code, gives the fix, and notes how `/dw-review --code-only` detects it. Agent-specific failure modes are covered separately in `agent-guardrails.md`.
 
 ---
 
@@ -324,7 +324,7 @@ You wrote `hello` in the mock. You asserted `hello`. You proved nothing.
 
 ---
 
-## How `/dw-code-review` uses this catalog
+## How `/dw-review --code-only` uses this catalog
 
 For each diff hunk under a test path:
 1. Run regex scans for the patterns flagged "Detection" above.

package/scaffold/skills/dw-testing-discipline/references/core-rules.md

@@ -125,4 +125,4 @@ A healthy test:
 5. Survives a mutation in the code it claims to cover (Rule 5).
 6. Has zero footprint in production code (Rule 6).
 
-Any test failing ≥2 of these is technical debt accumulating. `/dw-code-review` flags them.
+Any test failing ≥2 of these is technical debt accumulating. `/dw-review --code-only` flags them.

package/scaffold/skills/dw-testing-discipline/references/flaky-discipline.md

@@ -158,6 +158,6 @@ When CI is wired this way, a flake at unit usually = race or order-dependency (f
 
 ## Integration with dev-workflow
 
-- `/dw-fix-qa` uses this taxonomy when retest cycles produce inconsistent results: classify the flake, apply the right fix, document.
-- `/dw-code-review` flags tests being modified that have a `FLAKY-*` marker — review must verify the flake is now actually fixed, not just made less likely.
-- `/dw-run-qa` weekly summary includes the `flaky_rate` metric.
+- `/dw-qa --fix` uses this taxonomy when retest cycles produce inconsistent results: classify the flake, apply the right fix, document.
+- `/dw-review --code-only` flags tests being modified that have a `FLAKY-*` marker — review must verify the flake is now actually fixed, not just made less likely.
+- `/dw-qa` weekly summary includes the `flaky_rate` metric.

package/scaffold/skills/dw-testing-discipline/references/patterns.md

@@ -238,4 +238,4 @@ The page object hides the selector mess; tests read like specs. But for a 5-test
 
 ## Applying these patterns
 
-When `/dw-run-task` generates a new test, it must comply with these 12. `/dw-code-review` checks each diff hunk under test paths against these patterns and the anti-patterns in the sibling reference. Violations become findings.
+When `/dw-run` generates a new test, it must comply with these 12. `/dw-review --code-only` checks each diff hunk under test paths against these patterns and the anti-patterns in the sibling reference. Violations become findings.

package/scaffold/skills/dw-testing-discipline/references/playwright-recipes.md

@@ -1,6 +1,6 @@
 # Playwright recipes — concrete tactical patterns
 
-Practical Playwright code for the common scenarios. Use this when `/dw-run-qa` runs in UI mode or when `/dw-functional-doc` needs E2E coverage.
+Practical Playwright code for the common scenarios. Use this when `/dw-qa` runs in UI mode or when `/dw-functional-doc` needs E2E coverage.
 
 > These recipes ASSUME the doctrine in this skill (core rules, positive patterns) has already been applied. Recipes are the HOW once the WHY is settled.
 

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

@@ -1,6 +1,8 @@
 ---
 name: dw-ui-discipline
-description: Use BEFORE any UI work — runs a 4-question grounding (where do design decisions come from, what does this surface help the user do, what states does it have, who uses it where), then enforces the WCAG 2.2 AA floor and 14 visual-slop checks so UI ships with intent instead of training-data defaults.
+description: Use BEFORE any UI work. 4 grounding questions (design source, surface job, state matrix, scene), 14 anti-slop patterns, WCAG 2.2 AA floor. Triggers on UI design, /dw-redesign-ui, UI diffs.
+allowed-tools:
+  - Read
 ---
 
 # UI Discipline
@@ -12,9 +14,9 @@ This skill blocks that autopilot at four grounding questions before any visual d
 ## When to use
 
 - Inside `/dw-redesign-ui` — both proposal and validation steps.
-- Inside `/dw-create-techspec` when the spec has UI sections.
+- Inside `/dw-plan techspec` when the spec has UI sections.
 - Inside `/dw-functional-doc` when documenting screen-level patterns.
-- Inside `/dw-code-review` when the diff touches UI files (CSS, JSX, templates).
+- Inside `/dw-review --code-only` when the diff touches UI files (CSS, JSX, templates).
 - Inside `/dw-brainstorm` when the conversation drifts into visual direction.
 
 If you're tempted to skip this "because it's just a small tweak" — that's the trigger. Run the grounding.
@@ -126,7 +128,7 @@ Before any interactive widget ships:
 - [ ] Heading hierarchy is semantic (no skipped levels).
 - [ ] `prefers-reduced-motion` honored.
 
-Full verification recipes in `references/accessibility-floor.md`. `/dw-code-review` rejects the verdict if any interactive widget ships without these.
+Full verification recipes in `references/accessibility-floor.md`. `/dw-review --code-only` rejects the verdict if any interactive widget ships without these.
 
 ## When the grounding bends
 
@@ -139,8 +141,8 @@ In all bend cases, document the bend in the PR (one line). "I skipped the state
 ## Integration with dev-workflow commands
 
 - `/dw-redesign-ui` runs the grounding end-to-end. Steps 4 (propose) and 7 (validate) consult this skill explicitly.
-- `/dw-create-techspec` UI sections must answer the 4 grounding questions and reference the state matrix.
-- `/dw-code-review` checks UI diffs against the 14 visual-slop patterns and the accessibility floor.
+- `/dw-plan techspec` UI sections must answer the 4 grounding questions and reference the state matrix.
+- `/dw-review --code-only` checks UI diffs against the 14 visual-slop patterns and the accessibility floor.
 - `/dw-functional-doc` records the surface-job and scene sentences in the overview for each screen.
 
 ## Why this approach

package/scaffold/skills/dw-ui-discipline/references/accessibility-floor.md

@@ -1,6 +1,6 @@
 # Accessibility floor — WCAG 2.2 AA is the minimum, not the goal
 
-This reference is read in full before any interactive widget ships. Skipping any item below is a hard-block in `/dw-code-review`.
+This reference is read in full before any interactive widget ships. Skipping any item below is a hard-block in `/dw-review --code-only`.
 
 ## The non-negotiables
 
@@ -222,4 +222,4 @@ LLM-produced UI commonly fails on:
 - Modals that trap focus only on success path, not on error.
 - Auto-playing carousels with no pause control.
 
-`/dw-code-review` runs axe-style checks on the diff for these.
+`/dw-review --code-only` runs axe-style checks on the diff for these.

package/scaffold/skills/dw-ui-discipline/references/hard-gate.md

@@ -159,4 +159,4 @@ This is the minimum disclosure. Anything less and the grounding didn't pass.
 
 The downstream references (`visual-slop.md`, `state-matrix.md`, `accessibility-floor.md`) assume the grounding passed. They won't re-verify; if you skipped a question, the output will reflect it.
 
-`/dw-code-review` fails verdict on UI PRs where this disclosure is missing.
+`/dw-review --code-only` fails verdict on UI PRs where this disclosure is missing.

package/scaffold/skills/dw-ui-discipline/references/state-matrix.md

@@ -86,7 +86,7 @@ Before declaring the design "done":
 - [ ] `focus-visible` is distinct from `hover` (keyboard users need their own affordance).
 - [ ] Color is never the SOLE differentiator (a11y); pair with shape/text/position.
 
-## Integration with `/dw-code-review`
+## Integration with `/dw-review --code-only`
 
 Review fails verdict (REJECTED) on a UI PR when:
 - A new component handles async data but renders only the default state.

package/scaffold/skills/dw-ui-discipline/references/visual-slop.md

@@ -4,7 +4,7 @@ Two parts:
 1. **Fourteen patterns** an ungrounded UI agent produces.
 2. **Seventeen specific values** that signal "no thought went into this."
 
-Used by `/dw-code-review` against UI diffs and by `/dw-redesign-ui` as a self-check during proposal.
+Used by `/dw-review --code-only` against UI diffs and by `/dw-redesign-ui` as a self-check during proposal.
 
 ## The 14 patterns
 
@@ -140,7 +140,7 @@ Specific values that signal "no thought went into this." Avoid unless you can ar
 
 In `/dw-redesign-ui` step 4 (propose) — before presenting design directions, self-check against this list. If you're using a pattern, say why explicitly ("gradient crutch — intentional for marketing hero"). Sometimes the pattern IS the right call; the discipline is awareness, not absolutism.
 
-In `/dw-code-review` UI section — grep the diff for the anti-default values and the patterns. Each hit becomes a finding under `dw-review-rigor`:
+In `/dw-review --code-only` UI section — grep the diff for the anti-default values and the patterns. Each hit becomes a finding under `dw-review-rigor`:
 - Pattern on a NEW surface → `medium` severity.
 - Pattern propagating EXISTING slop further → `low` severity (consistency wins).
 - Pattern on a redesign that was supposed to fix slop → `high` severity (regression).

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

@@ -171,11 +171,11 @@ If no verification command exists for the project, state that explicitly in the
 
 This skill is invoked transparently from:
 
-- `/dw-run-task` — before committing the task's changes
-- `/dw-run-plan` — before Level 2 review and before declaring the plan complete
-- `/dw-fix-qa` — before marking a bug as resolved in `QA/bugs.md`
+- `/dw-run` — before committing the task's changes
+- `/dw-run` — before Level 2 review and before declaring the plan complete
+- `/dw-qa --fix` — before marking a bug as resolved in `QA/bugs.md`
 - `/dw-bugfix` — before claiming the bug is fixed (original symptom no longer reproduces)
-- `/dw-code-review` — before emitting an APPROVED verdict
+- `/dw-review --code-only` — before emitting an APPROVED verdict
 - `/dw-generate-pr` — blocks PR creation if the session has no passing VERIFICATION REPORT post-last-edit
 
 Callers should mention this skill in their "Skills Complementares" section so the user sees the dependency.

package/scaffold/skills/humanizer/SKILL.md

@@ -1,13 +1,7 @@
 ---
 name: humanizer
 version: 2.2.0
-description: |
-  Remove signs of AI-generated writing from text. Use when editing or reviewing
-  text to make it sound more natural and human-written. Based on Wikipedia's
-  comprehensive "Signs of AI writing" guide. Detects and fixes patterns including:
-  inflated symbolism, promotional language, superficial -ing analyses, vague
-  attributions, em dash overuse, rule of three, AI vocabulary words, negative
-  parallelisms, and excessive conjunctive phrases.
+description: Use when editing AI-generated text. Detects 24 'signs of AI writing' (em-dashes, rule-of-three, AI vocab, vague attributions). Triggers on docs, READMEs, blog posts, captions, marketing copy.
 allowed-tools:
   - Read
   - Write

package/scaffold/skills/remotion-best-practices/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: remotion-best-practices
-description: Best practices for Remotion - Video creation in React
+description: Use for video composition with Remotion + React. 25+ rules for composition, transitions, FFmpeg, performance. Triggers on .tsx Remotion files, video rendering, motion design, captions.
+allowed-tools:
+  - Read
 metadata:
   tags: remotion, video, react, animation, composition
 ---

package/scaffold/skills/security-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security-review
-description: Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.
+description: Use for security code review. OWASP patterns (injection, XSS, auth, authz, crypto, SSRF, secrets). Confidence-based reporting. Triggers on 'security review', auth/payment code, or /dw-secure-audit.
 allowed-tools: Read, Grep, Glob, Bash, Task
 license: LICENSE
 ---

package/scaffold/skills/security-review/languages/csharp.md

@@ -1,6 +1,6 @@
 # C# / .NET Security Patterns
 
-Covers **ASP.NET Core, ASP.NET (Framework), Blazor, Razor Pages, Minimal APIs, Entity Framework Core, ADO.NET, Dapper, Identity, NuGet**. Used by `/dw-security-check` as the primary reference when C# is detected in scope.
+Covers **ASP.NET Core, ASP.NET (Framework), Blazor, Razor Pages, Minimal APIs, Entity Framework Core, ADO.NET, Dapper, Identity, NuGet**. Used by `/dw-secure-audit` as the primary reference when C# is detected in scope.
 
 ---
 

package/scaffold/skills/security-review/languages/rust.md

@@ -1,6 +1,6 @@
 # Rust Security Patterns
 
-Covers **Actix Web, Axum, Rocket, Warp, Tonic (gRPC), Tower, Tokio, sqlx, Diesel, SeaORM, serde, reqwest, hyper, std::process, std::fs, unsafe blocks, FFI, and cargo supply chain**. Used by `/dw-security-check` as the primary reference when Rust is detected in scope.
+Covers **Actix Web, Axum, Rocket, Warp, Tonic (gRPC), Tower, Tokio, sqlx, Diesel, SeaORM, serde, reqwest, hyper, std::process, std::fs, unsafe blocks, FFI, and cargo supply chain**. Used by `/dw-secure-audit` as the primary reference when Rust is detected in scope.
 
 > Rust's ownership and borrow checker eliminate **memory-safety** classes of bugs (use-after-free, data races, buffer overflows) — but **logic bugs, misuse of `unsafe`, DoS via panic, injection into string-APIs, and supply-chain compromise are still present**. Do not assume "Rust = secure".
 

package/scaffold/skills/security-review/languages/typescript.md

@@ -2,7 +2,7 @@
 
 This file complements `javascript.md` (which already covers React/Vue/Express/Next/Angular/Node XSS, injection, DOM sinks, prototype pollution). Here we focus on **TypeScript-specific** vulnerability classes: type-system abuses, runtime vs compile-time gap, TS-native ORMs, TS-native validators, and framework-specific patterns unique to TS ecosystems.
 
-> Used by `/dw-security-check` as the primary reference when TS is detected in scope.
+> Used by `/dw-secure-audit` as the primary reference when TS is detected in scope.
 
 ---
 

package/scaffold/skills/vercel-react-best-practices/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: vercel-react-best-practices
-description: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
+description: Use for React/Next.js performance optimization. 67 rules across async, bundle, client, render, JS micro-perf. Triggers on React components, Next.js pages, data fetching, perf review, hydration issues.
+allowed-tools:
+  - Read
 license: MIT
 metadata:
   author: vercel

package/scaffold/templates-overrides-readme.md

@@ -23,7 +23,7 @@ git add .dw/templates/overrides/prd-template.md
 git commit -m "chore(templates): customize PRD template for our team"
 ```
 
-The override takes effect immediately. Commands that consume the template (`/dw-create-prd`, etc.) will read from `.dw/templates/<name>.md`, which is preserved as your edited copy.
+The override takes effect immediately. Commands that consume the template (`/dw-plan prd`, etc.) will read from `.dw/templates/<name>.md`, which is preserved as your edited copy.
 
 ## How to revert an override
 
@@ -46,9 +46,9 @@ npx @brunosps00/dev-workflow update
 
 - Removing critical-path sections like FR numbering or test plans — downstream commands rely on these.
 - Adding fields that conflict with the YAML frontmatter schema.
-- Anything that breaks `/dw-create-techspec` or `/dw-create-tasks` cross-references.
+- Anything that breaks `/dw-plan techspec` or `/dw-plan tasks` cross-references.
 
-If in doubt, run the workflow end-to-end after editing — the consistency check at the end of `/dw-create-tasks` will surface most structural breakages.
+If in doubt, run the workflow end-to-end after editing — the consistency check at the end of `/dw-plan tasks` will surface most structural breakages.
 
 ## Versioning your overrides