wp-skills 1.0.3 → 1.0.4

package/README.md

@@ -1,6 +1,6 @@
-# WordPress Team Skills
+# WordPress Theme Team Skills
 
-This skill pack helps WordPress teams (classic themes, block themes, and plugins): clear architecture, explicit guardrails, and verification-first workflows.
+This skill pack is optimized for WordPress theme teams (classic and block themes): clear architecture, explicit guardrails, and verification-first workflows.
 
 ## Quick Install
 
@@ -33,7 +33,7 @@ Installed locations:
 ## Team Usage Flow
 
 1. Start with `wordpress-router` or `wp-project-triage` to classify repository context.
-2. Select the domain skill (theme, frontend, plugin/API, ops, review/migration).
+2. Select the domain skill (theme, frontend, ops, review/migration).
 3. Provide explicit inputs: URL/page type, file scope, and compatibility constraints.
 4. Require explicit verification before merge or release.
 
@@ -63,12 +63,6 @@ Prompt examples:
 - [wp-interactivity-api](skills/wp-interactivity-api/README.md)
 - [wpds](skills/wpds/README.md)
 
-### Plugin, API, and capabilities
-
-- [wp-plugin-development](skills/wp-plugin-development/README.md)
-- [wp-rest-api](skills/wp-rest-api/README.md)
-- [wp-abilities-api](skills/wp-abilities-api/README.md)
-
 ### Tooling, ops, and quality
 
 - [wp-wpcli-and-ops](skills/wp-wpcli-and-ops/README.md)
@@ -81,9 +75,36 @@ Prompt examples:
 
 - `classic-theme-dev` + `frontend-wp` + `wp-dev-workflow`
 - `block-theme-dev` + `wp-block-development` + `wp-interactivity-api`
-- `wp-plugin-development` + `wp-rest-api` + `wp-abilities-api`
 - `wp-wpcli-and-ops` + `wp-performance` + `wp-phpstan`
 
+## Dynamic Skill Modes
+
+- `theme-base` (default): work in `wp-content/themes/**`, skip plugins.
+- `plugin-explicit` (opt-in): include plugin scope only when explicitly requested.
+
+Use plugin-explicit mode with triage:
+
+```bash
+npx wp-skills mode plugin-explicit
+```
+
+Use default theme-base mode:
+
+```bash
+npx wp-skills mode theme-base
+```
+
+Recommended plugin mode skills (external set):
+
+- `fullstack.wordpress.plugin-scaffold`
+- `fullstack.wordpress.security-audit`
+- `fullstack.wordpress.performance-audit`
+- `wp-dev-workflow` (for review and migration discipline)
+
+Default guardrail remains:
+
+- `wp-content/plugins/` and `wp-content/mu-plugins/` are treated as third-party and skipped unless plugin-explicit mode is requested.
+
 ## Maintain and Validate
 
 ```bash

package/docs/ai-authorship.md

@@ -34,10 +34,7 @@ All v1 skills followed the same process described above. As skills diverge in th
 | [wp-project-triage](../skills/wp-project-triage/SKILL.md) | Yes | Yes | Yes |
 | [wp-block-development](../skills/wp-block-development/SKILL.md) | Yes | Yes | Yes |
 | [wp-block-themes](../skills/wp-block-themes/SKILL.md) | Yes | Yes | Yes |
-| [wp-plugin-development](../skills/wp-plugin-development/SKILL.md) | Yes | Yes | Yes |
-| [wp-rest-api](../skills/wp-rest-api/SKILL.md) | Yes | Yes | Yes |
 | [wp-interactivity-api](../skills/wp-interactivity-api/SKILL.md) | Yes | Yes | Yes |
-| [wp-abilities-api](../skills/wp-abilities-api/SKILL.md) | Yes | Yes | Yes |
 | [wp-wpcli-and-ops](../skills/wp-wpcli-and-ops/SKILL.md) | Yes | Yes | Yes |
 | [wp-performance](../skills/wp-performance/SKILL.md) | Yes | Yes | Yes |
 | [wp-phpstan](../skills/wp-phpstan/SKILL.md) | Yes | Yes | Yes |

package/docs/skill-set-v1.md

@@ -6,10 +6,7 @@ This repo currently includes:
 - `wp-project-triage`
 - `wp-block-development`
 - `wp-block-themes`
-- `wp-plugin-development`
-- `wp-rest-api`
 - `wp-interactivity-api`
-- `wp-abilities-api`
 - `wp-wpcli-and-ops`
 - `wp-performance`
 - `wp-phpstan`
@@ -25,3 +22,9 @@ Planned next skills (not yet implemented):
 - `wp-build-tooling`
 - `wp-testing`
 - `wp-security`
+
+Optional plugin-focused support can be enabled via external skills when needed:
+
+- `fullstack.wordpress.plugin-scaffold`
+- `fullstack.wordpress.security-audit`
+- `fullstack.wordpress.performance-audit`

package/docs/upstream-sync.md

@@ -34,7 +34,7 @@ This keeps automation deterministic and reviewable before it starts rewriting sk
 - If `git diff` is non-empty, open a PR with:
   - a summary of changes
   - links to upstream release notes
-  - a checklist for human review (“does this impact blocks/themes/plugin workflows?”)
+  - a checklist for human review (“does this impact blocks/themes workflows?”)
 
 ## Validation
 
@@ -49,4 +49,3 @@ The automation should prefer canonical sources and avoid scraping where possible
 - WordPress core releases and API endpoints (official WordPress APIs)
 - Gutenberg releases (GitHub releases)
 - WordPress developer docs (used for the WP↔Gutenberg mapping when no API exists)
-

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wp-skills",
-  "version": "1.0.3",
+  "version": "1.0.4",
   "description": "WordPress Agent Skills installer and packager",
   "license": "Duke Dev",
   "type": "module",

package/shared/scripts/skillpack-cli.mjs

@@ -6,6 +6,7 @@ import { spawnSync } from "node:child_process";
 const scriptDir = path.dirname(fileURLToPath(import.meta.url));
 const buildScript = path.join(scriptDir, "skillpack-build.mjs");
 const installScript = path.join(scriptDir, "skillpack-install.mjs");
+const triageScript = path.join(scriptDir, "..", "..", "skills", "wp-project-triage", "scripts", "detect_wp_project.mjs");
 const packageRoot = path.resolve(scriptDir, "..", "..");
 
 function printUsage() {
@@ -18,11 +19,14 @@ function printUsage() {
       "  install   Install skills into a target repository (default command)",
       "  list      List available skills",
       "  build     Build dist layout for selected targets",
+      "  mode      Run triage in a specific routing mode",
       "",
       "Examples:",
       "  npx wp-skills install --dest=. --targets=codex,vscode,claude,cursor,antigravity",
       "  npx wp-skills list",
       "  npx wp-skills build --out=dist --clean",
+      "  npx wp-skills mode theme-base",
+      "  npx wp-skills mode plugin-explicit",
       "",
     ].join("\n")
   );
@@ -65,6 +69,17 @@ if (command === "list") {
   runNode(installScript, ["--list", ...args]);
 }
 
+if (command === "mode") {
+  const [modeName, ...modeArgs] = rest;
+  if (!modeName || (modeName !== "theme-base" && modeName !== "plugin-explicit")) {
+    process.stderr.write("Usage: wp-skills mode <theme-base|plugin-explicit> [triage-args]\n");
+    process.exit(2);
+  }
+
+  const triageArgs = modeName === "plugin-explicit" ? ["--include-plugins", ...modeArgs] : modeArgs;
+  runNode(triageScript, triageArgs);
+}
+
 const looksLikeFlag = command.startsWith("-");
 if (looksLikeFlag) {
   // Backward-compatible shorthand: treat bare flags as install args.

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

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use block-theme-dev to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use block-theme-dev to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

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

@@ -70,3 +70,8 @@ If migration scope is unclear, ask one question:
 - 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.
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

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

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use classic-theme-dev to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use classic-theme-dev to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

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

@@ -71,3 +71,8 @@ Ask one clarifying question if URL/page target is ambiguous:
 - 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.
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

package/skills/frontend-wp/README.md

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use frontend-wp to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use frontend-wp to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

package/skills/frontend-wp/SKILL.md

@@ -67,3 +67,8 @@ If style system is inconsistent, ask one question:
 - 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.
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

package/skills/wordpress-router/README.md

@@ -2,7 +2,7 @@
 
 ## Purpose
 
-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).
+Use when the user asks about WordPress theme codebases (classic 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, WP-CLI, performance, security, testing, release packaging).
 
 ## Install this skill only
 
@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use wordpress-router to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use wordpress-router to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

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 (classic theme dev, block theme dev, frontend, workflow/review, blocks, REST API, WP-CLI, performance, security, testing, release packaging)."
+description: "Use when the user asks about WordPress theme codebases (classic 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, 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."
 ---
 
@@ -10,7 +10,7 @@ compatibility: "Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent wit
 
 Use this skill at the start of most WordPress tasks to:
 
-- identify what kind of WordPress codebase this is (plugin vs theme vs block theme vs WP core checkout vs full site),
+- identify what kind of WordPress codebase this is (theme vs block theme vs WP core checkout vs full site),
 - pick the right workflow and guardrails,
 - delegate to the most relevant domain skill(s).
 
@@ -21,23 +21,28 @@ Use this skill at the start of most WordPress tasks to:
 
 ## Procedure
 
-1. Run the project triage script:
-   - `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
-2. Read the triage output and classify:
+1. Select routing mode from user intent:
+   - Theme/base work (default): `theme-base`
+   - Plugin coding (explicit request only): `plugin-explicit`
+2. Run the project triage script:
+   - Theme/base: `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
+   - Plugin-explicit: `node skills/wp-project-triage/scripts/detect_wp_project.mjs --include-plugins`
+3. Read the triage output and classify:
    - primary project kind(s),
    - tooling available (PHP/Composer, Node, @wordpress/scripts),
    - tests present (PHPUnit, Playwright, wp-env),
    - any version hints.
-3. Route to domain workflows based on user intent + repo kind:
+4. 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:
+5. Apply guardrails before making changes:
    - Confirm any version constraints if unclear.
    - Prefer the repo’s existing tooling and conventions for builds/tests.
+   - Treat `wp-content/plugins/` and `wp-content/mu-plugins/` as third-party scope and skip by default.
 
 ## Verification
 
@@ -53,4 +58,10 @@ Use this skill at the start of most WordPress tasks to:
 ## Escalation
 
 - If routing is ambiguous, ask one question:
-  - “Is this intended to be a WordPress plugin, a theme (classic/block), or a full site repo?”
+  - “Is this intended to be a theme (classic/block) task, or should third-party plugin code be included explicitly?”
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.
+- For plugin-explicit work, route to plugin-focused skills available in the environment (for example: `fullstack.wordpress.plugin-scaffold`, `fullstack.wordpress.security-audit`, `fullstack.wordpress.performance-audit`).

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

@@ -2,20 +2,23 @@
 
 This is a lightweight routing guide. It assumes you can run `wp-project-triage` first.
 
+## Mode selection (before routing)
+
+- `theme-base` (default): run `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
+- `plugin-explicit` (only when user explicitly asks for plugin coding): run `node skills/wp-project-triage/scripts/detect_wp_project.mjs --include-plugins`
+
 ## Step 1: classify repo kind (from triage)
 
 Use `triage.project.kind` and the strongest signals:
 
 - `wp-core` → treat as WordPress core checkout work (core patches, PHPUnit, build tools).
-- `wp-site` → treat as a full site repo (wp-content present; changes might be theme + plugins).
+- `wp-site` → treat as a full site repo (wp-content present; default scope is `wp-content/themes/*`).
 - `wp-block-theme` → theme.json/templates/patterns workflows.
 - `wp-theme` → classic theme workflows (templates PHP, `functions.php`, `style.css`).
-- `wp-block-plugin` → Gutenberg block development in a plugin (block.json, build pipeline).
-- `wp-plugin` / `wp-mu-plugin` → plugin workflows (hooks, admin, settings, cron, REST, security).
 - `gutenberg` → Gutenberg monorepo workflows (packages, tooling, docs).
 
 If multiple kinds match, prefer the most specific:
-`gutenberg` > `wp-core` > `wp-site` > `wp-block-theme` > `wp-block-plugin` > `wp-theme` > `wp-plugin`.
+`gutenberg` > `wp-core` > `wp-site` > `wp-block-theme` > `wp-theme`.
 
 ## Step 2: route by user intent (keywords)
 
@@ -23,8 +26,6 @@ Route by intent even if repo kind is broad (like `wp-site`):
 
 - **Interactivity API / data-wp-* directives / @wordpress/interactivity / viewScriptModule**
   - Route → `wp-interactivity-api`.
-- **Abilities API / wp_register_ability / wp-abilities/v1 / @wordpress/abilities**
-  - Route → `wp-abilities-api`.
 - **Playground / run-blueprint / build-snapshot / @wp-playground/cli / playground.wordpress.net**
   - Route → `wp-playground`.
 - **Blocks / block.json / registerBlockType / attributes / save serialization**
@@ -39,10 +40,8 @@ Route by intent even if repo kind is broad (like `wp-site`):
   - 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**
-  - Route → `wp-rest-api`.
+- **Plugin scaffold / plugin hardening / plugin performance (plugin-explicit mode)**
+  - Route → `fullstack.wordpress.plugin-scaffold`, `fullstack.wordpress.security-audit`, `fullstack.wordpress.performance-audit`.
 - **WP-CLI / wp-cli.yml / commands**
   - Route → `wp-wpcli-and-ops`.
 - **Build tooling / @wordpress/scripts / webpack / Vite / npm scripts**
@@ -61,3 +60,4 @@ Route by intent even if repo kind is broad (like `wp-site`):
 - Verify detected tooling before suggesting commands (Composer vs npm/yarn/pnpm).
 - Prefer existing lint/test scripts if present.
 - If version constraints aren’t detectable, ask for target WP core and PHP versions.
+- Skip `wp-content/plugins/` and `wp-content/mu-plugins/` by default unless explicitly requested.

package/skills/wp-block-development/README.md

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use wp-block-development to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use wp-block-development to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

package/skills/wp-block-development/SKILL.md

@@ -172,3 +172,8 @@ If you’re uncertain about upstream behavior/version support, consult canonical
 
 - WordPress Developer Resources (Block Editor Handbook, Theme Handbook, Plugin Handbook)
 - Gutenberg repo docs for bleeding-edge behaviors
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

package/skills/wp-block-development/scripts/list_blocks.mjs

@@ -5,6 +5,8 @@ const DEFAULT_IGNORES = new Set([
   ".git",
   "node_modules",
   "vendor",
+  "plugins",
+  "mu-plugins",
   "dist",
   "build",
   "coverage",
@@ -118,4 +120,3 @@ function main() {
 }
 
 main();
-

package/skills/wp-block-themes/README.md

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use wp-block-themes to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use wp-block-themes to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

package/skills/wp-block-themes/SKILL.md

@@ -114,3 +114,8 @@ Common issues:
 If upstream behavior is unclear, consult canonical docs:
 
 - Theme Handbook and Block Editor Handbook for `theme.json`, templates, patterns, and style variations.
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

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

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use wp-dev-workflow to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use wp-dev-workflow to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

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

@@ -67,3 +67,8 @@ Ask one question when scope is ambiguous:
 - 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.
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

package/skills/wp-interactivity-api/README.md

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use wp-interactivity-api to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use wp-interactivity-api to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References
 

package/skills/wp-interactivity-api/SKILL.md

@@ -177,3 +177,8 @@ See `references/debugging.md`.
   - `references/server-side-rendering.md`
   - `references/directives-quickref.md`
   - `references/debugging.md`
+
+## Scope guardrail
+
+- Default scope: first-party theme files (`wp-content/themes/**`) and essential root configuration files.
+- Treat `wp-content/plugins/**` and `wp-content/mu-plugins/**` as third-party and skip by default unless the user explicitly requests plugin scope.

package/skills/wp-performance/README.md

@@ -21,13 +21,13 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 ## When to use
 
 - Apply this skill when your task matches the scope in [SKILL.md](./SKILL.md).
-- Typical trigger prompt: `Use wp-performance to handle this task in my WordPress repo`.
+- Typical trigger prompt: `Use wp-performance to handle this task in my WordPress theme repository`.
 
 ## Inputs to provide
 
 - Repository root (or target project path).
 - Exact task goal (feature, refactor, debugging, migration, or review).
-- Constraints: WordPress/PHP versions, plugin/theme boundaries, timeline/risk constraints.
+- Constraints: WordPress/PHP versions, theme boundaries, timeline/risk constraints.
 
 ## Expected output
 
@@ -37,9 +37,9 @@ node shared/scripts/skillpack-install.mjs --dest=../your-wp-project --targets=co
 
 ## Team guardrails
 
-- Prefer existing repo conventions and tooling over introducing new patterns.
+- Work in first-party theme scope (`wp-content/themes/\*\*`) and essential root config files.
+- Skip `wp-content/plugins/\*\*` and `wp-content/mu-plugins/\*\*` by default (third-party scope).
 - Avoid destructive DB/content operations without explicit approval.
-- Keep backward compatibility visible for production WordPress sites.
 
 ## References