@brunosps00/dev-workflow 0.15.0 → 1.0.1

package/scaffold/skills/dw-simplification/references/deep-modules.md

@@ -0,0 +1,105 @@
+# Deep modules — high leverage at small interface
+
+A **deep module** absorbs complexity behind a narrow public surface. Its callers see a small, stable API and get a lot of work done per call. A **shallow module** is the opposite — small interface AND small implementation, so it adds an indirection without absorbing any complexity. Or worse: a god-module, deep implementation BUT huge interface, where the surface itself is the complexity.
+
+The refactor-audit mode of `/dw-brainstorm` checks every candidate module against this framing alongside the Fowler smell taxonomy. A "code smell" can mislead if the construct is actually a deep wrapper doing its job correctly.
+
+## The premise
+
+Good abstractions hide complexity. The metric isn't "how short is the code?" — it's "how much complexity does the interface eliminate per unit of public surface area?"
+
+- **Deep module**: 1000 lines of implementation, 3 public functions. Caller does NOT need to know the 1000 lines.
+- **Shallow module**: 50 lines of implementation, 8 public functions. Caller has to learn all 8 to use the 50 productively.
+- **God-module**: 5000 lines of implementation, 60 public functions. Surface area is itself unmanageable.
+
+The deep version wins not because it's shorter overall (it's longer), but because the cost of using it is concentrated in the implementation, not spread to every caller.
+
+## Diagnostic checklist
+
+When the refactor-audit mode evaluates a module, ask these in order:
+
+### 1. Deletion test
+
+> If this module were deleted, how many call sites would break?
+
+- **0–1 callers**: the module isn't pulling its weight. Inline it; the abstraction is shallower than the call sites' real shape. Mark this as `low` priority candidate for removal.
+- **2–3 callers**: borderline. Look at what each caller does with the result — if they immediately wrap/unwrap, the module is shallow. If they consume the result directly, leave it alone.
+- **4+ callers**: the module is at least somewhat load-bearing. Move to next checks.
+
+### 2. Locality test
+
+> Does the caller pass everything the module needs, OR does the module reach into globals / shared state to fill gaps?
+
+A deep module is **self-contained**: callers pass in arguments, get back results. A module that reads from `process.env`, a shared singleton, or implicit thread-local state has a deeper coupling than its interface admits — the caller has to know about the hidden inputs too.
+
+If the module reaches into shared state, its **effective interface** is bigger than what the function signature shows. That's a hidden shallowness — the public surface lies about its real cost.
+
+### 3. Leverage test
+
+> LOC saved per caller × number of callers — what's the multiplicative payoff?
+
+Crude formula: if each caller would otherwise write ~N lines of inline code to replace this module's call, and there are M callers, the module's leverage is N × M. A module whose leverage is < 2× its own LOC is shallow — it's not absorbing enough complexity to justify itself.
+
+### 4. Seam test
+
+> How often does the public interface change relative to the implementation?
+
+A stable public interface with frequently-changing implementation is the **ideal seam** — callers stay put while internals evolve. An interface that changes every few months means callers track it; the abstraction is leaking.
+
+Check `git log --oneline -- <module>` against `git log --oneline -- <module-public-surface-file>`. If they move together, the seam is weak.
+
+### 5. Adapter test
+
+> Does this module mediate between two foreign vocabularies?
+
+The best deep modules are **adapters** — they translate between two domains that have different naming conventions, error semantics, or state models. A module that doesn't mediate between domains is harder to justify as deep; it's probably either a passthrough (shallow) or just a piece of the same domain stretched across files (cohesion issue).
+
+## Anti-patterns
+
+### Shallow wrapper
+
+```ts
+// shallow — passthrough with one line of "work"
+export function getUserName(id: string) {
+  return db.users.findById(id).name;
+}
+```
+
+The wrapper saves the caller 8 characters (`.name`) and forces them to learn a new function name. The leverage is < 1. Inline it.
+
+When to keep a one-liner: it's an **adapter** that locks down ONE meaning of a query. If `getUserName` exists specifically because there are 4 candidate fields (`name`, `displayName`, `username`, `fullName`) and the team's canonical answer is "use `name`", the function IS pulling its weight by serving as the project's vocabulary anchor. Document the WHY in the function body.
+
+### God-module
+
+A class with 60 public methods is shallow even if each method is 100 lines, because the caller has to learn 60 concepts. Split by **role**: what is the smallest subset of methods a caller typically uses together? Each subset becomes a deep module of its own.
+
+### Implementation-leak abstraction
+
+A module that returns its internal representation directly (`return this.cache;`) makes callers depend on the internals. The first time the cache shape changes, every caller breaks. Wrap or copy on egress.
+
+## When refactor-audit raises a smell, also check deep-modules
+
+The combined verdict:
+
+| Fowler smell | Deep-modules check | Action |
+|--------------|--------------------|--------|
+| Long Method | Is the method INSIDE a deep module that callers don't see? | If yes, leave it — internal complexity is OK in deep modules. If no, extract. |
+| Large Class | Is the public surface narrow despite the line count? | If yes, leave it — that's deep. If no, split by role. |
+| Long Parameter List | Does each parameter represent a real choice the caller makes? | If yes, the deep module is forcing necessary configuration; introduce a config object. If parameters are derivable from each other, reduce. |
+| Feature Envy | Is the module a deep adapter between domains? | If yes, the "envy" is the mediation — keep it. If no, move the logic closer to its data. |
+| Middle Man | Does the middle man absorb any complexity? | If no, delete the middle man. If yes, document the why (it's a deep wrapper). |
+
+A flat "this is too long, extract method" recommendation is shallow analysis. Combining Fowler + deep-modules surfaces when the smell is actually a feature.
+
+## Output for refactor-audit findings
+
+When the audit flags a module as a shallow-wrapper or god-module candidate, the finding entry adds a `Deep-modules: <verdict>` line:
+
+```markdown
+### P1 — Shallow Wrapper
+**Files:** src/lib/getUserName.ts
+**Symptom:** 1-line passthrough wrapper around `db.users.findById(id).name`; 2 callers.
+**Deep-modules:** SHALLOW — fails deletion test (only 2 callers) AND leverage test (0 LOC saved per call).
+**Refactor:** Inline at both call sites. If the wrapper exists for vocabulary reasons, document and keep — otherwise remove.
+**Risk:** Low.
+```

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
 

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