wp-skills 1.0.0 → 1.0.1

package/LICENSE

@@ -1,16 +1,15 @@
-Agent Skills for WordPress
-Copyright (C) 2026 WordPress Contributors
+Duke Dev License
 
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
+Copyright (c) 2026 Duke Dev
+All rights reserved.
 
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
+Permission to use, copy, modify, and distribute this software is granted only
+with explicit written permission from Duke Dev.
 
-You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc.,
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM,
+OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -32,6 +32,10 @@ Agent Skills solve this by giving AI assistants **expert-level WordPress knowled
 | **wp-performance** | Profiling, caching, database optimization, Server-Timing |
 | **wp-phpstan** | PHPStan static analysis for WordPress projects (config, baselines, WP-specific typing) |
 | **wp-playground** | WordPress Playground for instant local environments |
+| **classic-theme-dev** | Classic theme architecture, template hierarchy, URL-to-template-hook mapping, refactoring |
+| **block-theme-dev** | Block theme architecture (`theme.json`, templates/parts, patterns), migration planning |
+| **frontend-wp** | CSS/SCSS architecture, JS behavior, WordPress enqueue/performance patterns |
+| **wp-dev-workflow** | Feature scaffolding, WordPress-focused code review, migration/backward compatibility |
 | **wpds** | WordPress Design System |
 
 ## Quick Start
@@ -154,4 +158,4 @@ node eval/harness/run.mjs
 
 ## License
 
-GPL-2.0-or-later
+Duke Dev

package/docs/skill-set-v1.md

@@ -13,6 +13,12 @@ This repo currently includes:
 - `wp-wpcli-and-ops`
 - `wp-performance`
 - `wp-phpstan`
+- `wp-playground`
+- `wpds`
+- `classic-theme-dev`
+- `block-theme-dev`
+- `frontend-wp`
+- `wp-dev-workflow`
 
 Planned next skills (not yet implemented):
 

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "wp-skills",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "description": "WordPress Agent Skills installer and packager",
-  "license": "GPL-2.0-or-later",
+  "license": "Duke Dev",
   "type": "module",
   "bin": {
     "wp-skills": "shared/scripts/skillpack-cli.mjs",

package/skills/block-theme-dev/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: block-theme-dev
+description: Use when building or migrating WordPress block themes using theme.json, templates/parts, patterns, and custom block integration.
+compatibility: Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node.
+---
+
+# Block Theme Dev
+
+## When to use
+
+Use this skill for block themes and hybrid migrations when the task touches:
+
+- `theme.json` settings/styles,
+- `templates/*.html` and `parts/*.html`,
+- block patterns,
+- classic -> block theme migration,
+- block-theme rendering/debugging in Site Editor workflows.
+
+## Inputs required
+
+- Repo root.
+- Target template/page type or user flow.
+- Desired design/system constraints (colors, spacing, typography, layout).
+- Migration scope (full block theme vs hybrid).
+
+## Procedure
+
+1. Classify and confirm block-theme context:
+   - `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
+   - Confirm signals: `theme.json`, `templates/`, `parts/`, pattern registration.
+2. Audit current theme model:
+   - Review `theme.json` for global styles, presets, spacing/layout constraints.
+   - Map template and part coverage for home/single/page/archive/404/header/footer.
+3. Implement requested change in the smallest stable layer:
+   - Global design tokens -> `theme.json`.
+   - Page structure -> `templates/*.html` and `parts/*.html`.
+   - Reusable content sections -> patterns.
+4. For pattern work:
+   - Use deterministic slugs and categories.
+   - Prefer core blocks and minimal custom CSS hooks.
+   - Ensure pattern markup is editable by content teams.
+5. For classic -> block migration:
+   - Preserve parity first (header/footer/core layouts) before enhancement.
+   - Flag likely breakpoints: shortcode-dependent sections, widget areas, hard-coded template logic.
+   - Keep backward compatibility notes in the response.
+
+## Verification
+
+- Validate changed templates/parts and `theme.json` syntax.
+- Verify intended template selection for target URLs/page types.
+- Run project lint/build/test commands when available.
+
+## Failure modes / debugging
+
+- Styles not applying:
+  - check `theme.json` scope and preset references.
+- Wrong template used:
+  - verify template hierarchy and slug naming.
+- Pattern regressions:
+  - test insertion/editing in editor to ensure block validity.
+
+## Escalation
+
+If migration scope is unclear, ask one question:
+
+- "Do you want full block-theme migration or hybrid with classic templates kept?"
+
+## Do not do
+
+- Do not remove classic templates/widgets without explicit migration approval.
+- Do not hard-code environment-specific URLs/IDs in patterns/templates.
+- Do not bypass validation for block markup changes.

package/skills/classic-theme-dev/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: classic-theme-dev
+description: Use when building, refactoring, or debugging classic WordPress themes with template hierarchy, hooks, and URL-to-template mapping.
+compatibility: Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node.
+---
+
+# Classic Theme Dev
+
+## When to use
+
+Use this skill for classic themes (`style.css` header + PHP templates) when the task involves:
+
+- theme architecture analysis,
+- URL -> template -> hook mapping,
+- template hierarchy decisions,
+- hook/filter-based UI or query customization,
+- refactoring legacy `functions.php` and template logic.
+
+## Inputs required
+
+- Repo root.
+- Target URL or page type (home, single, archive, taxonomy, search).
+- Desired change (UI, query, metadata, behavior).
+- Constraints (child theme policy, backward compatibility requirements).
+
+## Procedure
+
+1. Classify project context:
+   - `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
+   - Confirm classic theme signals: `style.css` theme header, PHP templates, no mandatory `templates/*.html` rendering path.
+2. Build architecture map (text output in response):
+   - Locate registration and bootstrap points with `rg`:
+     - `add_theme_support|register_nav_menus|register_sidebar|add_image_size`
+     - `register_post_type|register_taxonomy|add_shortcode`
+     - `add_action|add_filter|remove_action|remove_filter`
+   - Summarize: request entry -> query shaping -> template chosen -> key hooks/functions used.
+3. Map URL to template/hook path:
+   - Apply template hierarchy rules (`single-{post_type}.php`, `archive-{post_type}.php`, `category-{slug}.php`, etc.).
+   - Check custom overrides (`template_include`, `pre_get_posts`, custom query args).
+   - Provide exact candidate files and hook insertion points.
+4. Implement with safe theme patterns:
+   - Keep templates focused on rendering; move business logic to reusable functions/classes under `inc/` or `src/`.
+   - Prefer `get_template_part()` for repeated sections.
+   - Prefer hooks/filters over invasive template rewrites when possible.
+5. Produce hook map delta when editing hooks:
+   - Note added/changed/removed actions and filters.
+
+## Verification
+
+- Run available project checks from triage output (lint/tests/build).
+- Lint changed PHP files (at minimum `php -l <file>` when toolchain is absent).
+- Confirm affected URL/page type resolves to intended template and no fatal error is introduced.
+
+## Failure modes / debugging
+
+- Wrong template selected:
+  - inspect hierarchy-specific filenames and any `template_include` filters.
+- Query side effects:
+  - verify `pre_get_posts` guards (`is_admin`, `is_main_query`, conditional checks).
+- Mixed classic + block behavior:
+  - check whether hybrid/block templates are taking precedence.
+
+## Escalation
+
+Ask one clarifying question if URL/page target is ambiguous:
+
+- "Which exact URL and user-visible section should be changed?"
+
+## Do not do
+
+- Do not modify database schema/content directly.
+- Do not edit vendor/core/plugin files unless explicitly requested.
+- Do not perform destructive mass replacements without dry-run and approval.

package/skills/frontend-wp/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: frontend-wp
+description: Use when implementing WordPress frontend CSS/SCSS architecture, JavaScript behavior, and asset loading/performance across classic and block themes.
+compatibility: Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node.
+---
+
+# Frontend WP
+
+## When to use
+
+Use this skill when building or refactoring theme frontend behavior and styling for:
+
+- CSS/SCSS architecture,
+- Gutenberg editor vs frontend styling boundaries,
+- JavaScript behavior (menu, modal, accordion, tabs, lazy-load),
+- WordPress enqueue strategy and performance.
+
+## Inputs required
+
+- Repo root and target UI component/page.
+- Existing CSS strategy (BEM, ITCSS, utility-first, custom).
+- Browser/performance constraints and plugin compatibility constraints.
+
+## Procedure
+
+1. Discover stack and conventions:
+   - Identify existing CSS organization and naming rules.
+   - Identify JS build/runtime path and enqueue points (`wp_enqueue_style`, `wp_enqueue_script`).
+2. Align with one style strategy (do not mix ad hoc):
+   - Keep tokens/variables centralized.
+   - Separate base/layout/components/utilities if project supports layering.
+3. Implement styles with editor/frontend separation:
+   - Frontend styles for site output.
+   - Editor-specific styles only when necessary for parity.
+4. Implement JS behavior with WP-safe loading:
+   - Register/enqueue with dependencies and predictable handles.
+   - Avoid inline JS unless no alternative exists.
+   - Ensure behavior degrades safely if dependency is missing.
+5. Optimize delivery:
+   - Avoid duplicate bundles.
+   - Load only where needed.
+   - Minimize conflicts with plugins/page builders by scoping selectors and events.
+
+## Verification
+
+- Validate no console errors on affected pages.
+- Validate behavior works without breaking editor experience.
+- Run available lint/build/test commands.
+
+## Failure modes / debugging
+
+- Style leaks:
+  - tighten selector scope and component boundaries.
+- Script conflicts:
+  - verify handle uniqueness and dependency order.
+- Editor mismatch:
+  - check editor-only style loading and block wrapper classes.
+
+## Escalation
+
+If style system is inconsistent, ask one question:
+
+- "Should I standardize this change on the current project convention or introduce a new CSS architecture now?"
+
+## Do not do
+
+- Do not add large frontend dependencies without explicit approval.
+- Do not enqueue global assets for single-page-only features unless requested.
+- Do not use brittle selectors tied to dynamic plugin-generated markup when stable hooks exist.

package/skills/wordpress-router/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wordpress-router
-description: "Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing, release packaging)."
+description: "Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (classic theme dev, block theme dev, frontend, workflow/review, blocks, REST API, WP-CLI, performance, security, testing, release packaging)."
 compatibility: "Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node. Some workflows require WP-CLI."
 ---
 
@@ -30,6 +30,11 @@ Use this skill at the start of most WordPress tasks to:
    - any version hints.
 3. Route to domain workflows based on user intent + repo kind:
    - For the decision tree, read: `skills/wordpress-router/references/decision-tree.md`.
+   - Prefer team-package skills when the request spans multiple concerns:
+     - `classic-theme-dev`
+     - `block-theme-dev`
+     - `frontend-wp`
+     - `wp-dev-workflow`
 4. Apply guardrails before making changes:
    - Confirm any version constraints if unclear.
    - Prefer the repo’s existing tooling and conventions for builds/tests.

package/skills/wordpress-router/references/decision-tree.md

@@ -30,7 +30,15 @@ Route by intent even if repo kind is broad (like `wp-site`):
 - **Blocks / block.json / registerBlockType / attributes / save serialization**
   - Route → `wp-block-development`.
 - **theme.json / Global Styles / templates/*.html / patterns/**
-  - Route → `wp-block-themes`.
+  - Route → `block-theme-dev` (team package), or `wp-block-themes` for focused theme.json/template guidance.
+- **Classic templates / template hierarchy / get_template_part / functions.php refactor**
+  - Route → `classic-theme-dev`.
+- **URL to template mapping / pre_get_posts / theme hook map**
+  - Route → `classic-theme-dev`.
+- **Frontend CSS/SCSS architecture / enqueue assets / JS behavior in themes**
+  - Route → `frontend-wp`.
+- **Feature scaffolding / WordPress code review / migration + backward compatibility**
+  - Route → `wp-dev-workflow`.
 - **Plugins / hooks / activation hook / uninstall / Settings API / admin pages**
   - Route → `wp-plugin-development`.
 - **REST endpoint / register_rest_route / permission_callback**

package/skills/wp-dev-workflow/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: wp-dev-workflow
+description: Use when scaffolding WordPress features, performing WordPress-focused code review, and planning migrations with backward compatibility safeguards.
+compatibility: Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node. Some workflows require WP-CLI.
+---
+
+# WP Dev Workflow
+
+## When to use
+
+Use this skill for team workflow tasks that cut across theme/plugin/block work:
+
+- feature scaffolding and boilerplate,
+- WordPress-focused code review,
+- migration planning and backward compatibility checks,
+- release-readiness checklists.
+
+## Inputs required
+
+- Repo root.
+- Task type: scaffold, review, or migration.
+- Scope and constraints (deadline, risk tolerance, compatibility target versions).
+
+## Procedure
+
+1. Classify project and tooling first:
+   - `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
+2. Choose workflow path:
+   - Scaffold path: generate files/hooks/entry points aligned with existing architecture.
+   - Review path: inspect security/perf/maintainability issues with concrete file-level findings.
+   - Migration path: produce checklist and rollout plan with rollback steps.
+3. Scaffold path requirements:
+   - Create minimal working structure with TODO markers only where needed.
+   - Include hook insertion points and test targets.
+4. Review path requirements:
+   - Security checks: nonce, capability checks, sanitization, escaping, REST permissions.
+   - Performance checks: query volume, cache strategy, asset load scope.
+   - Maintainability checks: separation of concerns, function/class size, duplicated logic.
+5. Migration path requirements:
+   - Track entities impacted: templates, blocks, CPT/taxonomy, metadata, shortcodes, URLs.
+   - Detect backward-compat traps: hard-coded IDs, legacy hooks, brittle serialized content.
+   - Prefer reversible changes and phased rollout.
+
+## Verification
+
+- Run available lint/build/tests from project tooling.
+- For migrations, provide explicit pre/post verification checklist.
+- For reviews, prioritize findings by severity and include exact file references.
+
+## Failure modes / debugging
+
+- Incomplete migration scope:
+  - re-check content dependencies (blocks/shortcodes/meta) and CLI scripts.
+- Review without actionable output:
+  - convert general comments into concrete patch suggestions.
+- Scaffold drift:
+  - ensure generated structure matches current repo conventions.
+
+## Escalation
+
+Ask one question when scope is ambiguous:
+
+- "Should I optimize for fastest delivery or safest migration/review depth?"
+
+## Do not do
+
+- Do not run destructive DB/content operations without explicit approval.
+- Do not claim migration safety without listing verified checks.
+- Do not introduce new architecture patterns that conflict with existing team standards unless requested.

package/skills/wp-project-triage/SKILL.md

@@ -25,7 +25,12 @@ Use this skill to quickly understand what kind of WordPress repo you’re in and
    - PHP/Node tooling present
    - tests present
    - version hints and sources
-4. If the report is missing signals you need, update the detector rather than guessing.
+4. Route to the right execution skill from classification:
+   - `wp-theme` -> `classic-theme-dev`
+   - `wp-block-theme` -> `block-theme-dev`
+   - frontend implementation tasks -> `frontend-wp`
+   - scaffolding/review/migration tasks -> `wp-dev-workflow`
+5. If the report is missing signals you need, update the detector rather than guessing.
 
 ## Verification