Bring posthog-node guidance and the Node example onto v5

context/skills/posthog-best-practices/description.md

@@ -26,6 +26,7 @@ If the project uses a specific PostHog product mentioned below, consult the rele
 - If the project uses consent or privacy controls:
   - Implement an explicit opt-in / opt-out path and honor it consistently.
   - If this applies, consult `references/data-collection.md`.
+- Whenever you name the `phc_` ingestion credential — env vars, config keys, prose — call it the project token (e.g. `POSTHOG_PROJECT_TOKEN`), not a "key". Keep this naming consistent across client and server.
 - If the project uses frontend PostHog initialization:
   - Treat `phc_` project tokens as public.
   - Never expose `phx_` personal API keys.
@@ -108,6 +109,8 @@ If the project uses React Native or Expo:
 
 If the project uses Node.js (`posthog-node`):
 
+- `posthog-node` v5+ requires Node 20+ (it uses native `fetch`). On older runtimes v5 fails at runtime; either upgrade Node or pin the SDK to v4.
+- `capture()` takes an object — `capture({ distinctId, event, properties })` — and this signature is identical in v4 and v5. A capture that produces no event is a runtime, flush, or Node-version problem, never a reason to downgrade the SDK.
 - For long-running servers, enable exception autocapture and install the framework's error handler integration.
 - For short-lived processes, call `await posthog.shutdown()` before exit. If needed, use `await posthog.shutdown(shutdownTimeoutMs?)`.
 - Use `posthog.flush()` only for per-request cleanup.

example-apps/javascript-node/package.json

@@ -10,6 +10,6 @@
   "dependencies": {
     "dotenv": "^16.0.0",
     "express": "^4.21.0",
-    "posthog-node": "^4.0.0"
+    "posthog-node": "^5.0.0"
   }
 }