vybekiit 0.7.0 → 0.7.2

package/dist/global-skills/back-up-my-code/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: back-up-my-code
-description: the builder's project is saved on GitHub so they never lose work. Use when the builder says something like: save my code; back up; put it on github.
+description: "the builder's project is saved on GitHub so they never lose work. Use when the builder says something like: save my code; back up; put it on github."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/buy-domain/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: buy-domain
-description: the app uses the builder's own web address instead of a temporary one. Use when the builder says something like: get a domain; buy a web address; my own url.
+description: "the app uses the builder's own web address instead of a temporary one. Use when the builder says something like: get a domain; buy a web address; my own url."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/check-safety/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: check-safety
-description: confirm the app is protected end-to-end before ship — abuse, database safety, and every. Use when the builder says something like: am i ready to ship; is my app safe; did we cover security.
+description: "confirm the app is protected end-to-end before ship — abuse, database safety, and every. Use when the builder says something like: am i ready to ship; is my app safe; did we cover security."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/configure-capabilities/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: configure-capabilities
-description: the app has **only the permissions it needs** — the builder never thinks about Info.plist, Android manifest, or Expo plugins. Use when the builder says something like: camera; location permission; notifications permission.
+description: "the app has **only the permissions it needs** — the builder never thinks about Info.plist, Android manifest, or Expo plugins. Use when the builder says something like: camera; location permission; notifications permission."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/connect-account/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: connect-account
-description: people can create accounts and sign in **inside the app**. Use when the builder says something like: sign in; log in; create accounts; add users; forgot password; reset password.
+description: "people can create accounts and sign in **inside the app**. Use when the builder says something like: sign in; log in; create accounts; add users; forgot password; reset password."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/connect-account-backend/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: connect-account-backend
-description: people can sign in from the phone app or extension. Use when the builder says something like: connect account backend.
+description: "people can sign in from the phone app or extension. Use when the builder says something like: connect account backend."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/design-my-data/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-my-data
-description: figure out what the app should remember before wiring storage. Use when the builder says something like: design my database; what data do i need; what should my app remember.
+description: "figure out what the app should remember before wiring storage. Use when the builder says something like: design my database; what data do i need; what should my app remember."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: doctor
-description: find out why something isn't working and fix it — without making the builder debug. Use when the builder says something like: it's broken; nothing works; get an error; check my app.
+description: "find out why something isn't working and fix it — without making the builder debug. Use when the builder says something like: it's broken; nothing works; get an error; check my app."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

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

@@ -0,0 +1,63 @@
+---
+name: feedback
+description: "send a private note about VybeKiit so the team can improve the kit. Use when the builder says something like: send feedback; report a kit bug; suggest a kit improvement; the kit is confusing."
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: feedback
+
+**Goal:** send a private note about VybeKiit so the team can improve the kit.
+
+**Contract:** one action at a time · verify-before-advance · plain language · translate errors · celebrate.
+
+## Safety boundary
+
+Include only:
+
+- kind: `bug`, `idea`, or `confusing`
+- the builder's short message
+- a short agent-written summary
+- up to 10 short steps that reproduce the problem
+- template: `web`, `mobile`, `extension`, `backend`, `spa`, or `unknown`
+- trigger: `explicit` or `automatic-suggestion`
+- agent name/version, kit version, and operating system name
+
+Exclude source code, command output, transcripts, stack traces, email, secrets, tokens, absolute paths,
+machine names, and private issue links. Never send automatically.
+
+## Steps
+
+1. **Prepare one safe draft.** Write the allowlisted JSON fields to
+   `.vybekiit/feedback-drafts/<timestamp>.json`. Create the folder if needed.
+   **Verify:** read the draft back and check that every field is allowed and bounded.
+
+2. **Show the preview.** Explain in plain language exactly what will be sent. Do not show removed
+   private details.
+   **Verify:** the builder can read the full safe preview.
+
+3. **Ask once.** Ask: *"Send this private feedback report to the VybeKiit team now?"*
+   If the builder does not clearly agree, stop and keep the local draft.
+   **Verify:** a clear yes was received in this conversation.
+
+4. **Send after approval.** Run:
+   `vybekiit feedback submit .vybekiit/feedback-drafts/<timestamp>.json --confirm`
+   GitHub may open once to confirm which paid buyer is reporting.
+   **Verify:** the command returns `{"ok":true,"reference":"FB-..."}`.
+
+5. **Record progress.** Add the safe reference to the Decision log and mark feedback sent in the
+   Progress section. Do not record the private issue URL or report body.
+   **Verify:** `checklist.md` contains only the safe reference.
+
+## If sending fails
+
+Say: *"Your note was not sent, but the safe draft is still saved. I can try again when you are
+ready."* Keep the draft. Do not fall back to `gh issue create`, `curl`, email, or another network
+service.
+
+## Definition of done
+
+The builder approved the exact safe preview, the command returned a feedback reference, and
+`checklist.md` records only that reference.

package/dist/global-skills/go-live/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: go-live
-description: the builder's app is online at a real web address that anyone can open. Use when the builder says something like: put it online; publish; make it live; ship it; deploy.
+description: "the builder's app is online at a real web address that anyone can open. Use when the builder says something like: put it online; publish; make it live; ship it; deploy."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: harden
-description: the builder's app is protected against the common attacks every app faces — someone. Use when the builder says something like: lock down; make it safe; protect from abuse.
+description: "the builder's app is protected against the common attacks every app faces — someone. Use when the builder says something like: lock down; make it safe; protect from abuse."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

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

@@ -534,41 +534,6 @@ 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, but ONLY on the files you have edited or created during this session. Never run formatting or linting across the entire project's codebase.
+  - Run any linter or prettier-like scripts found in the package.json.
 
 ## Reference files
 

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

@@ -566,41 +566,6 @@ 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:
@@ -785,7 +750,6 @@ 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,7 +289,6 @@ 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,43 +605,6 @@ 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.25.0
+**SDK Version:** 7.22.1
 
 Integrate PostHog into any python application.
 
@@ -73,7 +73,6 @@ 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
 
@@ -260,7 +259,7 @@ posthog.capture('$pageview', distinct_id="distinct_id_of_the_user", properties={
 
 **Release Tag:** public
 
-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.
+Capture an exception for error tracking.
 
 ### Parameters
 

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

@@ -534,41 +534,6 @@ 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/manifest.json

@@ -57,6 +57,7 @@
     "expo-ui",
     "expo-upgrade",
     "expo-web-to-native",
+    "feedback",
     "firebase-ai-logic-basics",
     "firebase-app-hosting-basics",
     "firebase-auth-basics",
@@ -121,5 +122,5 @@
     "wrangler",
     "xcode-project-setup"
   ],
-  "count": 120
+  "count": 121
 }

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

@@ -2,15 +2,17 @@
 name: neon
 description: >-
   Overview of the Neon platform for apps and agents, spanning Postgres, 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".
+  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.
 ---
 
 # Neon
 
-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.
+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.
 
 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.
 
@@ -20,15 +22,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. _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._
+- **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._
 
-### Public Beta Service Availability
+### Preview Service Availability
 
-Object Storage, Functions, and AI Gateway are in public beta.
+Object Storage, Compute Functions, and AI Gateway are preview (early access) features.
 
-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.
+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.
 
 ## Architecture: how Neon fits
 
@@ -72,7 +74,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 — including discovering the branch's servable models at runtime via the OpenAI-compatible `/v1/models` endpoint → `neon-ai-gateway`.
+- Calling an LLM or routing across model providers with one credential → `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`.
 
@@ -96,8 +98,6 @@ 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/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/reference/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 public beta feature).
+- `neon dev` injects the same vars into your local dev server — it's part of Neon Functions local development (a private preview 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,13 +212,9 @@ 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
   },
 });
 ```
@@ -324,10 +320,7 @@ 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" },
 });
 ```
 

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

@@ -16,7 +16,7 @@ description: >-
 
 # Neon AI Gateway
 
-This is a public beta feature and only available in `us-east-2`. The Neon AI Gateway is the LLM inference layer built into your Neon branch: one API and one Neon credential give you access to frontier and open-source models from Anthropic, OpenAI, Google, Meta, Alibaba, DeepSeek, and Databricks — powered by Databricks. Your existing OpenAI/Anthropic/Gemini SDK works by changing only the base URL.
+This is a preview feature and only available in `us-east-2`. The Neon AI Gateway is the LLM inference layer built into your Neon branch: one API and one Neon credential give you access to frontier and open-source models from Anthropic, OpenAI, Google, Meta, Alibaba, DeepSeek, and Databricks — powered by Databricks. Your existing OpenAI/Anthropic/Gemini SDK works by changing only the base URL.
 
 Use this skill to help the user send model calls through the gateway, wire it into the AI SDK or Mastra, and switch providers without rewiring code. Deliver a working inference request, a configured agent, or a precise answer from the official Neon docs.
 
@@ -215,75 +215,9 @@ Use a model's catalog ID directly in the `model` field — e.g. `claude-sonnet-4
 - **models.dev Neon provider page: https://models.dev/providers/neon** — the canonical, always-current list of the Neon provider's model IDs and their underlying models. The machine-readable catalog is at https://models.dev/api.json (the `neon` key).
 - **Models doc:** see Further reading.
 
-## List available models at runtime (`/v1/models`)
-
-The gateway also exposes the model catalog **live from your own branch endpoint**, so an app or agent can discover exactly which models this branch serves without hard-coding the list. It is an OpenAI-compatible list endpoint, served **only on the unified dialect** (`/v1`):
-
-```bash
-curl "$NEON_AI_GATEWAY_BASE_URL/v1/models" \
-  -H "Authorization: Bearer $NEON_AI_GATEWAY_TOKEN"
-```
-
-- `GET ${NEON_AI_GATEWAY_BASE_URL}/v1/models` → **200**
-- `GET ${NEON_AI_GATEWAY_BASE_URL}/openai/v1/models` → **404** (not served on the Responses dialect — use `/v1`)
-
-**Getting the credentials for the request.** Both values come from the same branch-scoped Neon credential the gateway uses everywhere else — you never manage a provider key:
-
-- **Provision via `neon.ts` (recommended).** Enable `preview.aiGateway` in `neon.ts` and run `neon deploy` (or `neon config apply`). Provisioning, `neon link`, and `neon checkout` pull `NEON_AI_GATEWAY_TOKEN` + `NEON_AI_GATEWAY_BASE_URL` into your local `.env.local`; inside a deployed Neon Function they're injected automatically. See **Setup** and **Environment variables** above.
-- **Pull into the environment via CLI.** On a branch that already has the gateway enabled, `neon env pull` writes the two vars to `.env`/`.env.local`, or `neon-env run -- <cmd>` injects them at runtime without a file.
-- **Provision via the Console UI.** Enable the AI Gateway on the branch in the Neon Console and copy the branch's gateway base URL and a Neon credential (token) from the project's connection/credentials view.
-
-Any Neon credential (`nt_live_...`) valid for the branch works as the bearer token; `NEON_AI_GATEWAY_BASE_URL` is the bare branch host (no path).
-
-**Response shape** — OpenAI/OpenRouter-compatible list:
-
-```jsonc
-{
-  "object": "list",
-  "data": [
-    {
-      "id": "claude-sonnet-4-6",              // catalog model ID — use directly in the `model` field
-      "canonical_slug": "claude-sonnet-4-6",
-      "name": "Claude Sonnet 4.6",            // human-readable display name
-      "object": "model",
-      "owned_by": "anthropic",                // anthropic | openai | google | meta | alibaba | databricks
-      "created": 0,
-      "enabled": true,
-      "context_length": null,
-      "architecture": {
-        "modality": "text->text",
-        "input_modalities": ["text"],
-        "output_modalities": ["text"],
-        "tokenizer": "Claude",                // Claude | Gemini | GPT | "" (empty for open-source)
-        "instruct_type": null
-      },
-      "top_provider": {
-        "is_moderated": false,
-        "context_length": null,
-        "max_completion_tokens": null
-      },
-      "pricing": null,
-      "per_request_limits": null
-    }
-    // ... one entry per model in the branch's catalog
-  ]
-}
-```
-
-> Note: `context_length`, `pricing`, and `per_request_limits` are currently `null` and `created` is `0` for every entry — for context windows, pricing, and capabilities use the models.dev catalog above. Use `/v1/models` when you need the live, branch-scoped list of servable model IDs (e.g. to populate a model picker or validate a `model` before a request).
-
 ## Availability
 
-The AI Gateway is a public beta feature available only on new projects in the `us-east-2` region; it can't be enabled on existing projects. Foundation model access requires a paid Neon plan. Confirm the user's project is a new project in `us-east-2`.
-
-### Enabling the gateway: plan and model-catalog gating
-
-The AI Gateway is credential-gated rather than a provisioning step, but two plan/beta limits gate it — one blocks provisioning, the other only trims the catalog — and the CLI surfaces each:
-
-- **Free plan → provisioning is blocked.** `neon config apply` / `deploy` and `neon checkout` **refuse** to enable the gateway on a Free plan (the gateway can't serve requests there), with a friendly "upgrade to a paid plan, or remove `preview.aiGateway`" error. A dry-run `neon config plan` and `neon env pull` don't provision, so they only **warn**. So: to use the gateway the project's account must be on a paid Neon plan.
-- **Paid plan with a reduced model catalog.** On a paid plan the gateway provisions and serves, but during the beta an account can start with a trimmed catalog — some flagship models (e.g. Anthropic Opus, OpenAI Codex / `*-pro`) are missing from `GET /v1/models`. This is expected; `neon env pull` (and the env pull bundled into `apply` / `deploy` / `checkout`) warns and links the user to their branch's AI Gateway page in the Neon Console (`https://console.neon.tech/app/projects/<project-id>/branches/<branch-id>/ai-gateway`) to request access to more models. Verify what's actually available for the branch by reading `/v1/models` (see the models section above) rather than assuming the full catalog.
-
-When helping a user debug "the gateway isn't working" or "a model is missing", use `/v1/models` plus the account's plan to distinguish these two cases — a Free plan blocks provisioning entirely, while a reduced catalog on a paid plan just needs a model-access request.
+The AI Gateway is a preview (early access) feature available only on new projects in the `us-east-2` region; it can't be enabled on existing projects. Foundation model access requires a paid Neon plan. Confirm the user's project is a new project in `us-east-2`. If the user does not yet have access, point them to the private beta sign-up: https://neon.com/blog/were-building-backends#access
 
 ## Neon Documentation