vybekiit 0.6.1 → 0.7.0

package/dist/global-skills/email-best-practices/tests/scenarios/01-spam-deliverability.md

@@ -0,0 +1,46 @@
+# Scenario 1: Emails Going to Spam
+
+## Prompt
+
+```
+You are an AI coding assistant. A developer asks you:
+
+"My transactional emails (password resets, order confirmations) are going to spam in Gmail. What do I do to fix this?"
+
+Answer with specific, actionable steps. Include exact DNS records, commands to verify, and threshold numbers where relevant.
+
+Format your response as a numbered action plan.
+```
+
+## Expected Correctness Criteria
+
+The agent MUST include these skill-specific details:
+
+### Authentication (deliverability.md)
+- [ ] SPF record example: `v=spf1 include:amazonses.com ~all`
+- [ ] DKIM: provider supplies the record
+- [ ] DMARC: `v=DMARC1; p=none; rua=mailto:dmarc@example.com`
+- [ ] DMARC rollout: `p=none` → `p=quarantine; pct=25` → `p=reject`
+- [ ] Verification commands: `dig TXT example.com +short`, `dig TXT resend._domainkey.example.com +short`, `dig TXT _dmarc.example.com +short`
+
+### Thresholds (deliverability.md)
+- [ ] Bounce targets: <1% good, 1-3% acceptable, 3-4% concerning, >4% critical
+- [ ] Complaint targets: <0.01% excellent, 0.01-0.05% good, >0.05% critical
+
+### IP Warming (deliverability.md)
+- [ ] Week 1: 50-100/day
+- [ ] Week 2: 200-500/day
+- [ ] Week 3: 1,000-2,000/day
+- [ ] Week 4: 5,000-10,000/day
+
+### Infrastructure (deliverability.md)
+- [ ] Dedicated subdomains: `t.example.com` (transactional), `m.example.com` (marketing)
+- [ ] DNS TTL: 300s during setup, 3600s+ after stable
+
+### Troubleshooting order (deliverability.md)
+- [ ] Check in order: 1. Authentication, 2. List-Unsubscribe header, 3. Reputation, 4. Content, 5. Sending patterns
+
+### Diagnostic tools (deliverability.md)
+- [ ] Google Postmaster Tools
+- [ ] mail-tester.com
+- [ ] MXToolbox blacklist check

package/dist/global-skills/email-best-practices/tests/scenarios/02-multi-region-compliance.md

@@ -0,0 +1,48 @@
+# Scenario 2: Multi-Region Email Compliance
+
+## Prompt
+
+```
+You are an AI coding assistant. A developer asks you:
+
+"I'm building an email newsletter for my SaaS product. I have users in the US, EU, and Canada. What legal requirements do I need to follow? Give me a comparison table of requirements by region and the specific implementation steps."
+
+Be specific about penalty amounts, timing requirements for unsubscribe processing, and consent record requirements.
+```
+
+## Expected Correctness Criteria
+
+### Penalties (compliance.md)
+- [ ] CAN-SPAM: $53k/email
+- [ ] GDPR: EUR 20M or 4% revenue
+- [ ] CASL: $1M (individual) to $10M (organization) CAD
+
+### Consent types (compliance.md)
+- [ ] CAN-SPAM: opt-out model (can send without opt-in)
+- [ ] GDPR: explicit opt-in (no pre-checked boxes)
+- [ ] CASL express: explicit opt-in
+- [ ] CASL implied: existing relationship (2 years) or inquiry (6 months)
+
+### Unsubscribe timing (compliance.md)
+- [ ] CAN-SPAM: 10 business days, must work 30 days after send
+- [ ] GDPR: immediately, as easy as opting in
+- [ ] CASL: 10 business days, must work 60 days after send
+
+### CASL specifics (compliance.md)
+- [ ] Sender identification valid 60 days after send
+- [ ] Keep consent records 3 years after expiration
+
+### Consent records (compliance.md)
+- [ ] Record: email, date/time, method, what consented to, source
+
+### International sending (compliance.md)
+- [ ] Best practice: follow GDPR (most restrictive) for all regions
+
+### Managing preferences vs unsubscribe (compliance.md)
+- [ ] One-click unsubscribe required; preference management is nice-to-have, doesn't replace unsubscribe
+
+### List-Unsubscribe header (compliance.md)
+- [ ] Required by Gmail/Yahoo since Feb 2024
+- [ ] Headers: `List-Unsubscribe` URL + `List-Unsubscribe-Post: List-Unsubscribe=One-Click`
+- [ ] Endpoint: POST returns 200/202, GET shows unsubscribe page
+- [ ] Stop sending within 48 hours

package/dist/global-skills/email-best-practices/tests/scenarios/03-retry-idempotency.md

@@ -0,0 +1,36 @@
+# Scenario 3: Retry Logic + Idempotency
+
+## Prompt
+
+```
+You are an AI coding assistant. A developer asks you:
+
+"I'm using the Resend API to send transactional emails. I need to implement retry logic with idempotency to prevent duplicate sends. Show me a TypeScript implementation with idempotency keys, exponential backoff, and proper error code handling."
+
+Include specific HTTP error codes and which ones to retry vs not retry, idempotency key generation strategies, and backoff timing.
+```
+
+## Expected Correctness Criteria
+
+### Idempotency keys (sending-reliability.md)
+- [ ] Event-based key example: `order-confirm-${orderId}` (recommended)
+- [ ] Request-scoped example: `reset-${userId}-${resetRequestId}`
+- [ ] UUID fallback: `crypto.randomUUID()` — generate once, reuse on retry
+- [ ] Warns against `Date.now()` or random values generated fresh on each attempt
+- [ ] Key expiration: 24 hours — complete retry logic within this window
+
+### Error codes (sending-reliability.md)
+- [ ] Retry: 5xx (server error), 429 (rate limit), network timeout, DNS failure
+- [ ] Do NOT retry: 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 422 (validation)
+
+### Backoff (sending-reliability.md)
+- [ ] Exponential: 1s -> 2s -> 4s -> 8s
+- [ ] Cap at 30 seconds
+- [ ] Jitter to prevent thundering herd
+- [ ] Max retries: 3
+
+### Timeout (sending-reliability.md)
+- [ ] AbortController pattern with 10-30 second timeout
+
+### Queuing (sending-reliability.md)
+- [ ] Queue pattern for critical emails: write pending -> attempt send -> mark sent/schedule retry -> mark failed + alert

package/dist/global-skills/email-best-practices/tests/scenarios/04-webhook-bounce-handling.md

@@ -0,0 +1,52 @@
+# Scenario 4: Webhook Bounce/Complaint Handling
+
+## Prompt
+
+```
+You are an AI coding assistant. A developer asks you:
+
+"I need to set up Resend webhooks to handle bounces and complaints. Show me how to implement this with signature verification using svix, idempotent event processing, and proper bounce/complaint handling (when to suppress, when to retry). Include TypeScript code."
+
+Be specific about: svix verification headers, hard vs soft bounce handling thresholds, and complaint handling requirements.
+```
+
+## Expected Correctness Criteria
+
+### Webhook setup (webhooks-events.md)
+- [ ] Endpoint must return 2xx within 5 seconds
+- [ ] Return 200 immediately, process asynchronously
+
+### Svix verification (webhooks-events.md)
+- [ ] Import from 'svix'
+- [ ] Headers: `svix-id`, `svix-timestamp`, `svix-signature`
+- [ ] Verify before processing, return 400 on invalid signature
+
+### Idempotent processing (webhooks-events.md)
+- [ ] Use event ID to deduplicate
+- [ ] Check if already processed before handling
+- [ ] Mark as processed after handling
+
+### Event types (webhooks-events.md)
+- [ ] `email.sent`, `email.delivered`, `email.bounced`, `email.complained`, `email.opened`, `email.clicked`
+
+### Bounce handling (webhooks-events.md + list-management.md)
+- [ ] Hard bounce: suppress immediately, remove from all lists
+- [ ] Soft bounce: track count, suppress after 3 failures
+- [ ] Suppression entry schema includes: email, reason, created_at, source_email_id
+
+### Complaint handling (webhooks-events.md + list-management.md)
+- [ ] Immediate suppression — no exceptions
+- [ ] Remove from all lists
+- [ ] Log for analysis
+
+### Suppression unsuppress rules (list-management.md)
+- [ ] Hard bounce: cannot unsuppress (address invalid)
+- [ ] Complaint: cannot unsuppress (legal requirement)
+- [ ] Soft bounce (3x): can unsuppress after 30-90 days
+- [ ] Manual removal: only if user requests
+
+### Pre-send check (list-management.md)
+- [ ] Always check suppression before sending
+
+### Retry behavior (webhooks-events.md)
+- [ ] Non-2xx triggers retries: ~30s -> ~1min -> ~5min (continues ~24 hours)

package/dist/global-skills/email-best-practices/tests/scenarios/05-new-saas-email-plan.md

@@ -0,0 +1,51 @@
+# Scenario 5: New SaaS Email Infrastructure Plan
+
+## Prompt
+
+```
+You are an AI coding assistant. A developer asks you:
+
+"I'm building a new SaaS app and need to plan my entire email infrastructure. I need to know: (1) what types of transactional emails I should plan for, (2) how to set up DNS authentication, (3) how to warm up my sending domain, (4) how to handle bounces/complaints in production, and (5) what compliance requirements I need for international users. Give me a comprehensive implementation roadmap."
+
+Be specific about: IP warming schedules (daily volumes by week), bounce rate thresholds, complaint rate thresholds, DNS record formats, and legal requirements by region.
+```
+
+## Expected Correctness Criteria
+
+### Email planning (transactional-email-catalog.md)
+- [ ] References the transactional email catalog for SaaS planning
+- [ ] Covers at minimum: verification, password reset, OTP/2FA, security alerts, billing
+
+### DNS authentication (deliverability.md)
+- [ ] SPF, DKIM, DMARC records with examples
+- [ ] DMARC rollout strategy (none -> quarantine; pct=25 -> reject)
+- [ ] Dedicated subdomains for transactional vs marketing
+
+### Warming (deliverability.md)
+- [ ] Correct weekly schedule: 50-100 / 200-500 / 1k-2k / 5k-10k
+- [ ] Start with engaged users, send consistently
+
+### Bounce/complaint handling (deliverability.md + list-management.md + webhooks-events.md)
+- [ ] Bounce thresholds: <1% good, >4% critical
+- [ ] Complaint thresholds: <0.01% excellent, >0.05% critical
+- [ ] Hard bounce: immediate suppression
+- [ ] Soft bounce: suppress after 3 failures
+- [ ] Complaint: immediate suppression
+- [ ] Pre-send suppression check
+
+### Compliance (compliance.md)
+- [ ] Covers CAN-SPAM, GDPR, CASL
+- [ ] Correct penalty amounts
+- [ ] Correct unsubscribe timing by region
+- [ ] Recommends GDPR as global standard
+
+### Data retention (list-management.md)
+- [ ] Send attempts: 90 days
+- [ ] Bounce/complaint events: 3 years
+- [ ] Suppression list: indefinite
+- [ ] Email content: 30 days
+- [ ] Consent records: 3 years after expiry
+
+### Cross-resource synthesis
+- [ ] Agent references multiple resource files (not just one)
+- [ ] "Start Here" routing from SKILL.md is followed

package/dist/global-skills/instrument-feature-flags/references/usage.md

@@ -534,6 +534,41 @@ PostHogSDK.shared.captureFeatureView(flag: "flag-key", flagVariant: "variant-key
 PostHogSDK.shared.captureFeatureInteraction(flag: "flag-key", flagVariant: "variant-key")
 ```
 
+### Bootstrapping flags
+
+Since there is a delay between initializing PostHog and fetching feature flags, feature flags are not always available immediately. This makes them unusable if you want to do something like redirecting a user to a different page based on a feature flag.
+
+To have your feature flags available immediately, you can initialize PostHog with precomputed values until it has had a chance to fetch them. This is called bootstrapping. After the SDK fetches feature flags from PostHog, it will use those flag values instead of bootstrapped ones.
+
+Set `config.bootstrap` before calling `setup()` to seed identity and flag values before the first `/flags` response (requires iOS SDK `3.66.0`+):
+
+Swift
+
+PostHog AI
+
+```swift
+let config = PostHogConfig(projectToken: "<ph_project_token>", host: "https://us.i.posthog.com")
+config.bootstrap = PostHogBootstrapConfig(
+    distinctId: "distinct_id_of_your_user",
+    isIdentifiedId: true,
+    featureFlags: [
+        "flag-1": true,
+        "variant-flag": "control"
+    ],
+    featureFlagPayloads: nil
+)
+PostHogSDK.shared.setup(config)
+```
+
+-   **Bootstrapped identity applies to the first session.** Setting it before `setup()` means events captured synchronously during initialization (like `Application Installed`) carry your distinct ID instead of the SDK-generated UUID.
+    -   An **anonymous** bootstrap (`isIdentifiedId: false`, the default) seeds the anonymous ID only when none is persisted yet. Once an anonymous ID exists on disk, or the user has been identified, it is ignored.
+    -   An **identified** bootstrap (`isIdentifiedId: true`) is for a user you've already identified outside the SDK (for example, from a backend session token). On a fresh install it seeds the distinct ID and marks the user identified. On a returning install where an anonymous user already exists, it merges that user into the identified ID via `identify()`, which emits a `$identify` event during `setup()`. A *different*, already-identified user is left untouched. The identified ID never becomes the device ID.
+-   **Bootstrapped flags are served until the first `/flags` response, then replaced.** A complete `/flags` response takes over entirely, so bootstrapped-only keys don't persist past it. Only *enabled* flags are seeded: a `true` boolean or a non-empty variant string. A `false` or empty value is dropped, matching posthog-js. Seed payloads with the separate `featureFlagPayloads` option. Flag values and payloads must be JSON-serializable, or they're dropped. Bootstrapped flags are cleared on `reset()`.
+
+The feature-flags-loaded signal fires as soon as bootstrapped flags are applied, so startup logic can read them immediately. These SDKs don't support the `sessionID` bootstrap option.
+
+See the [bootstrapping guide](/docs/feature-flags/bootstrapping.md) for the cross-SDK overview.
+
 ## Experiments (A/B tests)
 
 Since [experiments](/docs/experiments/start-here.md) use feature flags, the code for running an experiment is very similar to the feature flags code. See [adding experiment code](/docs/experiments/adding-experiment-code.md) for iOS examples.

package/dist/global-skills/instrument-product-analytics/SKILL.md

@@ -65,7 +65,7 @@ STEP 9: Set up environment variables.
 STEP 10: Verify and clean up.
   - Check the project for errors. Look for type checking or build scripts in package.json.
   - Ensure any components created were actually used.
-  - Run any linter or prettier-like scripts found in the package.json.
+  - Run any linter or prettier-like scripts found in the package.json, but ONLY on the files you have edited or created during this session. Never run formatting or linting across the entire project's codebase.
 
 ## Reference files
 

package/dist/global-skills/instrument-product-analytics/references/android.md

@@ -566,6 +566,41 @@ PostHog.captureFeatureView("flag-key", flagVariant = "variant-key")
 PostHog.captureFeatureInteraction("flag-key", flagVariant = "variant-key")
 ```
 
+### Bootstrapping flags
+
+Since there is a delay between initializing PostHog and fetching feature flags, feature flags are not always available immediately. This makes them unusable if you want to do something like redirecting a user to a different page based on a feature flag.
+
+To have your feature flags available immediately, you can initialize PostHog with precomputed values until it has had a chance to fetch them. This is called bootstrapping. After the SDK fetches feature flags from PostHog, it will use those flag values instead of bootstrapped ones.
+
+Set `config.bootstrap` before calling `setup()` to seed identity and flag values before the first `/flags` response (requires Android SDK `3.55.0`+):
+
+Kotlin
+
+PostHog AI
+
+```kotlin
+import com.posthog.PostHogBootstrapConfig
+val config = PostHogAndroidConfig(apiKey = POSTHOG_API_KEY, host = POSTHOG_HOST)
+config.bootstrap = PostHogBootstrapConfig(
+    distinctId = "distinct_id_of_your_user",
+    isIdentifiedId = true,
+    featureFlags = mapOf(
+        "flag-1" to true,
+        "variant-flag" to "control"
+    )
+)
+PostHogAndroid.setup(this, config)
+```
+
+-   **Bootstrapped identity applies to the first session.** Setting it before `setup()` means events captured synchronously during initialization (like `Application Installed`) carry your distinct ID instead of the SDK-generated UUID.
+    -   An **anonymous** bootstrap (`isIdentifiedId: false`, the default) seeds the anonymous ID only when none is persisted yet. Once an anonymous ID exists on disk, or the user has been identified, it is ignored.
+    -   An **identified** bootstrap (`isIdentifiedId: true`) is for a user you've already identified outside the SDK (for example, from a backend session token). On a fresh install it seeds the distinct ID and marks the user identified. On a returning install where an anonymous user already exists, it merges that user into the identified ID via `identify()`, which emits a `$identify` event during `setup()`. A *different*, already-identified user is left untouched. The identified ID never becomes the device ID.
+-   **Bootstrapped flags are served until the first `/flags` response, then replaced.** A complete `/flags` response takes over entirely, so bootstrapped-only keys don't persist past it. Only *enabled* flags are seeded: a `true` boolean or a non-empty variant string. A `false` or empty value is dropped, matching posthog-js. Seed payloads with the separate `featureFlagPayloads` option. Flag values and payloads must be JSON-serializable, or they're dropped. Bootstrapped flags are cleared on `reset()`.
+
+The feature-flags-loaded signal fires as soon as bootstrapped flags are applied, so startup logic can read them immediately. These SDKs don't support the `sessionID` bootstrap option.
+
+See the [bootstrapping guide](/docs/feature-flags/bootstrapping.md) for the cross-SDK overview.
+
 ## Experiments (A/B tests)
 
 Since [experiments](/docs/experiments/start-here.md) use feature flags, the code for running an experiment is very similar to the feature flags code:
@@ -750,6 +785,7 @@ val config = PostHogAndroidConfig(
 | errorTrackingConfig | PostHogErrorTrackingConfig() | Configures error tracking. autoCapture defaults to false; set it to true to autocapture uncaught exceptions when project settings also enable error tracking. |
 | surveys | false | Internal/experimental native Android survey support. Native Android survey UI is not fully supported or documented yet. |
 | surveysConfig | PostHogSurveysConfig() | Internal/experimental survey display delegate configuration, primarily for hybrid SDKs. |
+| bootstrap | null | Seeds identity (distinctId, isIdentifiedId) and feature-flag state (featureFlags, featureFlagPayloads) before the first /flags response. Bootstrapped identity applies to the first session; only enabled flags are served, until the first /flags response replaces them. See [bootstrapping](/docs/feature-flags/bootstrapping.md#behavior-on-mobile-sdks). |
 
 ### Event filtering with `beforeSend`
 

package/dist/global-skills/instrument-product-analytics/references/configuration.md

@@ -289,6 +289,7 @@ The [`PostHogConfig` object](https://github.com/PostHog/posthog-ios/blob/main/Po
 | reuseAnonymousIdType: BooleanDefault: false | Whether the SDK should reuse the anonymous Id between user changes. When enabled, a single Id will be used for all anonymous users on this device. |
 | surveysType: BooleanDefault: true | Enable Surveys. |
 | setBeforeSendType: FunctionDefault: undefined | Hook that allows for amending, sampling, or dropping events before they are sent to PostHog. |
+| bootstrapType: PostHogBootstrapConfigDefault: nil | Seeds identity (distinctId, isIdentifiedId) and feature-flag state (featureFlags, featureFlagPayloads) before the first /flags response. Bootstrapped identity applies to the first session; only enabled flags are served, until the first /flags response replaces them. See [bootstrapping](/docs/feature-flags/bootstrapping.md#behavior-on-mobile-sdks). |
 
 ### Community questions
 

package/dist/global-skills/instrument-product-analytics/references/flutter.md

@@ -605,6 +605,43 @@ PostHog AI
 await Posthog().reloadFeatureFlags();
 ```
 
+### Bootstrapping flags
+
+Since there is a delay between initializing PostHog and fetching feature flags, feature flags are not always available immediately. This makes them unusable if you want to do something like redirecting a user to a different page based on a feature flag.
+
+To have your feature flags available immediately, you can initialize PostHog with precomputed values until it has had a chance to fetch them. This is called bootstrapping. After the SDK fetches feature flags from PostHog, it will use those flag values instead of bootstrapped ones.
+
+Set `config.bootstrap` before calling `setup()` to seed identity and flag values before the first `/flags` response (requires the Flutter SDK `5.31.0`+):
+
+Dart
+
+PostHog AI
+
+```dart
+final config = PostHogConfig('<ph_project_token>');
+config.host = 'https://us.i.posthog.com';
+config.bootstrap = PostHogBootstrapConfig(
+  distinctId: 'distinct_id_of_your_user',
+  isIdentifiedId: true,
+  featureFlags: {
+    'flag-1': true,
+    'variant-flag': 'control',
+  },
+);
+await Posthog().setup(config);
+```
+
+The values are forwarded to the native iOS and Android SDKs:
+
+-   **Bootstrapped identity applies to the first session.** Setting it before `setup()` means events captured synchronously during initialization (like `Application Installed`) carry your distinct ID instead of the SDK-generated UUID.
+    -   An **anonymous** bootstrap (`isIdentifiedId: false`, the default) seeds the anonymous ID only when none is persisted yet. Once an anonymous ID exists on disk, or the user has been identified, it is ignored.
+    -   An **identified** bootstrap (`isIdentifiedId: true`) is for a user you've already identified outside the SDK (for example, from a backend session token). On a fresh install it seeds the distinct ID and marks the user identified. On a returning install where an anonymous user already exists, it merges that user into the identified ID via `identify()`, which emits a `$identify` event during `setup()`. A *different*, already-identified user is left untouched. The identified ID never becomes the device ID.
+-   **Bootstrapped flags are served until the first `/flags` response, then replaced.** A complete `/flags` response takes over entirely, so bootstrapped-only keys don't persist past it. Only *enabled* flags are seeded: a `true` boolean or a non-empty variant string. A `false` or empty value is dropped, matching posthog-js. Seed payloads with the separate `featureFlagPayloads` option. Flag values and payloads must be JSON-serializable, or they're dropped. Bootstrapped flags are cleared on `reset()`.
+
+The feature-flags-loaded signal fires as soon as bootstrapped flags are applied, so startup logic can read them immediately. These SDKs don't support the `sessionID` bootstrap option.
+
+On Flutter web, `bootstrap` is not applied, so configure it in your `posthog.init({...})` snippet instead. See the [bootstrapping guide](/docs/feature-flags/bootstrapping.md) for the cross-SDK overview.
+
 ### Setting properties for flag evaluation
 
 If a flag targets person or group properties, you can send those properties inline with the next flag evaluation request instead of waiting for a `$set` event to be ingested. This avoids the race where a flag returns a stale value right after you set a property.

package/dist/global-skills/instrument-product-analytics/references/posthog-python.md

@@ -1,6 +1,6 @@
 # PostHog Python SDK
 
-**SDK Version:** 7.22.1
+**SDK Version:** 7.25.0
 
 Integrate PostHog into any python application.
 
@@ -73,6 +73,7 @@ Initialize a new PostHog client instance.
 - **`capture_compression`** (`CaptureCompression`) - Request-body compression for capture-v1 uploads         (ignored in V0, which uses ``gzip``). ``CaptureCompression.GZIP``         or ``DEFLATE`` (or the strings ``"gzip"``/``"deflate"``). When         omitted, the ``POSTHOG_CAPTURE_COMPRESSION`` env var is consulted,         then the legacy ``gzip`` flag, then no compression.
 - **`secret_key`** (`any`) - A Personal API Key or Project Secret API Key, used to         authenticate local feature flag evaluation, remote config         payloads, and decrypted flag payloads. Example::              posthog.Client(project_api_key, secret_key="phx_...")
 - **`_dedicated_ai_endpoint`** (`bool`)
+- **`metrics?`** (`dict`)
 
 ### Returns
 
@@ -259,7 +260,7 @@ posthog.capture('$pageview', distinct_id="distinct_id_of_the_user", properties={
 
 **Release Tag:** public
 
-Capture an exception for error tracking.
+Capture an exception for error tracking.  When OpenTelemetry is installed and a valid span is active, its trace and span IDs are added as ``$trace_id`` and ``$span_id`` event properties.
 
 ### Parameters
 

package/dist/global-skills/instrument-product-analytics/references/usage.md

@@ -534,6 +534,41 @@ PostHogSDK.shared.captureFeatureView(flag: "flag-key", flagVariant: "variant-key
 PostHogSDK.shared.captureFeatureInteraction(flag: "flag-key", flagVariant: "variant-key")
 ```
 
+### Bootstrapping flags
+
+Since there is a delay between initializing PostHog and fetching feature flags, feature flags are not always available immediately. This makes them unusable if you want to do something like redirecting a user to a different page based on a feature flag.
+
+To have your feature flags available immediately, you can initialize PostHog with precomputed values until it has had a chance to fetch them. This is called bootstrapping. After the SDK fetches feature flags from PostHog, it will use those flag values instead of bootstrapped ones.
+
+Set `config.bootstrap` before calling `setup()` to seed identity and flag values before the first `/flags` response (requires iOS SDK `3.66.0`+):
+
+Swift
+
+PostHog AI
+
+```swift
+let config = PostHogConfig(projectToken: "<ph_project_token>", host: "https://us.i.posthog.com")
+config.bootstrap = PostHogBootstrapConfig(
+    distinctId: "distinct_id_of_your_user",
+    isIdentifiedId: true,
+    featureFlags: [
+        "flag-1": true,
+        "variant-flag": "control"
+    ],
+    featureFlagPayloads: nil
+)
+PostHogSDK.shared.setup(config)
+```
+
+-   **Bootstrapped identity applies to the first session.** Setting it before `setup()` means events captured synchronously during initialization (like `Application Installed`) carry your distinct ID instead of the SDK-generated UUID.
+    -   An **anonymous** bootstrap (`isIdentifiedId: false`, the default) seeds the anonymous ID only when none is persisted yet. Once an anonymous ID exists on disk, or the user has been identified, it is ignored.
+    -   An **identified** bootstrap (`isIdentifiedId: true`) is for a user you've already identified outside the SDK (for example, from a backend session token). On a fresh install it seeds the distinct ID and marks the user identified. On a returning install where an anonymous user already exists, it merges that user into the identified ID via `identify()`, which emits a `$identify` event during `setup()`. A *different*, already-identified user is left untouched. The identified ID never becomes the device ID.
+-   **Bootstrapped flags are served until the first `/flags` response, then replaced.** A complete `/flags` response takes over entirely, so bootstrapped-only keys don't persist past it. Only *enabled* flags are seeded: a `true` boolean or a non-empty variant string. A `false` or empty value is dropped, matching posthog-js. Seed payloads with the separate `featureFlagPayloads` option. Flag values and payloads must be JSON-serializable, or they're dropped. Bootstrapped flags are cleared on `reset()`.
+
+The feature-flags-loaded signal fires as soon as bootstrapped flags are applied, so startup logic can read them immediately. These SDKs don't support the `sessionID` bootstrap option.
+
+See the [bootstrapping guide](/docs/feature-flags/bootstrapping.md) for the cross-SDK overview.
+
 ## Experiments (A/B tests)
 
 Since [experiments](/docs/experiments/start-here.md) use feature flags, the code for running an experiment is very similar to the feature flags code. See [adding experiment code](/docs/experiments/adding-experiment-code.md) for iOS examples.

package/dist/global-skills/neon/SKILL.md

@@ -2,17 +2,15 @@
 name: neon
 description: >-
   Overview of the Neon platform for apps and agents, spanning Postgres, Auth,
-  Data API, and the new services: Object Storage, Compute Functions, and AI
-  Gateway. Use whenever "Neon" is mentioned for an overview of how to work with Neon and how to get started. Otherwise, the individual capabilities are the triggers: "object storage" or "S3-compatible
-  storage", "serverless functions", "background jobs", or
-  "run code near my database", "AI gateway", "LLM proxy",
-  "model routing", or "call an LLM" → AI Gateway; "database", "Postgres", or
-  "authentication" → Postgres and Auth.
+  the Data API, and the new services: Object Storage, Compute Functions, and AI
+  Gateway. Use when "Neon" is mentioned, or when any of its individual
+  capabilities are the trigger: "object storage" or "S3", "buckets", "serverless
+  functions", "AI gateway", "call an LLM", "postgres", "database", or "backend".
 ---
 
 # Neon
 
-Important: Neon is no longer just a Serverless Postgres provider. Neon is the backend for apps and agents with Serverless Postgres, Auth, Functions, Storage, and an AI Gateway: instant, branchable, serverless.
+Important: Neon is no longer just a Serverless Postgres provider. Neon is the backend for apps and agents with Serverless Postgres, Auth, Functions, Object Storage, and an AI Gateway: instant, branchable, serverless.
 
 Use this skill as the starting point for anything Neon: get an overview of its capabilities, find your way around the Neon agent skills and documentation, and follow best practices for getting started and for branch-first development workflows.
 
@@ -22,15 +20,15 @@ Neon bundles several backend primitives for building apps and agents that all br
 
 - **Postgres** — Serverless Postgres that scales and branches with your app. _Generally available._
 - **Auth** — Managed authentication with users and sessions stored in Postgres. _Generally available._
-- **Object Storage** — S3-compatible object storage that branches with your projects. _Preview / early access._
-- **Compute Functions** — Long-running serverless functions running close to your database — for WebSocket servers, long agent HTTP streams, APIs, and server-sent event servers. _Preview / early access._
-- **AI Gateway** — One API for all frontier and open-source models, with routing, logging, and cost controls, powered by Databricks. _Preview / early access._
+- **Object Storage** — S3-compatible object storage that branches with your projects. _Public beta._
+- **Functions** — Long-running serverless functions - Neon's compute offering - running close to your database — for WebSocket servers, long agent HTTP streams, APIs, and server-sent event servers. _Public beta._
+- **AI Gateway** — One API for all frontier and open-source models, with routing, logging, and cost controls, powered by Databricks. _Public beta._
 
-### Preview Service Availability
+### Public Beta Service Availability
 
-Object Storage, Compute Functions, and AI Gateway are preview (early access) features.
+Object Storage, Functions, and AI Gateway are in public beta.
 
-Early access features are only available on net-new projects created in the `us-east-2` region; they cannot be enabled on existing projects for now. Before guiding a user through any of these services, confirm they are working with a new project in `us-east-2`. If not, they will need to create a new project in that region. Then confirm the user already has early access; otherwise, point them to the private beta sign-up: https://neon.com/blog/were-building-backends#access.
+Beta access features are only available on net-new projects created in the `us-east-2` region; they cannot be enabled on existing projects for now. Before guiding a user through any of these services, confirm they are working with a new project in `us-east-2`. If not, they will need to create a new project in that region.
 
 ## Architecture: how Neon fits
 
@@ -74,7 +72,7 @@ Common doc URLs are organized in the topic links below. If you need a page not l
 - Choosing or creating the right branch type for dev, preview, test, or CI workflows → `neon-postgres-branches`.
 - Storing and serving files (uploads, images, blobs) that branch with the database → `neon-object-storage`.
 - Deploying long-running or streaming serverless functions — APIs, agents, SSE/WebSocket servers — next to the database → `neon-functions`.
-- Calling an LLM or routing across model providers with one credential → `neon-ai-gateway`.
+- Calling an LLM or routing across model providers with one credential — including discovering the branch's servable models at runtime via the OpenAI-compatible `/v1/models` endpoint → `neon-ai-gateway`.
 - Provisioning instant, claimable temporary Postgres databases (for example, one per end user or demo) → `claimable-postgres`.
 - Diagnosing or fixing excessive Postgres egress (network data-transfer) costs in a codebase → `neon-postgres-egress-optimizer`.
 
@@ -98,6 +96,8 @@ For example, to install the object storage skill globally for a specific agent w
 npx skills add neondatabase/agent-skills -s neon-object-storage -g -y -a <agent-name>
 ```
 
+You should also make sure the skills are up to date. You can run the same command or replace `add` with `update` to update all Neon skills.
+
 ## Getting Started with Neon
 
 Use this section when guiding a user through first-time Neon setup, or when adding a new Neon service (Auth, object storage, functions, and so on) to a project that is already onboarded (for example, one already using Neon Postgres).
@@ -129,7 +129,7 @@ If `init` is not suitable, the individual steps can be run non-interactively, us
 - **MCP server:** `npx -y add-mcp https://mcp.neon.tech/mcp -g -n Neon -y -a <agent-name>`
 - **Agent skill:** `npx skills add neondatabase/agent-skills --skill neon-postgres --skill neon --agent <agent-name> -y`
 
-Prefer the CLI over the MCP server unless the user instructs otherwise, since it provides more capabilities, including deploying Neon Functions. For full CLI installation options, see https://neon.com/docs/reference/cli-install.md
+Prefer the CLI over the MCP server unless the user instructs otherwise, since it provides more capabilities, including deploying Neon Functions. For full CLI installation options, see https://neon.com/docs/cli/install.md
 
 ### Setup Flow
 
@@ -178,7 +178,7 @@ If env vars are injected at runtime instead of written to disk — or you simply
 - `neon-env run -- <your dev command>` (from `@neon/env`) fetches the branch's vars from your `neon.ts` and injects them into the child process at runtime — no `.env` file needed. This is the runtime counterpart to the on-disk `env pull`.
 - `neon-env export` (from `@neon/env`) prints the branch's env to stdout as dotenv lines or, with `--format json`, JSON — for piping into another env manager rather than running a command. For example, [varlock](https://varlock.dev) can bulk-load it from a `.env.schema` with `@setValuesBulk(exec("neon-env export --format json"), format=json)`.
 - `fetchEnv` from `@neon/env` is the programmatic version of the same thing: resolve the branch's env in code at runtime instead of shelling out to `neon-env run`.
-- `neon dev` injects the same vars into your local dev server — it's part of Neon Functions local development (a private preview feature).
+- `neon dev` injects the same vars into your local dev server — it's part of Neon Functions local development (a public beta feature).
 
 When an agent should not write a local `.env`, instruct it (for example in your `AGENTS.md`) to run `neon checkout <branch> --no-env-pull` and rely on runtime injection.
 
@@ -212,9 +212,13 @@ export default defineConfig({
   auth: true,
   dataApi: true,
   preview: {
-    functions: { /* ... */ }, // see the neon-functions skill
-    buckets: { /* ... */ },    // see the neon-object-storage skill
-    aiGateway: true,           // see the neon-ai-gateway skill
+    functions: {
+      /* ... */
+    }, // see the neon-functions skill
+    buckets: {
+      /* ... */
+    }, // see the neon-object-storage skill
+    aiGateway: true, // see the neon-ai-gateway skill
   },
 });
 ```
@@ -320,7 +324,10 @@ export default defineConfig({ auth: true, dataApi: true });
 
 // 2. Or verify a third-party IdP instead of Neon Auth:
 export default defineConfig({
-  dataApi: { authProvider: "external", jwksUrl: "https://your-idp/.well-known/jwks.json" },
+  dataApi: {
+    authProvider: "external",
+    jwksUrl: "https://your-idp/.well-known/jwks.json",
+  },
 });
 ```