Add WordPress framework support

[Ref34t]

Ready for review — PostHog/context-mill#279 (the skill-side half) merged on 2026-07-27, so the cross-repo contract this PR pins now holds. Rebased on main; all 1553 tests pass.

Problem

The wizard has no way to recognize a WordPress project. npx @posthog/wizard in a WordPress directory detects nothing — and when a theme build has left a package.json behind, detection falls through to the generic Node integration and gives advice that doesn't apply.

WordPress is already a PostHog product surface: there are WordPress library docs, and WooCommerce is a supported data-warehouse source. The wizard just hadn't been told.

What this adds

Followed .claude/skills/adding-framework-support/SKILL.md step by step.

• Integration.wordpress — ordered after laravel and before the language fallbacks, so a site whose theme carries a package.json still resolves to WordPress rather than javascript_node.
• src/frameworks/wordpress/ — a FrameworkConfig modelled on the Laravel one: usesPackageJson: false, composerPackageManager, version read from $wp_version in wp-includes/version.php and bucketed as 6.4.x.
• Detection covers the four shapes a real WordPress tree takes:
  1. an installed site — wp-config.php, wp-load.php, wp-settings.php, wp-includes/version.php
  2. unpacked core before install — wp-config-sample.php only
  3. a Composer-managed install where core is not in the root — roots/wordpress, johnpbloch/wordpress, wpackagist-* (Bedrock)
  4. a standalone plugin or theme directory, identified by its Plugin Name: / Theme Name: header
• Context gathering reports the project type, the plugins directory (including Bedrock's web/app/plugins), and any existing plugin entry file — so the agent extends that plugin instead of creating a second one.

Where the WordPress rules live

Not here. An earlier commit had getAdditionalContextLines carrying the integration rules — plugin over functions.php, the ABSPATH guard, esc_js() on the token, flush after capture. That was wrong: those are integration knowledge, which AGENTS.md places in context-mill, and they already exist in the wordpress block of commandments.yaml in #279. Carrying them in both places would have drifted the first time either side was edited. They've been removed, and this config now passes only what the skill cannot know — the shape of the project this run is pointed at.

Telemetry

analytics.getTags reports projectType: site, plugin, or theme. WordPress is the first CMS in the registry, and that split is the useful signal — whether people run the wizard against a whole site or inside a single plugin they're building. It surfaces alongside detected_framework with no extra wiring.

Cross-repo contract

variant-resolution.test.ts asserts every framework in the Integration enum resolves to a context-mill variant. Adding Integration.wordpress fails that test until context-mill ships an integration-wordpress variant carrying framework: wordpress — which is exactly what PostHog/context-mill#279 adds. The pinned skill-menu.json fixture here is updated to match.

That test is why this PR waited in draft: merge order was context-mill#279 first, then this. #279 is now merged, so the order is satisfied.

Tests

9 new detection tests, including the negatives that matter — a Laravel project and a plain Composer PHP project must not be claimed by WordPress — plus an ordering test asserting a WordPress site beats the Node fallback.

pnpm build   ✅
pnpm test    ✅ 1576 passing
pnpm fix     ✅ no new errors

Not included

No wizard-workbench test app yet. The handbook's worked example for wizard mcp-analytics puts test fixtures in the canonical set, so happy to add one there if you'd like this to go through the same end-to-end evaluation the other frameworks get.

[Ref34t]

Two updates since opening.

Removed four duplicated prompt lines. getAdditionalContextLines was repeating rules that already live in the wordpress block of context-mill's commandments.yaml — plugin over functions.php, the ABSPATH guard, esc_js() on the token, flush after capture. Those reach the agent with the skill, so carrying them here duplicated integration knowledge across the boundary AGENTS.md draws between the two repos, and would have drifted the moment either side was edited. The config now passes only what the skill cannot know: the project shape this run is pointed at.

Telemetry. analytics.getTags reports projectType — site, plugin, or theme. Since WordPress is the first CMS in the registry, that split is the useful signal: whether people run the wizard against a whole site or inside a single plugin they are building. It should show up alongside detected_framework without any extra wiring.

Still a draft pending PostHog/context-mill#279. pnpm build, pnpm test (1576 passing), pnpm fix all clean after both changes.

[Ref34t]

Out of draft: PostHog/context-mill#279 (the skill-side half) merged today, so the cross-repo contract this PR pins now holds on both sides. Rebased on main — all 1553 tests pass, including variant-resolution.test.ts with the integration-wordpress entry.