chore: fallback language skills v2

transformation-config/commandments.yaml

@@ -65,7 +65,7 @@ commandments:
     - posthog is the Python SDK package name
     - Install dependencies with `pip install posthog` or `pip install -r requirements.txt` and do NOT use unquoted version specifiers like `>=` directly in shell commands
     - In CLIs and scripts: MUST call posthog.shutdown() before exit or all events are lost
-    - Always use the Posthog() class constructor (instance-based API) instead of module-level posthog.api_key config
+    - Prefer the Posthog() class constructor (instance-based API) for better control over initialization and shutdown, but adapt to the project's existing patterns if it already uses module-level config
     - Always include enable_exception_autocapture=True in the Posthog() constructor to automatically track exceptions
     - NEVER send PII in capture() event properties — no emails, full names, phone numbers, physical addresses, IP addresses, or user-generated content
     - PII belongs in identify() person properties, NOT in capture() event properties. Safe event properties are metadata like message_length, form_type, boolean flags.

transformation-config/skills/integration/config.yaml

@@ -159,39 +159,47 @@ variants:
 
   # Language fallback skills, used when no specific framework is detected
   - id: python
-    example_paths: basics/python
+    template: fallback-description.md
+    # Docs-only, no example app
     display_name: Python
     description: PostHog integration for any Python application using the Python SDK
     tags: [python]
     docs_urls:
       - https://posthog.com/docs/libraries/python.md
       - https://posthog.com/docs/references/posthog-python.md
+      - https://posthog.com/docs/error-tracking/installation/python.md
 
   - id: javascript_node
-    example_path: basics/javascript-node
+    template: fallback-description.md
+    # Docs-only, no example app
     display_name: JavaScript Node
     description: PostHog integration for server-side Node.js applications using posthog-node
     tags: [javascript_node]
     docs_urls:
       - https://posthog.com/docs/libraries/node.md
       - https://posthog.com/docs/references/posthog-node.md
-
+      - https://posthog.com/docs/error-tracking/installation/node.md
+
   - id: javascript_web
-    example_path: basics/javascript-web
+    template: fallback-description.md
+    # Docs-only, no example app
     display_name: JavaScript Web
     description: PostHog integration for client-side web JavaScript applications using posthog-js
     tags: [javascript_web]
     docs_urls:
       - https://posthog.com/docs/libraries/js.md
       - https://posthog.com/docs/references/posthog-js.md
+      - https://posthog.com/docs/error-tracking/installation/web.md
 
   - id: ruby
-    example_paths: basics/ruby
+    template: fallback-description.md
+    # Docs-only, no example app
     display_name: Ruby
     description: PostHog integration for any Ruby application using the Ruby SDK
     tags: [ruby]
     docs_urls:
       - https://posthog.com/docs/libraries/ruby.md
+      - https://posthog.com/docs/error-tracking/installation/ruby.md
 
   - id: swift
     example_paths: basics/swift

transformation-config/skills/integration/fallback-description.md

@@ -0,0 +1,34 @@
+# PostHog integration for {display_name}
+
+This skill helps you add PostHog analytics to {display_name} applications.
+
+## Workflow
+
+Follow these steps in order to complete the integration:
+
+{workflow}
+
+## Reference files
+
+{references}
+
+The example project demonstrates SDK usage patterns (initialization, event capture, user identification, error tracking). Use it to understand the PostHog API, but adapt your implementation to match the actual project's architecture and conventions.
+
+## Key principles
+
+- **Environment variables**: Always use environment variables for PostHog keys. Never hardcode real API keys. If the project has no build step or runtime that supports environment variables (e.g. vanilla HTML), use placeholder values like `'YOUR_POSTHOG_API_KEY'` and instruct the user to replace them in the setup report.
+- **Minimal changes**: Add PostHog code alongside existing integrations. Don't replace or restructure existing code.
+- **Adapt to the project**: Follow the SDK documentation for how to integrate, but find the right place in the project's architecture to put it. Every project is structured differently — look for the natural entry point.
+- **Explore first**: Read the project's key files before writing any code. Understand what the project does, where requests are handled, where users authenticate, and where errors are caught.
+
+## SDK guardrails
+
+{commandments}
+
+## Identifying users
+
+Always add `identify()` on login and signup flows. Refer to the SDK and identify documentation for the correct pattern. Never use raw emails or IP addresses as the distinct ID.
+
+## Error tracking
+
+Always add exception capture around critical user flows. Refer to the error tracking installation documentation for the correct pattern for this language.