rsc-universal 0.1.1

package/skills/whatsapp-telegram/scripts/verify.sh

@@ -0,0 +1,90 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# verify.sh — whatsapp-telegram integration gate. Read-only, never writes.
+#
+# Statically greps the integration code in the TARGET dir (arg 1, default: cwd) for the known
+# WhatsApp/Telegram footguns this skill warns about:
+#   1. Every WhatsApp Graph send URL pins a version — fail on a versionless graph.facebook.com call.
+#   2. No hardcoded WhatsApp bearer tokens (EAA...) or Telegram bot tokens (\d{8,10}:[A-Za-z0-9_-]{35}).
+#   3. A file that polls getUpdates must not also call setWebhook (mutually exclusive).
+#   4. Advisory: if a free-form WhatsApp send exists, a template-send path should exist too.
+#
+# Artifact-conditional: if no integration files are found, exit 0 with a [skip] (safe to run
+# anywhere — an empty/clean target NEVER fails). Exit non-zero ONLY on a real footgun, with paths.
+#
+# Portability: stock macOS bash 3.2 — no mapfile, no associative arrays, arrays initialised.
+
+YELLOW=$'\033[33m'; GREEN=$'\033[32m'; RED=$'\033[31m'; NC=$'\033[0m'
+EXIT=0
+skip() { printf '%s[skip]%s %s\n' "$YELLOW" "$NC" "$*"; }
+ok()   { printf '%s[ok]%s %s\n'   "$GREEN"  "$NC" "$*"; }
+err()  { printf '%s[fail]%s %s\n' "$RED"    "$NC" "$*"; EXIT=1; }
+
+TARGET="${1:-$(pwd)}"
+if [ ! -d "$TARGET" ]; then
+  skip "target '$TARGET' is not a directory — nothing to check"
+  exit 0
+fi
+
+# Collect candidate integration source files (skip deps / vcs / build output). Initialised array.
+FILES=()
+while IFS= read -r -d '' f; do
+  FILES+=("$f")
+done < <(find "$TARGET" \
+  \( -path '*/node_modules' -o -path '*/.git' -o -path '*/dist' -o -path '*/build' -o -path '*/.next' -o -path '*/vendor' \) -prune -o \
+  -type f \( -name '*.ts' -o -name '*.tsx' -o -name '*.js' -o -name '*.mjs' -o -name '*.py' -o -name '*.go' -o -name '*.rb' -o -name '*.sh' -o -name '*.json' \) -print0 2>/dev/null)
+
+# Keep only files that actually touch one of the two platforms.
+RELEVANT=()
+for f in "${FILES[@]:-}"; do
+  [ -n "$f" ] || continue
+  if grep -Eql 'graph\.facebook\.com|api\.telegram\.org|messaging_product' "$f" 2>/dev/null; then
+    RELEVANT+=("$f")
+  fi
+done
+
+if [ "${#RELEVANT[@]:-0}" -eq 0 ]; then
+  skip "no WhatsApp/Telegram integration files found under $TARGET — nothing to check"
+  exit 0
+fi
+ok "scanning ${#RELEVANT[@]} integration file(s)"
+
+# ---- 1. WhatsApp Graph URL must pin a version ----
+HITS="$(grep -EnH 'graph\.facebook\.com/[^v"'"'"'\`/[:space:]]' "${RELEVANT[@]}" 2>/dev/null \
+  | grep -Ev 'graph\.facebook\.com/v[0-9]+' || true)"
+if [ -n "$HITS" ]; then
+  err "versionless graph.facebook.com URL (pin v25.0):"
+  printf '%s\n' "$HITS"
+else
+  ok "WhatsApp Graph URLs are version-pinned"
+fi
+
+# ---- 2. no hardcoded tokens ----
+# WhatsApp access tokens start EAA...; Telegram bot tokens look like 123456789:AA....(35 chars).
+TOK="$(grep -EnH "EAA[A-Za-z0-9_-]{20,}|[0-9]{8,10}:[A-Za-z0-9_-]{35}" "${RELEVANT[@]}" 2>/dev/null || true)"
+if [ -n "$TOK" ]; then
+  err "hardcoded token literal (move to an env var):"
+  printf '%s\n' "$TOK"
+else
+  ok "no hardcoded WhatsApp/Telegram token literals"
+fi
+
+# ---- 3. setWebhook and getUpdates not in the same file ----
+for f in "${RELEVANT[@]}"; do
+  if grep -Eql 'getUpdates' "$f" 2>/dev/null && grep -Eql 'setWebhook' "$f" 2>/dev/null; then
+    err "both getUpdates and setWebhook in one file (pick one): $f"
+  fi
+done
+if [ "$EXIT" -eq 0 ]; then ok "no getUpdates+setWebhook conflict"; fi
+
+# ---- 4. advisory: free-form send should pair with a template path ----
+if grep -Eql '"type"[[:space:]]*:[[:space:]]*"text"|type:[[:space:]]*"text"' "${RELEVANT[@]}" 2>/dev/null; then
+  if ! grep -Eql '"type"[[:space:]]*:[[:space:]]*"template"|type:[[:space:]]*"template"' "${RELEVANT[@]}" 2>/dev/null; then
+    skip "advisory: free-form WhatsApp send found but no template path — out-of-window sends will hit #131047"
+  fi
+fi
+
+printf '\n'
+if [ "$EXIT" -eq 0 ]; then ok "verify.sh passed"; else err "verify.sh found footguns"; fi
+exit "$EXIT"

package/skills/wordpress/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: wordpress
+description: "Use when building or hardening WordPress sites or WooCommerce stores — block themes with theme.json v3, plugins with block.json and proper hooks, wp-config security hardening, performance (object cache, asset loading, speculative loading), and WP-CLI operations — and you are treating WordPress as the product, not just writing PHP. Triggers: 'build a WordPress block theme', 'write a WP plugin', 'harden my WordPress install', 'enable HPOS in WooCommerce', 'wp search-replace migration', 'why is my wp-admin slow', 'autoloaded options are huge', 'endurece mi WordPress', 'crea un tema de bloques'. NOT a Laravel app (that is laravel)."
+tags: [wordpress, woocommerce, block-themes, wp-cli, php, security-hardening, performance]
+recommends: [php, secure-coding, performance, mysql, shopify]
+origin: risco
+---
+
+# WordPress
+
+You are building the WordPress application layer — themes, plugins, the dashboard/CLI surface, security, and stores — for someone treating WordPress as the product. Know the difference between a `functions.php` hack and a real plugin. Refuse to paste secrets into the dashboard file editor. Pick block themes over page builders by default. Reach for `wp` before clicking through wp-admin.
+
+This is not generic PHP. If there is no WordPress API in sight (value objects, Composer/PSR-4, PHPStan), that is [php](../php/SKILL.md). A Laravel app is [laravel](../laravel/SKILL.md).
+
+## Version & runtime targeting
+
+Target current. Stale version assumptions are the most common way WP code rots.
+
+- **WordPress 6.9** (released 2025-12-02) is current; it refines speculative loading and supports PHP 8.5. WP 6.8 ("Cecil", 2025-04-15) added bcrypt password hashing and speculative loading. *Why: features below assume 6.6+ APIs (`wp_enqueue_block_style`, theme.json v3).*
+- **PHP 8.4 is the recommended runtime for 2026.** WP 6.9 fully supports PHP 8.5; WP 6.8+ fully supports 8.4; WP 6.4+ supports 8.3. **Never target PHP 7.x or 8.0–8.2 for new code — all EOL.** *Why: writing for a dead runtime ships deprecation bugs the host will eventually refuse to run.*
+- **theme.json v3** is the schema for new block themes (WP 6.6+). Locally set `WP_DEVELOPMENT_MODE` to `all` so theme.json edits are not cached for 30+ seconds. *Why: without it you will edit theme.json, see nothing change, and waste an hour.*
+
+```php
+// wp-config.php — local dev only, never on production
+define( 'WP_DEVELOPMENT_MODE', 'all' );
+define( 'WP_DEBUG', true );
+define( 'SCRIPT_DEBUG', true );
+```
+
+## Decision: how heavy is the change?
+
+Pick the lightest artifact that survives an update. The failure mode is everyone reaching for `functions.php` or editing files that get overwritten.
+
+| You need to… | Artifact | Do NOT |
+| --- | --- | --- |
+| One-line tweak, site-specific behavior | mu-plugin in `wp-content/mu-plugins/` | dump it in the active theme's `functions.php` |
+| Change look of a third-party theme | **child theme** | edit the parent theme — updates wipe it |
+| Reusable feature, hooks, blocks, CPTs | **standalone plugin** | hide app logic in `functions.php` |
+| Full custom front end | **block theme** + theme.json v3 | reach for a page builder for structural layout |
+| Sell products | block theme + **WooCommerce** | hand-roll a cart |
+
+## Block themes
+
+A block theme is `theme.json` + HTML templates in `templates/` and `parts/`. Start from a v3 skeleton:
+
+```json
+{
+  "$schema": "https://schemas.wp.org/trunk/theme.json",
+  "version": 3,
+  "settings": {
+    "appearanceTools": true,
+    "color": {
+      "palette": [
+        { "slug": "base", "color": "#ffffff", "name": "Base" },
+        { "slug": "contrast", "color": "#111111", "name": "Contrast" }
+      ]
+    },
+    "typography": {
+      "fluid": true,
+      "fontFamilies": [
+        { "fontFamily": "system-ui, sans-serif", "slug": "system", "name": "System" }
+      ]
+    },
+    "layout": { "contentSize": "640px", "wideSize": "1100px" }
+  },
+  "styles": {
+    "color": { "background": "var(--wp--preset--color--base)", "text": "var(--wp--preset--color--contrast)" }
+  }
+}
+```
+
+Templates resolve by hierarchy: `templates/index.html` is the fallback; `single.html`, `archive.html`, `page.html`, `404.html` override it. Reusable chunks live in `parts/` (`header.html`, `footer.html`).
+
+Register patterns by dropping PHP-headered HTML in `patterns/`; they appear in the inserter automatically. Enqueue CSS **per block** so it only loads when the block renders:
+
+```php
+add_action( 'init', function () {
+	wp_enqueue_block_style( 'core/group', array(
+		'handle' => 'mytheme-group',
+		'src'    => get_theme_file_uri( 'assets/blocks/group.css' ),
+		'path'   => get_theme_file_path( 'assets/blocks/group.css' ),
+	) );
+} );
+```
+
+Rule: never hand-write `<link>`/`<script>` tags in templates — the browser cannot cache them and you lose dependency management. Always enqueue. And never edit a parent theme directly; make a child theme.
+
+## Plugins
+
+A plugin is a folder with a headered main file. That header is what makes it a plugin:
+
+```php
+<?php
+/**
+ * Plugin Name: Acme Books
+ * Description: Registers the book CPT and a related block.
+ * Version:     1.0.0
+ * Requires PHP: 8.4
+ * Requires at least: 6.9
+ */
+defined( 'ABSPATH' ) || exit; // never expose a direct hit
+```
+
+Hooks split two ways: **actions** fire at a point in execution (`add_action('init', …)`); **filters** transform a value and must `return` it (`add_filter('the_content', …)`). Confusing them is a top-five WP bug.
+
+Register a block from a `block.json` — never duplicate metadata in PHP:
+
+```php
+add_action( 'init', function () {
+	register_block_type( __DIR__ . '/build/related-books' ); // reads block.json
+} );
+```
+
+Register a custom post type with explicit capabilities and labels:
+
+```php
+add_action( 'init', function () {
+	register_post_type( 'book', array(
+		'public'       => true,
+		'show_in_rest' => true, // required for the block editor
+		'supports'     => array( 'title', 'editor', 'thumbnail' ),
+		'labels'       => array( 'name' => 'Books', 'singular_name' => 'Book' ),
+	) );
+} );
+```
+
+Every write path needs a **capability check + nonce**, and every output/query needs escaping/sanitizing. This is the line between a plugin and a vulnerability.
+
+```php
+// Bad — SQL injection, no auth
+$rows = $wpdb->get_results( "SELECT * FROM {$wpdb->posts} WHERE post_author = $id" );
+
+// Good — capability, nonce, prepared statement
+if ( ! current_user_can( 'edit_posts' ) ) { wp_die( 'nope' ); }
+check_admin_referer( 'acme_save' );
+$rows = $wpdb->get_results( $wpdb->prepare(
+	"SELECT * FROM {$wpdb->posts} WHERE post_author = %d", $id
+) );
+echo esc_html( $rows[0]->post_title );
+```
+
+Sanitize on input (`sanitize_text_field`, `absint`), escape on output (`esc_html`, `esc_attr`, `esc_url`, `wp_kses` for allowed HTML).
+
+## Security hardening
+
+The single highest-impact habit is keeping core, plugins, and themes updated — 2024 saw 7,966 new ecosystem vulnerabilities, +34% YoY, and the vast majority hit known-vulnerable extensions. Baseline `wp-config.php` constants:
+
+```php
+define( 'DISALLOW_FILE_EDIT', true );  // kills dashboard Theme/Plugin editor; SFTP/Git unaffected
+define( 'WP_AUTO_UPDATE_CORE', 'minor' );
+define( 'FORCE_SSL_ADMIN', true );
+```
+
+Use **Application Passwords** (WP 5.6+) for REST/API machine auth — individually revocable, cannot log into `wp-login.php`, and the right answer when a script or [nextjs](../nextjs/SKILL.md) front end needs to talk to WP. Never reuse the admin password in a script.
+
+For the full block — file-permission matrix (dirs 755 / files 644 / wp-config 600), `DISALLOW_FILE_MODS`, nginx/.htaccess security headers, login lockdown, XML-RPC and user-enumeration disabling, version-disclosure removal — see [references/hardening.md](references/hardening.md). Generic OWASP/threat-modeling not tied to the WP attack surface is [secure-coding](../secure-coding/SKILL.md).
+
+## Performance
+
+Two caches, different jobs: an **object cache** (Redis/Memcached via a drop-in) memoizes DB query results across requests; a **page cache** stores whole rendered HTML pages. You usually want both. Then:
+
+- **Audit autoloaded options** first when wp-admin crawls — a few MB of autoloaded junk loads on *every* request. Find offenders with the SQL in the reference.
+- Enqueue assets per block (above); defer/async non-critical scripts.
+- Speculative loading (prerender/prefetch on hover) ships in 6.8+; tune it rather than bolting on a plugin.
+
+Full Redis wiring, the autoload audit query, transients, and a WP-tied Core Web Vitals checklist are in [references/performance.md](references/performance.md). Generic CWV/load-testing methodology divorced from WordPress is the [performance](../performance/SKILL.md) sibling.
+
+## WooCommerce
+
+**HPOS** (High-Performance Order Storage) is the default order datastore for new installs since WooCommerce 8.2 — orders live in dedicated tables, not `wp_posts`. Enable/migrate and verify with WP-CLI:
+
+```bash
+wp wc hpos enable            # turn on custom order tables
+wp wc cot sync               # backfill/sync existing orders
+wp wc cot verify_cot_data    # confirm parity before flipping authority
+```
+
+Any plugin that touches orders **must declare HPOS compatibility**, or WooCommerce disables it in HPOS mode:
+
+```php
+add_action( 'before_woocommerce_init', function () {
+	if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
+		\Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
+			'custom_order_tables', __FILE__, true
+		);
+	}
+} );
+```
+
+Store/checkout/product setup checklist and migration caveats: [references/woocommerce.md](references/woocommerce.md). A Shopify store is the [shopify](../shopify/SKILL.md) sibling.
+
+## WP-CLI & local dev
+
+`wp` is the operational backbone — scriptable, faster than the dashboard, and safe on serialized data.
+
+- **Local stack:** `wp-env start` (Dockerized WP). Scaffold a block/plugin with `npx @wordpress/create-block acme-block`.
+- **Migrations:** `wp search-replace` is serialization-safe — never run a raw SQL `REPLACE` on the DB, it corrupts serialized arrays. Dry-run first:
+
+```bash
+wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables --dry-run
+wp db export backup.sql        # always export before a real run
+wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables
+```
+
+- **Cron:** WP's pseudo-cron only fires on traffic. For reliable schedules, define `DISABLE_WP_CRON` true and run `wp cron event run --due-now` from real system cron.
+
+## Anti-patterns
+
+| Anti-pattern | Why it's wrong | Do instead |
+| --- | --- | --- |
+| App logic in `functions.php` | Dies with the theme; not portable | Standalone plugin or mu-plugin |
+| Editing a parent theme / core files | Wiped on update | Child theme; hooks/filters |
+| `query_posts()` | Breaks the main query, no pagination | `WP_Query` or `pre_get_posts` |
+| `$wpdb->query("… $var …")` | SQL injection | `$wpdb->prepare()` with `%d`/`%s` |
+| `<script src>`/`<link>` in templates | Not cached, no dependency graph | `wp_enqueue_script/style`, `wp_enqueue_block_style` |
+| Secrets pasted in dashboard file editor | Logged, world-readable, version-control blind | `wp-config.php` constants + `DISALLOW_FILE_EDIT` |
+| Page builder for structural layout | Bloat, lock-in, broken CWV | Block theme + patterns |
+| Disabling auto-updates, never patching | 7,966 vulns/yr land on stale plugins | `WP_AUTO_UPDATE_CORE`; `wp plugin update --all` |
+| Raw SQL `REPLACE` to change URLs | Corrupts serialized data | `wp search-replace` |
+| Order-touching plugin without HPOS declaration | WooCommerce disables it | `FeaturesUtil::declare_compatibility` |
+
+## verify.sh
+
+`scripts/verify.sh <path>` statically scans theme/plugin/config code for these anti-patterns — committed DB creds or `AUTH_KEY`/salt literals, missing `DISALLOW_FILE_EDIT` when a `wp-config.php` is in scope, `eval(`/`base64_decode(`, `query_posts(`, unprepared `$wpdb` interpolation, and hardcoded `<script src=`/`<link rel="stylesheet">` in PHP templates. Read-only; exits 0 on a clean or empty target, non-zero on any FAIL so it can gate CI.

package/skills/wordpress/evals/README.md

@@ -0,0 +1,3 @@
+# Evals: wordpress
+
+`cases.yaml` checks routing and capability for the wordpress skill. `should_trigger` lists prompts (including a non-obvious HPOS migration and Spanish/Catalan phrasings) that must select this skill; `should_not_trigger` lists adjacent prompts that must route to a named sibling (php, laravel, shopify, secure-coding, nextjs). The `capability` block is a scaffolding scenario with a `must_include` rubric. There is no automated runner here — evaluate by hand or with your harness: read each `should_trigger`/`should_not_trigger` prompt, confirm the skill description would (or would not) match and that the route_to sibling is the better home, then run the capability scenario against the skill and check the produced plugin hits every rubric line. A case fails if the skill mis-routes or the output misses a `must_include` item.

package/skills/wordpress/evals/cases.yaml

@@ -0,0 +1,50 @@
+skill: wordpress
+
+should_trigger:
+  - prompt: "Build me a custom WordPress block theme with theme.json and a few templates"
+    why: Core block-theme authoring — theme.json v3, template hierarchy, patterns.
+  - prompt: "Harden this WordPress install before launch — lock down the dashboard and config"
+    why: Security baseline (DISALLOW_FILE_EDIT, permissions, login lockdown) is owned here.
+  - prompt: "Enable HPOS on our WooCommerce store and migrate the existing orders"
+    why: Non-obvious — store datastore migration via wp wc cot/hpos CLI, plugin compatibility.
+  - prompt: "Why is wp-admin crawling? someone said our autoloaded options are huge"
+    why: WP-specific performance — autoload audit, object cache — not generic CWV.
+  - prompt: "endurece mi WordPress y desactiva el editor de archivos del panel"
+    why: Spanish phrasing for hardening + DISALLOW_FILE_EDIT; same capability, must trigger.
+  - prompt: "Write a WP plugin that registers a 'book' custom post type and a related block"
+    why: Plugin authoring — plugin header, register_post_type, block.json/register_block_type.
+  - prompt: "crea un tema de bloques y haz un wp search-replace de staging a producción"
+    why: Catalan/Spanish + serialization-safe migration recipe, both core to this skill.
+
+should_not_trigger:
+  - prompt: "Refactor this PHP value object to use property hooks and pass PHPStan level max"
+    route_to: php
+    why: Pure language work, no WordPress API in sight.
+  - prompt: "Set up an Eloquent model with a Blade view and an Artisan command"
+    route_to: laravel
+    why: Laravel framework, not WordPress.
+  - prompt: "Build my Shopify storefront theme in Liquid with sections and metafields"
+    route_to: shopify
+    why: Different commerce platform entirely.
+  - prompt: "Do an OWASP threat model of my Express API and its auth flow"
+    route_to: secure-coding
+    why: Generic web security not tied to the WordPress attack surface.
+  - prompt: "Build a Next.js front end that reads the WordPress REST API and renders posts"
+    route_to: nextjs
+    why: The React/front-end side of a headless split; WordPress owns only the back end.
+
+capability:
+  - scenario: >
+      Scaffold a hardened, WooCommerce-ready WordPress plugin that registers a 'book'
+      custom post type plus a related-books block, declares HPOS compatibility, and is
+      safe to commit to a public repo.
+    must_include:
+      - "Proper plugin header (Plugin Name, Version, Requires PHP 8.4+, Requires at least 6.9)"
+      - "ABSPATH guard so the file cannot be hit directly"
+      - "register_post_type for 'book' with show_in_rest, explicit supports and labels"
+      - "block.json + register_block_type( __DIR__ . '/build/...' ) — no metadata duplicated in PHP"
+      - "current_user_can capability check AND a nonce on any write/save path"
+      - "$wpdb->prepare() for any query (or no raw SQL); output escaped with esc_html/esc_attr"
+      - "FeaturesUtil::declare_compatibility('custom_order_tables', __FILE__, true) on before_woocommerce_init"
+      - "No hardcoded secrets, DB creds, or AUTH_KEY/salt literals"
+      - "Deploy note recommending DISALLOW_FILE_EDIT and keeping plugins updated"

package/skills/wordpress/references/hardening.md

@@ -0,0 +1,108 @@
+# WordPress hardening
+
+The full baseline behind the SKILL.md security section. Apply top-down; each item closes a real attack path.
+
+## wp-config.php constants
+
+```php
+// Block code edits from the dashboard entirely
+define( 'DISALLOW_FILE_EDIT', true );   // no Theme/Plugin code editor
+define( 'DISALLOW_FILE_MODS', true );   // also no install/update from UI (lock managed hosts)
+
+// Transport & cookies
+define( 'FORCE_SSL_ADMIN', true );
+
+// Updates — keep minor/security patches automatic
+define( 'WP_AUTO_UPDATE_CORE', 'minor' );
+
+// Move wp-config one level above webroot when the host allows it.
+```
+
+Regenerate the salt keys (`AUTH_KEY`, `SECURE_AUTH_KEY`, `LOGGED_IN_KEY`, `NONCE_KEY` and their salts) from `https://api.wordpress.org/secret-key/1.1/salt/`. These are the only "secrets" that belong in `wp-config.php`. Never commit a real `wp-config.php` with live values — ship a `wp-config-sample.php` and inject via environment on deploy.
+
+## File permission matrix
+
+| Target | Mode | Note |
+| --- | --- | --- |
+| Directories | `755` | `find . -type d -exec chmod 755 {} \;` |
+| Files | `644` | `find . -type f -exec chmod 644 {} \;` |
+| `wp-config.php` | `600` (or `640`) | readable only by the web user |
+| `wp-content/uploads` | `755`, no PHP execution | block `*.php` there |
+
+The web server user should own files but not be able to write to core/theme/plugin dirs in production — write access is what turns a single upload bug into RCE.
+
+## Block PHP execution in uploads
+
+nginx:
+
+```nginx
+location ~* /wp-content/uploads/.*\.php$ { deny all; }
+```
+
+Apache (`wp-content/uploads/.htaccess`):
+
+```apache
+<FilesMatch "\.php$">
+  Require all denied
+</FilesMatch>
+```
+
+## Security headers
+
+nginx:
+
+```nginx
+add_header X-Content-Type-Options "nosniff" always;
+add_header X-Frame-Options "SAMEORIGIN" always;
+add_header Referrer-Policy "strict-origin-when-cross-origin" always;
+add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
+```
+
+## Login & account hardening
+
+- Enforce strong passwords and a 2FA/passkey plugin; WP 6.8 introduced bcrypt password hashing so legacy hashes are upgraded transparently on next login.
+- Rate-limit `wp-login.php` (fail2ban, host WAF, or a lockout plugin). Brute force is the most common automated attack.
+- Never ship a user literally named `admin`. Use least-privilege roles; editors do not need `manage_options`.
+
+## Application Passwords (machine auth)
+
+For REST/API access — a headless front end, CI, an integration — issue an Application Password (WP 5.6+) per consumer:
+
+```bash
+wp user application-password create admin "ci-deploy" --porcelain
+```
+
+They are individually revocable, do not grant `wp-login.php` access, and bypass interactive 2FA for machines. Send as HTTP Basic over TLS:
+
+```bash
+curl --user 'admin:xxxx xxxx xxxx xxxx xxxx xxxx' https://example.com/wp-json/wp/v2/posts
+```
+
+Revoke from Users → Profile → Application Passwords (or `wp user application-password delete`) when a consumer is retired.
+
+## Reduce attack surface
+
+```php
+// Stop user enumeration via the REST users endpoint for anonymous callers
+add_filter( 'rest_endpoints', function ( $endpoints ) {
+	unset( $endpoints['/wp/v2/users'], $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
+	return $endpoints;
+} );
+
+// Remove version disclosure
+remove_action( 'wp_head', 'wp_generator' );
+```
+
+Disable XML-RPC unless something genuinely needs it (`add_filter('xmlrpc_enabled','__return_false')`) — it is a pingback-amplification and brute-force vector. Block `/xmlrpc.php` at the server when fully unused.
+
+## Update discipline
+
+2024 logged 7,966 new ecosystem vulnerabilities (+34% YoY); nearly all exploited installs were running a known-vulnerable plugin/theme. The cheapest defense is patching:
+
+```bash
+wp core update && wp core update-db
+wp plugin update --all
+wp theme update --all
+```
+
+Automate via cron + a staging smoke test before production.

package/skills/wordpress/references/performance.md

@@ -0,0 +1,80 @@
+# WordPress performance
+
+The depth behind the SKILL.md performance section. Order matters: measure first, fix the biggest object on the page, then cache.
+
+## Two caches, different jobs
+
+| Cache | Stores | Wins | Tool |
+| --- | --- | --- | --- |
+| Object cache | DB query results, computed values, transients | repeated/admin requests, logged-in users | Redis or Memcached drop-in |
+| Page cache | full rendered HTML responses | anonymous traffic | host page cache, reverse proxy, plugin |
+
+You usually want both. The object cache is what speeds up a slow wp-admin (logged-in, uncacheable pages).
+
+## Redis object cache wiring
+
+Install the Redis PHP extension and a drop-in (e.g. the Redis Object Cache plugin ships `object-cache.php` into `wp-content/`). Configure in `wp-config.php`:
+
+```php
+define( 'WP_REDIS_HOST', '127.0.0.1' );
+define( 'WP_REDIS_PORT', 6379 );
+define( 'WP_REDIS_PREFIX', 'site1:' );   // isolate keys per site on a shared Redis
+define( 'WP_CACHE', true );
+```
+
+Verify it is actually serving:
+
+```bash
+wp redis status
+wp cache flush          # after deploys that change cached data
+```
+
+## Audit autoloaded options first
+
+When wp-admin crawls, the usual culprit is multi-MB autoloaded options loaded on *every* request (orphaned plugin data, runaway transients). Find offenders:
+
+```sql
+SELECT option_name, ROUND(LENGTH(option_value)/1024) AS size_kb
+FROM wp_options
+WHERE autoload IN ('yes','on','auto')
+ORDER BY LENGTH(option_value) DESC
+LIMIT 20;
+```
+
+Or via CLI:
+
+```bash
+wp option list --autoload=on --format=table --fields=option_name,size --orderby=size --order=desc | head -20
+```
+
+Set genuinely-not-needed-everywhere options to `autoload = no`, and delete orphaned plugin rows. Clean expired transients: `wp transient delete --expired`.
+
+## Transients
+
+Cache expensive computed data with an expiry; transients use the object cache when one exists, otherwise the DB.
+
+```php
+$data = get_transient( 'acme_report' );
+if ( false === $data ) {
+	$data = build_expensive_report();          // the slow part
+	set_transient( 'acme_report', $data, HOUR_IN_SECONDS );
+}
+```
+
+## Asset discipline
+
+- Per-block CSS via `wp_enqueue_block_style()` — loads only when the block renders.
+- Defer non-critical scripts: pass `array( 'strategy' => 'defer' )` (or `'async'`) as the `$args` to `wp_enqueue_script()` (WP 6.3+).
+- Concatenate/minify at build time; never ship the dev bundle.
+- No inline `<script>`/`<link>` in templates — uncacheable, no dependency graph.
+
+## Speculative loading
+
+WP 6.8 shipped speculative loading (prerender/prefetch on link hover or viewport) and 6.9 refined it. Tune the eagerness/mode rather than installing a separate prefetch plugin; over-eager prerendering wastes bandwidth and can fire analytics prematurely.
+
+## Core Web Vitals, WP-flavored
+
+- **LCP:** the hero is usually a featured image — size it, serve modern formats, and do not lazy-load the above-the-fold image (`fetchpriority="high"`).
+- **CLS:** declare image/embed dimensions; reserve space for ad/menu slots.
+- **INP:** trim heavy front-end JS from page builders and excess plugins; defer what is not interactive at load.
+- Measure with field data, not just lab — a logged-out, cold-cache mobile run is the honest number.

package/skills/wordpress/references/woocommerce.md

@@ -0,0 +1,65 @@
+# WooCommerce
+
+The store layer behind the SKILL.md WooCommerce section. WordPress owns the back end; a Shopify store is a different platform (the `shopify` sibling).
+
+## HPOS (High-Performance Order Storage)
+
+Since WooCommerce 8.2, **HPOS is the default order datastore for new installs**. Orders, order items, and metadata move out of `wp_posts`/`wp_postmeta` into dedicated `wc_orders*` tables — fewer joins, faster queries, no autoload bloat.
+
+Three states matter:
+1. **Legacy posts storage** — orders in `wp_posts` (old sites).
+2. **Compatibility mode** — writes to both stores, keeps them in sync (safe interim during migration).
+3. **HPOS authoritative** — custom tables are the source of truth.
+
+## Enable / migrate / verify (WP-CLI)
+
+```bash
+# Inspect current state
+wp wc cot status
+
+# Turn on custom order tables
+wp wc hpos enable
+
+# Backfill existing orders into the new tables (idempotent; re-runnable)
+wp wc cot sync
+
+# Verify parity before making HPOS authoritative
+wp wc cot verify_cot_data
+
+# Only after a clean verify: flip authority and (optionally) stop syncing legacy
+```
+
+Always `wp db export` before migrating a production store. Run `sync` and `verify_cot_data` again after the final plugin updates to catch drift.
+
+## Plugin compatibility declaration
+
+A plugin that reads or writes orders **must** declare HPOS compatibility or WooCommerce will disable it when HPOS is authoritative:
+
+```php
+add_action( 'before_woocommerce_init', function () {
+	if ( class_exists( \Automattic\WooCommerce\Utilities\FeaturesUtil::class ) ) {
+		\Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility(
+			'custom_order_tables', __FILE__, true
+		);
+	}
+} );
+```
+
+Then stop using `WP_Query`/`get_post_meta` for orders. Use the CRUD API — `wc_get_orders()`, `wc_get_order( $id )`, `$order->get_meta()` / `$order->update_meta_data()` / `$order->save()` — which works against whichever datastore is active.
+
+## Store setup checklist
+
+- General: store address, currency, selling/shipping locations.
+- Products: product types (simple/variable/grouped), tax classes, stock management.
+- Payments: a gateway with a tested webhook path; never store raw card data.
+- Checkout: use the **block-based Cart/Checkout blocks** (the modern default) over the classic shortcodes for new stores.
+- Tax & shipping zones configured before launch; test a real end-to-end order in staging.
+- Emails: verify transactional order emails actually deliver (sender domain, SPF/DKIM).
+
+## Store-specific CLI
+
+```bash
+wp wc product list --user=admin
+wp wc shop_order list --user=admin     # legacy alias still works in compat mode
+wp wc tool run regenerate_product_lookup_tables --user=admin
+```