[gewenyu99]

Problem

The Laravel example and the Laravel rules tell agents to set the project token as POSTHOG_API_KEY. That's the name posthog-laravel reads today, but PostHog calls it the project token everywhere else, and the wizard writes POSTHOG_PROJECT_TOKEN for Laravel. A wizard run following these rules puts the token in a variable the SDK doesn't read.

Changes

• Rule: the Laravel commandment says POSTHOG_PROJECT_TOKEN. POSTHOG_API_KEY stays readable for apps that already set it, and agents don't write it for new installs.
• PHP rule: the php commandment said to initialize with PostHog::init(). Laravel skills also carry the php tag, so it contradicted the Laravel rule not to. It now skips init() when the app uses posthog/posthog-laravel.
• Example: .env.example, the README and config/posthog.php use POSTHOG_PROJECT_TOKEN. The config matches the one feat: read the project token from POSTHOG_PROJECT_TOKEN posthog-php#311 publishes, with api_key kept as the deprecated fallback.

Blocked on

PostHog/posthog-php#311, which makes posthog-laravel read POSTHOG_PROJECT_TOKEN. Before merging, bump posthog/posthog-laravel in example-apps/laravel/composer.json to the release that ships it.

How it was checked

npm test (320 passed). The example hasn't been booted against the new SDK because it isn't released yet.

Stacked on #497.

🤖 Generated with Claude Code