vybekiit 0.7.29 → 0.7.32

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

@@ -1,6 +1,6 @@
 ---
 name: onboarding
-description: "take the builder from \"I just bought this\" to **their app running and visible in front of. Use when the vibe coder says something like: set up my app; let's start; get me going; just bought."
+description: "take the builder from \"I just bought this\" to their app running and visible in front of them in this one session. Use when the vibe coder says something like: set up my app; let's start; get me going; just bought; hi; help."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---
@@ -26,16 +26,17 @@ translate every error · celebrate. Decide all technical choices yourself.
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install the end-user onboarding recipe when the vibe coder wants a first-run wizard (catalog SSOT — Option C).**
-   Copy `apps/componentLibrary/src/pageRecipes/OnboardingPage.tsx` export `OnboardingPage` into the buyer app at route `/onboarding`.
-   Recipe id: `onboarding`. Presets: none.
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Skip this step if the vibe coder only needs *their* kit setup (steps 1–5 below) and not a product wizard for their users.
-   Also reference `packages/agentKit` `getPageRecipeInstall('onboarding')` / page-recipe-manifest.json.
-   **Verify:** if installed, `/onboarding` builds with practice UI.
-
-1. **Welcome + ask the one thing that matters.**
-   Greet warmly. If the vibe coder already described their app, use that description. Otherwise ask:
+0. **Add the first-run wizard page when the vibe coder wants one for their users.** Run
+   `vybekiit add page-recipe onboarding`. It adds the page at `/onboarding`. Keep every `TODO:` in the
+   page and fill each one in. Skip this step when the vibe coder only needs their own kit setup
+   (steps 1-5 below).
+   **Verify:** if added, `/onboarding` opens and shows practice content.
+
+1. **Welcome, say what VybeKiit is, then ask the one thing that matters.**
+   Greet warmly in plain text with no emojis, then tell them in a few short sentences what they have, in plain words:
+   *"VybeKiit is a ready-made web app with the hard parts already working. It comes with sign-in, payments, a database that remembers your customers' information, emails your app sends, file uploads, visitor stats, alerts when something breaks, more languages, and putting your app online. While we build, you can turn on Report mode and point at anything on screen that looks wrong, and I fix it. You own all of it, and I do the technical work."*
+   Then stop talking about the kit and move on to their idea.
+   If the vibe coder already described their app, use that description. Otherwise ask:
    *"In one sentence, what do you want to build?"* Use their answer to tailor the starter page later.
    Keep the conversation about their idea.
 
@@ -64,7 +65,7 @@ translate every error · celebrate. Decide all technical choices yourself.
    **Verify:** the dev server is up with no errors. If it fails → run `doctor`.
 
    > (Agent-only) **Database MCP tier:** Supabase, Neon, and Firebase use login-once MCP configs
-   > (`mcp-supabase.json`, `mcp-neon.json`, `mcp-firebase.json`) — merge via `agent/mcp-setup.md`
+   > (`mcp-supabase.json`, `mcp-neon.json`, `mcp-firebase.json`) — merge via `.vybekiit/agent/mcp-setup.md`
    > (Cursor, Claude Desktop, Codex). MongoDB and AWS are advanced only.
    >
    > **Payment MCP tier:** Stripe and PayPal use `mcp-stripe.json` / `mcp-paypal.json` when
@@ -73,7 +74,7 @@ translate every error · celebrate. Decide all technical choices yourself.
 3. **Show them their app.**
    Give them the verified preview link from this run and tell them what they'll see.
    **Verify:** open the page in a browser yourself. Continue the requested work; ask the builder only if you cannot verify what they see.
-   🎉 *Celebrate* — their app is alive.
+   *Celebrate* — their app is alive.
    Mention Report mode once: *"If something looks wrong, press Option+Shift+R (Alt+Shift+R on
    Windows), click it, tell me what's off — I'll get the details automatically."*
 

package/dist/global-skills/plan-my-idea/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: plan-my-idea
-description: "help the builder figure out exactly what they want **before** you build — so the first. Use when the vibe coder says something like: help me plan; figure out my idea; think it through; marketplace; like airbnb."
+description: "help the builder figure out exactly what they want before you build — so the first version matches their idea instead of your guess. Use when the vibe coder says something like: help me plan; figure out my idea; think it through; marketplace; like airbnb."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/publish-app/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: publish-app
-description: "the builder's app is **in the App Store and Google Play** for anyone to download. This is. Use when the vibe coder says something like: put it online; publish; make it live; ship it; deploy; publish app."
+description: "the builder's app is in the App Store and Google Play for anyone to download. Use when the vibe coder says something like: put it online; publish; make it live; ship it; deploy; publish app."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

package/dist/global-skills/publish-extension/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: publish-extension
-description: "the builder's extension is **listed in the Chrome Web Store** for anyone to install. Use when the vibe coder says something like: put it online; publish; make it live; ship it; deploy; chrome store."
+description: "the builder's extension is listed in the Chrome Web Store for anyone to install. Use when the vibe coder says something like: put it online; publish; make it live; ship it; deploy; chrome store."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---

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

@@ -4,7 +4,7 @@ description: Use when working with the Resend email API — sending transactiona
 license: MIT
 metadata:
     author: resend
-    version: "3.12.0"
+    version: "3.13.0"
     homepage: https://resend.com/agent-skills
     source: https://github.com/resend/resend-skills
     openclaw:
@@ -47,6 +47,7 @@ references:
     - usage.md
     - installation.md
     - fetch-all-templates.mjs
+disable-model-invocation: true
 ---
 
 # Resend

package/dist/global-skills/resend/references/webhooks.md

@@ -65,7 +65,9 @@ The `email.received` payload contains metadata only (sender, recipient, subject,
 |-------|---------|
 | `domain.created` / `updated` / `deleted` | Domain configuration changes |
 | `contact.created` / `updated` / `deleted` | Contact list changes (not from CSV imports) |
+| `contact.topics.updated` | Contact's topic subscriptions change |
 | `suppression.added` / `removed` | Email address added to or removed from the suppression list |
+| `topic.created` / `updated` / `deleted` | Topic created, updated, or deleted |
 
 ## Setup
 

package/dist/global-skills/reset-password/SKILL.md

@@ -26,12 +26,10 @@ translate every error · celebrate.
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install the page recipe first (catalog SSOT — Option C).**
-   Copy `apps/componentLibrary/src/pageRecipes/AccountSecurityPage.tsx` export `AccountSecurityPage` into the buyer app at route `/settings/security`.
-   Recipe id: `account-security`. Preset: auth-bridge.
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Also reference `packages/agentKit` `getPageRecipeInstall('reset-password')` / page-recipe-manifest.json.
-   **Verify:** route builds with practice security UI before provider wiring.
+0. **Add the ready-made page first.** Run `vybekiit add page-recipe account-security`. It adds the page
+   at `/settings/security` and lists any data setup to run next. Keep every `TODO:` in the page and fill
+   each one in as you connect the real service.
+   **Verify:** `/settings/security` opens and shows practice content.
 
 1. **Confirm sign-in is wired.** Run `add-signin` first if accounts are not set up yet.
    **Verify:** existing sign-in works.

package/dist/global-skills/save-data/SKILL.md

@@ -51,6 +51,9 @@ For other requests, select matching presets from the catalog before authoring an
    Inspect the selected service's existing CLI or MCP login and exact project before requesting
    access. Reuse authorized connections and preserve existing projects. Never delete a project to
    free capacity. Request one manual action only when an actual access blocker remains.
+   Supabase keys: after `supabase login`, run `vybekiit-automate db setup --json --project-ref=<ref>`.
+   It saves `SUPABASE_URL` and `SUPABASE_ANON_KEY` to `settings.env`, `SUPABASE_SERVICE_ROLE_KEY` to `.env`, and prints
+   only their names.
    **Verify:** the database is reachable (`@vybekiit/db`'s `pingDatabase`).
 
 2. **Decide what to remember from the request.** Reuse existing data shapes and ownership rules.

package/dist/global-skills/sentry-sdk-setup/SKILL.md

@@ -3,6 +3,7 @@ name: sentry-sdk-setup
 description: Set up Sentry in any language or framework. Detects the user's platform and loads the right SDK skill. Use when asked to add Sentry, install an SDK, or set up error monitoring in a project.
 license: Apache-2.0
 role: router
+disable-model-invocation: true
 ---
 
 > [All Skills](../../SKILL_TREE.md)

package/dist/global-skills/sentry-workflow/SKILL.md

@@ -3,6 +3,7 @@ name: sentry-workflow
 description: Keep Sentry SDKs up to date. Use when asked to upgrade the Sentry SDK across major versions, migrate SDK versions, or fix deprecated APIs.
 license: Apache-2.0
 role: router
+disable-model-invocation: true
 ---
 
 > [All Skills](../../SKILL_TREE.md)

package/dist/global-skills/setup-email/SKILL.md

@@ -31,17 +31,16 @@ when asked.
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install the page recipe first (catalog SSOT — Option C).**
-   Copy `apps/componentLibrary/src/pageRecipes/EmailNotificationsPage.tsx` export `EmailNotificationsPage` into the buyer app at route `/dashboard/email`.
-   Recipe id: `email-notifications`. Presets: notifications_log.
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Also reference `packages/agentKit` `getPageRecipeInstall('setup-email')` / page-recipe-manifest.json.
-   **Verify:** route builds and shows practice UI before provider wiring.
-
+0. **Add the ready-made page first.** Run `vybekiit add page-recipe email-notifications`. It adds the page
+   at `/settings/notifications` and lists any data setup to run next. Keep every `TODO:` in the page and fill
+   each one in as you connect the real service.
+   **Verify:** `/settings/notifications` opens and shows practice content.
 
 1. **Confirm the one sending detail.** Ask for (or guide them to set up) a verified sender address —
    the "from" address their app's emails come from. Tell them exactly where to confirm it, then save
-   it to the secret settings file.
+   it to the secret settings file. For the sending key (Resend by default), ask the builder to run
+   `vybekiit-automate resend setup` in their own terminal. It asks for the key with hidden typing,
+   checks it, and saves `RESEND_API_KEY` to `.env`. Never ask for the key in chat.
    **Verify:** the sender address is set and confirmed.
 
 2. **Wire sending.** Connect the app's email sending to `resolveEmailProvider()` (see wrapper for

package/dist/global-skills/setup-payments/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: setup-payments
-description: "the requested purchase flow works in practice. A test purchase succeeds end-to-end; accepting real money requires separately verified live setup. Use when the vibe coder says something like: add payments; take money; sell something; charge people."
+description: "the requested purchase flow works in practice. Use when the vibe coder says something like: add payments; take money; sell something; charge people."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---
@@ -32,14 +32,11 @@ translate every error · celebrate. You wire all the code; the builder only sign
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install the page recipe first (catalog SSOT — Option C).**
-   Copy `apps/componentLibrary/src/pageRecipes/PricingPage.tsx` export `PricingPage` into the buyer app at route `/pricing`.
-   Recipe id: `pricing`. Presets: orders + webhook_events (apply after provider secrets exist).
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Selling physical/digital goods (not only subscriptions)? Also install catalog ids
-   `commerce-products`, `commerce-cart`, `commerce-checkout` via `getPageRecipeInstall`.
-   Also reference `packages/agentKit` `getPageRecipeInstall('setup-payments')` / page-recipe-manifest.json.
-   **Verify:** `/pricing` builds and shows practice plans before provider wiring.
+0. **Add the ready-made pricing page first.** Run `vybekiit add page-recipe pricing`. It adds the page
+   at `/pricing` and lists any data setup to run next (run that after the payment keys are saved).
+   Selling products, not only plans? Also run `vybekiit add page-recipe product-grid`, then `cart` and
+   `checkout` the same way. Keep every `TODO:` in the pages and fill each one in as you connect payments.
+   **Verify:** `/pricing` opens and shows practice plans.
 
 1. **Explain the plan in one line.** *"I'll connect a payment service so you can charge people. I'll do
    the setup — you'll sign in once when I ask."* (Never name Lemon Squeezy, Stripe, or PayPal.)
@@ -48,15 +45,16 @@ translate every error · celebrate. You wire all the code; the builder only sign
    - Run `vybekiit-automate ls setup --json …` (or wizard mode without `--json`).
    - If Lemon Squeezy shows a sign-in screen, the automation **waits** until the builder completes login in the browser, then continues — no separate standby step required.
    - Optional pre-check: `vybekiit-automate ls standby` opens the dashboard and waits the same way.
-   - Write JSON output to `.env` (`LEMONSQUEEZY_STORE_ID`, variant ID, API key, webhook secret).
-   **Verify:** values saved; product exists in test mode.
+   - The command saves the store, product and key settings straight into the app's `.env` and prints only
+     their names. Never copy key values into the chat.
+   **Verify:** the command lists the saved names; product exists in test mode.
 
 3. **Stripe (opt-in).** Merge `mcp-stripe.json` via `agent/mcp-setup.md`; builder OAuth once.
    Agent creates product/price via Stripe MCP; write restricted API key to `.env`.
    **Verify:** test mode product visible in Stripe dashboard.
 
 4. **PayPal (opt-in).** Merge `mcp-paypal.json` via `agent/mcp-setup.md`; builder OAuth once (sandbox).
-   Agent provisions via PayPal MCP; write client id/secret and webhook id to `.env`.
+   Agent provisions via PayPal MCP; write the client secret to `.env`, the client id and webhook id to `settings.env`.
    **Verify:** sandbox checkout completes.
 
 5. **Connect the automatic payment message (webhook).** Webhook URL is `/api/webhook` on the deployed app

package/dist/global-skills/setup-sms/SKILL.md

@@ -27,7 +27,7 @@ Inspect an existing app before changing it. Scaffold a new kit app only when the
 1. **Collect Twilio secret settings** through doctor (never ask the builder to type SIDs by hand):
    `TWILIO_ACCOUNT_SID`, `TWILIO_AUTH_TOKEN`, `TWILIO_FROM_NUMBER`. Optional:
    `TWILIO_VERIFY_SERVICE_SID`, `TWILIO_WHATSAPP_FROM`.
-   **Verify:** values saved to `.env`.
+   **Verify:** values saved to `settings.env` and `.env`.
 
 2. **Set `NOTIFICATIONS_PROVIDER=twilio`.**
    **Verify:** `resolveNotificationsProvider()` does not throw.

package/dist/global-skills/sign-in-with-email-link/SKILL.md

@@ -24,12 +24,10 @@ Inspect an existing app before changing it. Scaffold a new kit app only when the
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install / extend the auth page recipe first (catalog SSOT — Option C).**
-   Copy or extend `apps/componentLibrary/src/pageRecipes/AuthPage.tsx` export `AuthPage` at route `/login`
-   with a "Email me a link" path. Recipe id: `auth`. Preset: auth-bridge.
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Also reference `packages/agentKit` `getPageRecipeInstall('sign-in-with-email-link')` / page-recipe-manifest.json.
-   **Verify:** `/login` shows a practice magic-link entry before provider wiring.
+0. **Add the ready-made sign-in page first.** Run `vybekiit add page-recipe auth`. It adds the page
+   at `/login` (if the app already has a sign-in page, it is kept). Then add an "Email me a link" option to it.
+   Keep every `TODO:` in the page and fill each one in as you connect the real service.
+   **Verify:** `/login` opens and shows an "Email me a link" option with practice content.
 
 1. **Confirm sign-in + email are wired** (`add-signin`, `setup-email` when going live).
    **Verify:** email OTP or password sign-in already works.

package/dist/global-skills/sign-in-with-google/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sign-in-with-google
-description: "people can tap **Continue with Google** — one button that signs them in **or** creates. Use when the vibe coder says something like: sign in with google; continue with google."
+description: "people can tap Continue with Google — one button that signs them in or creates their account. Use when the vibe coder says something like: sign in with google; continue with google."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---
@@ -28,14 +28,12 @@ needs it.
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install / extend the auth page recipe first (catalog SSOT — Option C).**
-   Copy or extend `apps/componentLibrary/src/pageRecipes/AuthPage.tsx` export `AuthPage` at route `/login`
-   with a **Continue with Google** button. Recipe id: `auth`. Preset: auth-bridge.
-   Legal pages when needed: `TermsOfServicePage` → `/terms`, `PrivacyPolicyPage` → `/privacy`
-   from the page-recipe manifest (group `legal`).
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Also reference `packages/agentKit` `getPageRecipeInstall('sign-in-with-google')` / page-recipe-manifest.json.
-   **Verify:** `/login` shows practice Google button before provider wiring.
+0. **Add the ready-made sign-in page first.** Run `vybekiit add page-recipe auth`. It adds the page
+   at `/login` (if the app already has a sign-in page, it is kept). Then add a "Continue with Google" button to it.
+   Keep every `TODO:` in the page and fill each one in as you connect the real service.
+   Need terms and privacy pages for Google? Run `vybekiit add page-recipe terms-of-service` and
+   `vybekiit add page-recipe privacy-policy` (they add `/terms` and `/privacy`).
+   **Verify:** `/login` opens and shows a practice "Continue with Google" button.
 
 1. **Make sure the basics exist.** Database (`save-data`) and base sign-in (`add-signin`) must work
    first — Google builds on top.
@@ -45,10 +43,13 @@ needs it.
    If it says "not signed in yet," walk the builder through the one command it prints.
    **Verify:** doctor reports gcloud ready.
 
-3. **Create the Google login for your app.** Use `gcloud` to create a **Web application** OAuth client.
-   Write `GOOGLE_OAUTH_CLIENT_ID`, `GOOGLE_OAUTH_CLIENT_SECRET`, and `GOOGLE_OAUTH_REDIRECT_URI`
-   to `.env`. Never ask the builder to open the Google Cloud console.
-   **Verify:** all three values are non-empty in `.env`.
+3. **Create the Google login for your app.** Run `vybekiit-automate google oauth --json` with
+   `--project=<gcloud-project-id>`, `--app-name=<app-name>`, `--support-email=<builder-email>`,
+   `--app-url=<app-url>` and `--redirect=<app-url>/api/auth/callback/google`. It creates (or fixes) the
+   Web login client and saves `GOOGLE_OAUTH_CLIENT_ID` to `settings.env` and
+   `GOOGLE_OAUTH_CLIENT_SECRET` to `.env`, printing only their names. If Google asks to sign in, the builder signs in once in the
+   browser it opens. Never ask the builder to open the Google Cloud console.
+   **Verify:** both names are listed as saved and are non-empty.
 
 4. **Enable Google on the sign-in handler.** Follow `platform-skills/better-auth-vybekiit.md` — add
    the Google social provider to the auth route. One flow handles sign-in and sign-up.

package/dist/global-skills/sign-in-with-phone/SKILL.md

@@ -25,15 +25,13 @@ Inspect an existing app before changing it. Scaffold a new kit app only when the
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install / extend the auth page recipe first (catalog SSOT — Option C).**
-   Copy or extend `apps/componentLibrary/src/pageRecipes/AuthPage.tsx` export `AuthPage` at route `/login`
-   with phone + code UI. Recipe id: `auth`. Preset: auth-bridge.
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Also reference `packages/agentKit` `getPageRecipeInstall('sign-in-with-phone')` / page-recipe-manifest.json.
-   **Verify:** `/login` shows practice phone sign-in UI before provider wiring.
+0. **Add the ready-made sign-in page first.** Run `vybekiit add page-recipe auth`. It adds the page
+   at `/login` (if the app already has a sign-in page, it is kept). Then add a phone number and code form to it.
+   Keep every `TODO:` in the page and fill each one in as you connect the real service.
+   **Verify:** `/login` opens and shows a phone number and code form with practice content.
 
 1. **Run `setup-sms` first** if Twilio secret settings are not filled in.
-   **Verify:** `NOTIFICATIONS_PROVIDER=twilio` and Twilio keys in `.env`.
+   **Verify:** `NOTIFICATIONS_PROVIDER=twilio` in `settings.env` and `TWILIO_AUTH_TOKEN` in `.env`.
 
 2. **Add phone + code UI** on login → send code, then verify.
    **Verify:** practice mode accepts code `000000` with empty Twilio settings.

package/dist/global-skills/stripe-best-practices/SKILL.md

@@ -14,9 +14,10 @@ description: >-
   processing payments, setting up subscriptions, collecting sales tax, VAT, or
   GST, creating connected accounts, or implementing secure key handling.
 
+disable-model-invocation: true
 ---
 
-Latest Stripe API version: **2026-08-26.dahlia**. Always use the latest API version and SDK unless the user specifies otherwise.
+Latest Stripe API version: **2026-09-30.endive**. Always use the latest API version and SDK unless the user specifies otherwise.
 
 Development and testing environment default: For new integration development, use separate [sandboxes](https://docs.stripe.com/sandboxes.md) instead of the account’s shared test mode sandbox. Sandboxes isolate settings and test data from live mode. Use separate sandboxes for local development and CI. When stronger isolation is useful, dedicate sandboxes to development teams or testing scenarios. Use the shared test mode sandbox only for an existing integration that depends on it or when a required feature doesn’t support general sandboxes.
 

package/dist/global-skills/stripe-best-practices/references/billing.md

@@ -55,6 +55,8 @@ For a flat or per-seat fee plus usage, keep the fee on the existing Stripe Subsc
 ## Traps to avoid
 
 - Don’t call a subscription integration complete without a webhook handler for the subscription lifecycle events (`customer.subscription.*`, `invoice.paid`, `invoice.payment_failed`). Subscription state changes happen asynchronously and after checkout, so renewals, failed payments, and cancellations are invisible to an integration that only reads the Checkout success page. Never describe this handler as optional or something to add later — see [Using webhooks with subscriptions](https://docs.stripe.com/billing/subscriptions/webhooks.md).
+- Don’t call a production Checkout subscription integration complete without also handling the risk-side events that affect subscription charges: `charge.dispute.created`, `charge.refunded`, and `radar.early_fraud_warning.created`. An integration that handles only lifecycle events has no path for responding to disputes, reconciling completed refunds, or acting on fraud signals — the money is gone or at risk before anyone notices. Subscribe to these events and use the version-appropriate object graph to resolve the affected Subscription; see [Handle refund, dispute, and early fraud warning events](https://docs.stripe.com/billing/subscriptions/webhooks.md#refund-events). Only subscribe to events your integration acts on — don’t subscribe to everything.
+- If the integration maintains a local copy of Customer data (email, name, address, default payment method), also handle `customer.updated` so local records stay in sync. For Accounts v2 integrations, the equivalents are `v2.core.account[configuration.customer].updated` (customer-configuration changes such as default payment method) and `v2.core.account[identity].updated` (billing address and identity fields). See [Accounts v2 webhooks](https://docs.stripe.com/accounts-v2/use-accounts-as-customers.md#accounts-v2-webhooks). Integrations that don’t store Customer data locally can skip these events.
 - Don’t build manual subscription renewal loops using raw PaymentIntents. Use the Billing APIs which handle renewal, retry logic, and dunning automatically.
 - Don’t use the deprecated `plan` object. Use [Prices](https://docs.stripe.com/api/prices.md) instead.
 - Don’t put prices for different tiers or plans on a single product. Instead, create one Product for each plan a customer can choose. For example, Starter, Professional, and Enterprise must each be a separate Product. Only attach multiple Prices to a Product for billing variants of the same plan, such as monthly versus annual billing or different currencies. Avoid placing Prices for different tiers on a single Product. Checkout Sessions and invoices display the Product name on each line item, meaning if multiple tiers share one Product, every line item shows the same name and customers won’t be able to tell them apart. For more information, see [Model your product catalog](https://docs.stripe.com/products-prices/how-products-and-prices-work.md#model-your-catalog).

package/dist/global-skills/stripe-best-practices/references/payments.md

@@ -50,7 +50,7 @@ Handle both `checkout.session.completed` and `checkout.session.async_payment_suc
 
 Webhooks are **required**, not optional, for:
 
-- Subscriptions and any recurring billing, where most state changes (renewals, payment failures, cancellations) happen after checkout. Read the Billing skill reference for the lifecycle events to handle.
+- Subscriptions and any recurring billing, where renewals, payment failures, cancellations, and risk events such as disputes, refunds, and fraud signals happen asynchronously after checkout. Read the Billing skill reference for the full set of events to handle, including risk-side events.
 - Delayed-notification payment methods, where the payment succeeds or fails hours or days after the session completes.
 - Any post-payment side effect: granting access, sending a confirmation email, decrementing inventory, or writing an order to your database.
 

package/dist/global-skills/stripe-best-practices/references/tax.md

@@ -20,7 +20,7 @@
 
 ## What Stripe Tax does and doesn’t do
 
-**What Stripe Tax does:** tax calculation, nexus threshold monitoring (Dashboard → Tax → Locations → “Needs attention” and email alerts), registration on the user’s behalf for eligible US remote sellers (“Register for me”; see [Registration safety](https://docs.stripe.com/undefined.md#registration-safety)), and filing through [TaxJar](https://docs.stripe.com/tax/file-with-stripe.md) or [a filing partner](https://docs.stripe.com/tax/filing.md), where available.
+**What Stripe Tax does:** tax calculation, nexus threshold monitoring (Dashboard → Tax → Locations → “Needs attention” and email alerts), registration on the user’s behalf for eligible US remote sellers (“Register for me”; see Registration safety), and filing through [TaxJar](https://docs.stripe.com/tax/file-with-stripe.md) or [a filing partner](https://docs.stripe.com/tax/filing.md), where available.
 
 **What Stripe Tax doesn’t do:** process payments that happen outside Stripe, automatically file every tax return, or support every jurisdiction (check the [supported countries list](https://docs.stripe.com/tax/supported-countries.md) for current coverage). For off-Stripe payments, the [standalone Tax APIs](https://docs.stripe.com/tax/off-stripe.md) can calculate tax and record transactions for reporting and filing.
 
@@ -127,7 +127,7 @@ Threshold monitoring only processes live-mode transactions, not sandbox payments
 
 Guide, don’t advise. Never tell a user where they must register or whether they’re legally obligated. Recommend they consult their tax advisor to determine their obligations.
 
-- The [Tax Registrations API](https://docs.stripe.com/api/tax/registrations.md) can list, create, update, and expire registrations (set `expires_at` to expire; there’s no delete). A scheduled expiry can be changed, but an expiration that has taken effect is permanent (to collect again, the user adds a new registration), and there’s no pause. A head office address is required before adding a registration.
+- The [Tax Registrations API](https://docs.stripe.com/api/tax/registrations.md) can list, create, update, and expire registrations (set `expires_at` to expire; there’s no delete). A scheduled expiration can be changed, but an expiration that has taken effect is permanent (to collect again, the user adds a new registration), and there’s no pause. A head office address is required before adding a registration.
 - Adding a registration in Stripe records where the user is *already* registered. It doesn’t register them with the tax authority.
 - Creating or expiring a registration changes whether Stripe collects tax in that jurisdiction, but it doesn’t register or deregister the user with the tax authority. The user must do that separately. Prepare the change and have the user confirm it; never create or expire a registration automatically.
 

package/dist/global-skills/supabase/CHANGELOG.md

@@ -1,5 +1,24 @@
 # Changelog
 
+## [0.1.9](https://github.com/supabase/agent-skills/compare/v0.1.8...supabase-v0.1.9) (2026-09-28)
+
+
+### Bug Fixes
+
+* **supabase:** recommend scoped personal access tokens for the Management API, CLI, and MCP ([#604](https://github.com/supabase/agent-skills/issues/604)) ([551274e](https://github.com/supabase/agent-skills/commit/551274ed2fe97c8fea1325f7ceb05803a542f8df))
+
+## [0.1.8](https://github.com/supabase/agent-skills/compare/v0.1.7...supabase-v0.1.8) (2026-09-24)
+
+
+### Features
+
+* **supabase:** add debugging workflows to the supabase skill ([#112](https://github.com/supabase/agent-skills/issues/112)) ([3a4f0ce](https://github.com/supabase/agent-skills/commit/3a4f0ce0782e0cbdcf187c362e8d15d9e324462b))
+
+
+### Bug Fixes
+
+* **supabase:** recommend scoped personal access tokens for the Management API, CLI, and MCP ([#604](https://github.com/supabase/agent-skills/issues/604)) ([551274e](https://github.com/supabase/agent-skills/commit/551274ed2fe97c8fea1325f7ceb05803a542f8df))
+
 ## [0.1.7](https://github.com/supabase/agent-skills/compare/v0.1.6...supabase-v0.1.7) (2026-08-12)
 
 

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

@@ -4,6 +4,7 @@ description: "Use when doing ANY task involving Supabase. Triggers: Supabase pro
 metadata:
   author: supabase
   version: "0.1.2"
+disable-model-invocation: true
 ---
 
 # Supabase

package/dist/global-skills/supabase-postgres-best-practices/SKILL.md

@@ -8,6 +8,7 @@ metadata:
   organization: Supabase
   date: January 2026
   abstract: Comprehensive Postgres performance optimization guide for developers using Supabase and Postgres. Contains performance rules across 8 categories, prioritized by impact from critical (query performance, connection management) to incremental (advanced features). Each rule includes detailed explanations, incorrect vs. correct SQL examples, query plan analysis, and specific performance metrics to guide automated optimization and code generation.
+disable-model-invocation: true
 ---
 
 # Supabase Postgres Best Practices

package/dist/global-skills/track-errors/SKILL.md

@@ -27,23 +27,22 @@ translate every error · celebrate. You set up alerts; the builder only pastes o
 ## Steps
 
 <!-- vybekiit:page-recipe-install -->
-0. **Install the page recipe first (catalog SSOT — Option C).**
-   Copy `apps/componentLibrary/src/pageRecipes/SystemHealthPage.tsx` export `SystemHealthPage` into the buyer app at route `/admin/health`.
-   Recipe id: `system-health`. Presets: none.
-   Keep every `TODO:` in the recipe and wire each one after the route renders.
-   Also reference `packages/agentKit` `getPageRecipeInstall('track-errors')` / page-recipe-manifest.json.
-   **Verify:** route builds and shows practice UI before provider wiring.
-
+0. **Add the ready-made page first.** Run `vybekiit add page-recipe system-health`. It adds the page
+   at `/admin/health` and lists any data setup to run next. Keep every `TODO:` in the page and fill
+   each one in as you connect the real service.
+   **Verify:** `/admin/health` opens and shows practice content.
 
 1. **Explain in one line.** *"I'm going to set up alerts so you know when something breaks in your live app."*
 
-2. **Create or open the alert project.** Sign in to the error-tracking dashboard (Sentry free tier) and
-   create a project for this app. Copy the **DSN** (connection string) from project settings.
-   **Verify:** you have a DSN ready — do not paste it in chat.
+2. **Create or open the alert project.** Ask the builder to run `vybekiit-automate sentry setup` in
+   their own terminal. It asks for a Sentry auth token with hidden typing, checks it, and saves
+   `SENTRY_AUTH_TOKEN` to `.env`. With that token, create a project for this app through the Sentry
+   API (free tier) and read its **DSN** (connection string).
+   **Verify:** you have a DSN ready. Never paste it in chat.
 
-3. **Wire it in.** Set in `.env`:
+3. **Wire it in.** Set in `settings.env`:
    - `OBSERVABILITY_PROVIDER="sentry"`
-   - `SENTRY_DSN="<paste from dashboard>"`
+   - `SENTRY_DSN="<DSN from step 2>"`
    Confirm `instrumentation.ts` and `src/lib/observability.ts` exist and import `@vybekiit/observability`.
    **Verify:** app builds; provider resolves without error.
 
@@ -59,7 +58,7 @@ translate every error · celebrate. You set up alerts; the builder only pastes o
 
 ## If anything breaks
 
-Run `doctor`. Most failures are a missing or wrong DSN — re-copy from the dashboard into `.env` only
+Run `doctor`. Most failures are a missing or wrong DSN — re-copy from the dashboard into `settings.env` only
 (never chat). If MCP fails once, run `vybekiit doc-fallback sentry`.
 
 ## Definition of done

package/dist/global-skills/update-kit/SKILL.md

@@ -23,7 +23,7 @@ translate every error · celebrate. You do the whole update; the builder just wa
 > (Under the hood — agent-only) Updates run through **three channels** inside this one skill:
 > npm package bumps (`@vybekiit/*`), agent-layer refresh from the template mirror, and platform
 > instruction files pinned in `.agents/skills/`. The builder's own app code is never touched — only
-> maintained kit files listed in ADR-0007. Use `planKitUpdate()` from `@vybekiit/agent-kit` for
+> maintained kit files. Use `planKitUpdate()` from `@vybekiit/agent-kit` for
 > channel 1; `vybekiit sync-agent-layer` for channel 2; `npx skills update -y` for channel 3 when
 > `skills-lock.json` exists.
 

package/dist/global-skills/upgrading-expo/SKILL.md

@@ -3,6 +3,7 @@ name: upgrading-expo
 description: Guidelines for upgrading Expo SDK versions and fixing dependency issues
 version: 1.0.0
 license: MIT
+disable-model-invocation: true
 ---
 
 ## References

package/dist/global-skills/use-dom/SKILL.md

@@ -3,6 +3,7 @@ name: use-dom
 description: Use Expo DOM components to run web code in a webview on native and as-is on web. Migrate web code to native incrementally.
 version: 1.0.0
 license: MIT
+disable-model-invocation: true
 ---
 
 ## What are DOM Components?

package/dist/global-skills/use-railway/SKILL.md

@@ -18,6 +18,7 @@ description: >
   `railway up` flow (deploys + signs up on the fly) or `railway login`
   (which creates new accounts on the fly).
 allowed-tools: Bash(railway:*), Bash(which:*), Bash(command:*), Bash(npm:*), Bash(npx:*), Bash(curl:*), Bash(python3:*)
+disable-model-invocation: true
 ---
 
 # Use Railway
@@ -104,7 +105,7 @@ Before any mutation, verify the tool path and context:
 
 ```bash
 command -v railway                # CLI installed
-RAILWAY_CALLER="skill:use-railway@1.5.5" RAILWAY_AGENT_SESSION="railway-skill-$(date +%s)-$$" railway whoami --json
+RAILWAY_CALLER="skill:use-railway@1.6.1" RAILWAY_AGENT_SESSION="railway-skill-$(date +%s)-$$" railway whoami --json
 railway --version                 # check CLI version
 ```
 
@@ -128,7 +129,7 @@ Check once per session and don't re-run it after acting; the restart prompt to t
 
 When Railway MCP is available and the job is a platform-state read, use the matching MCP read instead of shelling out. If using the CLI path, run the CLI checks above.
 
-For Railway CLI calls made while this skill is active, prefix the command with `RAILWAY_CALLER=skill:use-railway@1.5.5` and a stable `RAILWAY_AGENT_SESSION` reused for the current user request. Generate the session id once per user request, then reuse that exact value for later Railway CLI calls in the same workflow. Do not run a separate `export` preflight solely for telemetry; inline env prefixes keep the shell output concise and avoid leaking setup steps into every response.
+For Railway CLI calls made while this skill is active, prefix the command with `RAILWAY_CALLER=skill:use-railway@1.6.1` and a stable `RAILWAY_AGENT_SESSION` reused for the current user request. Generate the session id once per user request, then reuse that exact value for later Railway CLI calls in the same workflow. Do not run a separate `export` preflight solely for telemetry; inline env prefixes keep the shell output concise and avoid leaking setup steps into every response.
 
 **Context resolution - URL IDs always win:**
 - If the user provides a Railway URL, extract IDs from it. Do NOT run `railway status --json`; it returns the locally linked project, which is usually unrelated.
@@ -294,14 +295,14 @@ For anything beyond quick operations, load the references needed for the user's
 | **Analyze a database** ("analyze \<url\>", "analyze db", "analyze database", "analyze service", "introspect", "check my postgres/redis/mysql/mongo") | [analyze-db.md](references/analyze-db.md) | Database introspection and performance analysis. analyze-db.md directs you to the DB-specific reference. **This takes priority over the status/operate routes when a Railway URL to a database service is provided alongside "analyze".** |
 | Create or connect resources | [setup.md](references/setup.md) | Projects, services, databases, buckets, templates, workspaces |
 | Ship code or manage releases | [deploy.md](references/deploy.md) | Deploy, redeploy, restart, build config, monorepo, Dockerfile |
-| Change configuration | [configure.md](references/configure.md) | Environments, variables, config patches, domains, networking |
+| Change configuration ("webhook", "notify on deploy", "custom header", "Slack/Discord notifications") | [configure.md](references/configure.md) | Environments, variables, config patches, domains, networking, project webhooks with the `list-webhooks` / `create-webhook` / `update-webhook` / `test-webhook` / `delete-webhook` MCP tools and their custom headers |
 | Manage feature flags | [feature-flags.md](references/feature-flags.md) | MCP registry operations; CLI targeting rules and rollouts; SDK runtime reads |
 | Define configuration in source control ("IaC", "infrastructure as code", "config as code", `.railway/railway.ts`, `.railway/railway.py`, `.railway/railway.go`, "config migrate/plan/apply/pull") | [iac.md](references/iac.md) | Author/import IaC, migrate legacy JSON/TOML, save and apply reviewed plans, check drift |
 | Manage databases ("PITR", "restore", "backup", "HA", "failover", "switchover", "PgBouncer", "connection pooling") | [databases.md](references/databases.md) | Postgres recovery, HA and pooling; MySQL/Redis HA; use analysis references for performance investigations |
 | Inspect costs or manage spending limits | [usage.md](references/usage.md) | Workspace/project/service usage, billing periods, workspace and Railway Agent limits |
 | Run a coding agent on Railway ("cloud agent", "railway ca", "railway code", "desktop SSH") | [cloud-agents.md](references/cloud-agents.md) | Provision, connect, wake, sleep, delete, or configure desktop access to cloud agent VMs |
 | Check health or debug failures | [operate.md](references/operate.md) | Status, logs, metrics, build/runtime triage, recovery |
-| Trace requests across services ("tracing", "traces", "trace ID", "spans", "OpenTelemetry", "OTel", "OTLP", "instrument my app", "instrument my function", "Bun function", "auto-instrumentation") | [tracing.md](references/tracing.md) | Enable tracing per project or service with the `get-tracing` / `set-service-tracing` / `set-project-tracing` MCP tools or `railway trace enable`, SDK instrumentation (preferred) vs automatic (eBPF), what to instrument, instrumenting a Function (Bun), the provided `OTEL_*` variables, sampling, reading traces with the `list-traces` / `get-trace` MCP tools or `railway trace list` / `get`, the Traces tab |
+| Trace requests across services ("tracing", "traces", "trace ID", "spans", "OpenTelemetry", "OTel", "OTLP", "instrument my app", "instrument my function", "Bun function", "auto-instrumentation") | [tracing.md](references/tracing.md) | Enable tracing per service and environment with the `get-tracing` / `set-service-tracing` MCP tools or `railway trace enable`, the IaC `tracing` block and its current SDK limitation, SDK instrumentation (preferred) vs automatic (eBPF), what to instrument, instrumenting a Function (Bun), the provided `OTEL_*` variables, sampling, reading traces with the `list-traces` / `get-trace` MCP tools or `railway trace list` / `get`, checking what a service's instrumentation covers with `get-tracing-coverage`, the Traces tab |
 | Use a sandbox or build remotely ("sandbox", "scratch environment", "ephemeral box", "build remotely", "remote build", "run this remotely", "checkpoint", "snapshot/save/restore sandbox state") | [sandbox.md](references/sandbox.md) | Create/fork sandboxes, run commands remotely, remote template builds, checkpoints (save/restore sandbox state), port forwarding, teardown. Requires Sandboxes enabled in Priority Boarding — if unavailable, prompt the user to enable it. |
 | Request from API, docs, or community | [request.md](references/request.md) | Railway GraphQL API queries/mutations, metrics queries, Central Station, official docs |
 
@@ -346,7 +347,7 @@ Multi-step workflows follow natural chains:
 - **First deploy**: setup (create project + service), configure (set variables and source), deploy, operate (verify healthy)
 - **Fix a failure**: operate (triage logs), configure (fix config/variables), deploy (redeploy), operate (verify recovery)
 - **Add a domain**: configure (add domain + set port), operate (verify DNS and service health)
-- **Add tracing**: tracing (enable for the project or service with `set-project-tracing` / `set-service-tracing` or `railway trace enable`, prefer SDK instrumentation over automatic, add spans around inbound work, I/O and logical units; for a Function, edit its file with `get-function-source-code` / `update-function-source-code`), configure (set `OTEL_METRICS_EXPORTER`/`OTEL_LOGS_EXPORTER`, start command), deploy (redeploy so the `OTEL_*` variables land), tracing (verify with `x-railway-trace-id` and `get-trace` or `railway trace get`)
+- **Add tracing**: tracing (enable for the service in the right environment with `set-service-tracing` or `railway trace enable`, prefer SDK instrumentation over automatic, add spans around inbound work, I/O and logical units; for a Function, edit its file with `get-function-source-code` / `update-function-source-code`), configure (set `OTEL_METRICS_EXPORTER`/`OTEL_LOGS_EXPORTER`, start command), deploy (redeploy so the `OTEL_*` variables land), tracing (verify with `x-railway-trace-id` and `get-trace` or `railway trace get`, then `get-tracing-coverage` for the database and client spans)
 - **Docs to action**: request (fetch docs answer), route to the relevant operational reference
 
 When composing, return one unified response covering all steps. Don't ask the user to invoke each step separately.