vybekiit 0.7.0 → 0.7.2

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

@@ -1,46 +0,0 @@
-# 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

@@ -1,48 +0,0 @@
-# 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

@@ -1,36 +0,0 @@
-# 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

@@ -1,52 +0,0 @@
-# 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

@@ -1,51 +0,0 @@
-# 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/neon-postgres/references/neon-sdk.md

@@ -1,262 +0,0 @@
-# `@neon/sdk` — the TypeScript client for the Neon API
-
-`@neon/sdk` is the official TypeScript client for the [Neon API](https://neon.com/docs/reference/api-reference): **Fetch-based, zero-dependency, ESM-only**, generated from Neon's [OpenAPI spec](https://neon.com/api_spec/release/v2.json) with an ergonomic layer on top. It is the successor to [`@neondatabase/api-client`](https://www.npmjs.com/package/@neondatabase/api-client) (axios-based, generated-only). The old client is **not deprecated** and is safe to keep using, but new code should prefer `@neon/sdk`.
-
-Use this reference when writing typed, programmatic control of Neon resources in TypeScript — provisioning projects, managing branches/databases/endpoints, transferring projects across orgs, snapshots/restore, consumption metrics, and the beta services (Object Storage, Functions, AI Gateway, scoped credentials).
-
-## When to reach for it (vs MCP / CLI)
-
-- **Neon MCP server and CLI** are for **local development** — a coding agent in your editor or terminal.
-- **`@neon/sdk`** is for **programmatic integration**: CI/CD pipelines where the CLI isn't enough, non-trivial dev scripts, and full platforms that provision and manage fleets of Neon databases (the same open API behind Replit, Netlify DB, Laravel Cloud, and Vercel's Neon marketplace integration). All it needs is a Neon API key.
-
-## Install
-
-```bash
-npm install @neon/sdk
-```
-
-Requires Node.js ≥ 20.19, or any runtime with a global `fetch` (Bun, Deno, edge, browser).
-
-## Two layers, one package
-
-```ts
-import { createNeonClient, raw } from "@neon/sdk";
-```
-
-- **`createNeonClient`** — the high-level ergonomic client: auth once, `{ data, error }` results, typed errors, retries, readiness polling, auto-pagination, and multi-step workflows, organized into resource namespaces (`neon.projects`, `neon.branches`, `neon.postgres`, …).
-- **`raw`** — the full generated 1:1 surface: every endpoint as a standalone, tree-shakeable function (also at the `@neon/sdk/raw` subpath). Speaks the **same** `{ data, error }` / `throwOnError` contract as the ergonomic client.
-
-## Quick start
-
-```ts
-import { createNeonClient } from "@neon/sdk";
-
-const neon = createNeonClient({ apiKey: process.env.NEON_API_KEY! });
-
-// Create a project and get a ready-to-use connection string in one call.
-const { data, error } = await neon.projects.createAndConnect({ name: "my-app" });
-if (error) throw error;
-const { project, connectionString } = data;
-```
-
-## Client configuration
-
-`createNeonClient(config)`:
-
-| Option | Type | Default | Description |
-| --- | --- | --- | --- |
-| `apiKey` | `string \| (() => string \| Promise<string>)` | — (required) | Neon API key, or a function returning it. Sent as a Bearer token. |
-| `throwOnError` | `boolean` | `false` | `true` → methods return the resource directly and **throw** on error. `false` → return `{ data, error }`. **Narrows return types** at the type level. |
-| `waitForReadiness` | `boolean` | `false` | `true` → mutations block until their provisioning `operations` finish, so the returned resource is ready. |
-| `wait` | `{ pollIntervalMs?; timeoutMs? }` | `1000` / `300000` | Readiness poller tuning. |
-| `retries` | `number` | `2` | Automatic retries on always-safe statuses (`423`, `429`, `503`) with backoff. |
-| `orgId` | `string` | — | Default org for project create/list and as the transfer source org. Overridable per call. |
-| `baseUrl` | `string` | `https://console.neon.tech/api/v2` | Override the API base URL. |
-| `fetch` | `typeof fetch` | global `fetch` | Custom fetch (proxies, tests, non-global runtimes). |
-
-Every option except `apiKey` is also accepted **per call** via the trailing `options` arg (`{ throwOnError?, waitForReadiness?, signal? }`), overriding the client default.
-
-## The result model
-
-By default every method resolves to a discriminated `{ data, error }` envelope — no `try/catch`:
-
-```ts
-const { data, error } = await neon.projects.get("late-frost-12345");
-if (error) return; // error is a typed NeonError union
-data; // narrowed to Project
-```
-
-Set `throwOnError` (on the client or per call) to get the bare resource and throw instead — the return type narrows accordingly:
-
-```ts
-const neon = createNeonClient({ apiKey, throwOnError: true });
-const project = await neon.projects.get("…");                          // Project (throws)
-const res     = await neon.projects.get("…", { throwOnError: false }); // { data, error }
-```
-
-## Errors
-
-The `error` channel carries a typed hierarchy (all `Error` subclasses with a `kind` discriminant); the same value is thrown when `throwOnError` is set.
-
-| Class | `kind` | Notable fields |
-| --- | --- | --- |
-| `NeonError` | (base) | `message`, `kind` |
-| `NeonApiError` | `"api"` | `status`, `code`, `requestId`, `response`, `body` |
-| `NeonNotFoundError` | `"not_found"` | 404 — extends `NeonApiError` |
-| `NeonAuthError` | `"auth"` | 401/403 |
-| `NeonRateLimitError` | `"rate_limit"` | 429 (after retries) |
-| `NeonOperationError` | `"operation"` | `operationId`, `status` — an awaited operation failed |
-| `NeonTimeoutError` | `"timeout"` | readiness/wait deadline exceeded |
-| `NeonNetworkError` | `"network"` | transport failure (no response) |
-| `NeonError` | `"client"` | SDK-side errors (e.g. ambiguous connection-string selection) |
-
-```ts
-const { error } = await neon.branches.get(pid, "nope");
-if (error?.kind === "not_found") { /* … */ }
-```
-
-## Pagination
-
-Cursor-paginated `list()` methods return a lazy `Paginated<T>`:
-
-```ts
-const { data: all }  = await neon.projects.list().all();   // every page → { data, error }
-const { data: page } = await neon.projects.list().page();  // one page
-for await (const project of neon.projects.list()) { … }    // stream; throws on a page error
-```
-
-## Readiness & workflows
-
-Neon mutations are asynchronous — they return `operations`. `waitForReadiness` blocks until they settle; the **workflow** methods (`createAndConnect`, `createWithCompute`) default it on and hand back a connection string in one call. The underlying primitive is `neon.operations.waitFor(operations)`.
-
-## API surface (ergonomic client)
-
-Legend: **[P]** returns `Paginated<T>` · **[W]** workflow (multi-step) · **→void** resolves to `void`.
-
-### `neon.projects`
-
-| Method | Returns | Notes |
-| --- | --- | --- |
-| `list(query?)` | **[P]** `ProjectListItem` | `{ search?, org_id?, limit? }` |
-| `get(id)` | `Project` | |
-| `create(input?)` | `Project` | `{ name?, region_id?, pg_version?, org_id?, autoscaling_limit_min_cu?, autoscaling_limit_max_cu?, settings? }` |
-| `createAndConnect(input?, { pooled? })` | **[W]** `{ project, connectionString }` | one call + readiness; `pooled` default `true` |
-| `update(id, input)` | `Project` | `{ name?, settings? }` |
-| `delete(id)` | `Project` | |
-| `transfer({ fromOrgId?, toOrgId, projectIds })` | **→void** | `fromOrgId` defaults to client `orgId` |
-| `transferFromUser({ toOrgId, projectIds })` | **→void** | personal account → org |
-| `recover(id)` | `Project` | beta — recover a soft-deleted project |
-| `permissions.list / grant / revoke` | `ProjectPermission`(`[]`) | share a project by email |
-
-```ts
-// Provision a project and get a pooled connection string in one call
-const { data } = await neon.projects.createAndConnect(
-  { name: "tenant-42", region_id: "aws-us-east-1" },
-  { pooled: true },
-); // data: { project, connectionString }
-
-// Upgrade path: move projects from a sponsored (free) org to the paid org
-await neon.projects.transfer({
-  fromOrgId: sponsoredOrgId, // defaults to the client's `orgId`
-  toOrgId: paidOrgId,
-  projectIds: ["late-frost-12345"],
-});
-```
-
-### `neon.branches`
-
-| Method | Returns | Notes |
-| --- | --- | --- |
-| `list(projectId, query?)` | **[P]** `Branch` | `{ search?, sort_by?, sort_order?, include_deleted? }` |
-| `get(projectId, branchId)` | `Branch` | |
-| `create(projectId, input?)` | `Branch` | `{ name?, parent_id?, parent_lsn?, parent_timestamp?, protected? }` |
-| `update(projectId, branchId, input)` | `Branch` | `{ name?, protected?, expires_at? }` |
-| `delete(projectId, branchId)` | **→void** | |
-| `createWithCompute(projectId, input, { pooled? })` | **[W]** `{ branch, endpoint, connectionString }` | `input`: `{ name?, parentId?, compute?: { minCu?, maxCu?, suspendTimeoutSeconds? } }` |
-| `getDefault(projectId)` / `setDefault(projectId, branchId)` | `Branch` | resolve/set the default branch |
-| `recover(projectId, branchId)` | `Branch` | beta — recover within the 7-day window |
-| `finalizeRestore(projectId, branchId, { name? }?)` | **→void** | commit a restore previewed with `snapshots.restore` |
-
-```ts
-// Branch off the default branch with its own compute — returns a ready connection string
-const { data: prod } = await neon.branches.getDefault(projectId);
-const { data } = await neon.branches.createWithCompute(projectId, {
-  name: "preview/pr-123",
-  parentId: prod?.id,
-  compute: { minCu: 0.25, maxCu: 2 },
-}); // data: { branch, endpoint, connectionString }
-```
-
-### `neon.postgres`
-
-The Postgres data plane of a branch. `neon.postgres.connectionString(params, options?)` resolves a URI, **auto-selecting** the default branch and the sole role/database when omitted:
-
-```ts
-const { data: uri } = await neon.postgres.connectionString({
-  projectId, // branchId?, endpointId?, databaseName?, roleName?, pooled? all optional; pooled default true
-});
-```
-
-Nested namespaces:
-
-- **`neon.postgres.endpoints`** — `list / get / create / update / delete`, plus `start` / `suspend` / `restart` and `listByBranch(projectId, branchId)`.
-- **`neon.postgres.roles`** — `list / get / create / delete`, plus `password(...)` (reveals) and `resetPassword(...)` (rotates; result carries the new password).
-- **`neon.postgres.databases`** — `list / get / create / update / delete`.
-- **`neon.postgres.dataApi`** — `get / create / update / delete` the branch's Data API.
-
-### Beta services
-
-- **`neon.storage`** — branch object storage. `get(projectId, branchId)` → `BranchStorage`; nested `buckets` (`list / create / delete`) and `objects` (`list / get / delete / deleteByPrefix / presign`). Use `presign(..., { operation: "upload" | "download" })` for direct S3-style transfers.
-- **`neon.functions`** — branch Neon Functions. `list` **[P]** `/ get / update / delete`, and `deploy(projectId, branchId, slug, { zip?, runtime?, environment? })` (multipart; poll `get` until `current_deployment.status === "completed"`).
-- **`neon.credentials`** — branch scoped credentials. `list / create / revoke`; secrets (`api_token`, `s3_secret_access_key`) are returned **once** on `create`. Scopes: `storage:read`, `storage:write`, `ai_gateway:invoke`, `functions:invoke`.
-- **`neon.aiGateway`** — `get(projectId, branchId)` → `BranchAiGateway` (404 when the gateway is not enabled on the branch). See the `neon-ai-gateway` skill for calling the gateway itself.
-
-### `neon.snapshots`
-
-| Method | Returns | Notes |
-| --- | --- | --- |
-| `list(projectId)` | `Snapshot[]` | |
-| `create(projectId, branchId, input?)` | `Snapshot` | `{ name?, timestamp?, lsn?, expiresAt? }` (point-in-time) |
-| `update(projectId, snapshotId, input)` | `Snapshot` | `{ name?, expiresAt? }` — `expiresAt: null` clears the TTL |
-| `delete(projectId, snapshotId)` | **→void** | |
-| `restore(projectId, snapshotId, input?)` | `Branch` | see below |
-| `getSchedule` / `setSchedule(projectId, branchId, …)` | `BackupSchedule` / **→void** | |
-
-`restore` input: `{ name?, targetBranchId?, finalize?, preview?, keepOnAbort? }`.
-- Restoring **as a new branch** (no `targetBranchId`) finalizes by default → ready to use.
-- Restoring **onto an existing branch** doesn't finalize by default, so you can preview first.
-- **Transaction-style** `preview`: restores un-finalized, runs your callback, then **finalizes (commit)** on `true` or **deletes the preview branch (abort)** on `false` (unless `keepOnAbort`):
-
-```ts
-await neon.snapshots.restore(projectId, snapshotId, {
-  targetBranchId,
-  preview: async (branch) => (await checks(branch)) === "ok", // true → commit · false → abort
-});
-```
-
-### `neon.operations` / `neon.consumption` / `neon.apiKeys` / `neon.regions` / `neon.user` / `neon.auth`
-
-- **`operations`** — `list` **[P]** `/ get`, and `waitFor(operations, { pollIntervalMs?, timeoutMs?, signal? })` (the readiness primitive).
-- **`consumption`** — cursor-paginated billing metrics: `perProject`, `perProjectV2`, `perBranchV2` (each takes `{ from, to, granularity, project_ids?, org_id? }`; `perBranchV2` requires `project_ids`). Consumption requires a Scale plan or above.
-- **`apiKeys`** — `list / create(keyName) / revoke`; the created `key` token is shown **once**.
-- **`regions.list()`**, **`user.me()` / `user.organizations()`**.
-- **`auth`** — branch-scoped Neon Auth: `get / create / disable / updateConfig`, plus `oauthProviders`, `trustedDomains`, and `users` sub-resources.
-
-## Drop down to the raw client
-
-The ergonomic namespaces don't wrap every endpoint. For anything else, `raw` exposes every endpoint 1:1 — pass `neon.client` so the call reuses the client's auth:
-
-```ts
-import { raw } from "@neon/sdk";
-// or, for guaranteed tree-shaking: import { getProjectBranchSchema } from "@neon/sdk/raw";
-
-const { data, error } = await raw.getProjectBranchSchema({
-  client: neon.client,
-  path: { project_id, branch_id },
-  query: { db_name: "neondb" }, // db_name is required
-});
-```
-
-The raw layer speaks the same result contract: `{ data, error }` by default, or pass `throwOnError: true` for the bare resource. All request/response/error **types** are re-exported flat from `@neon/sdk` for `import type { Project, Branch, … }`.
-
-Wait on operations from a raw mutation with the readiness primitive:
-
-```ts
-const { data } = await raw.createProjectBranch({
-  client: neon.client,
-  path: { project_id: projectId },
-  body: { branch: { name: "wip" } },
-});
-const { error } = await neon.operations.waitFor(data!.operations, { timeoutMs: 120_000 });
-```
-
-## Migrating from `@neondatabase/api-client`
-
-There's no rush — `@neondatabase/api-client` is not being deprecated. When you do move: swap axios-style `try/catch` for the `{ data, error }` envelope (or set `throwOnError: true` to keep throwing), and replace hand-rolled operation polling with `waitForReadiness` / the workflow methods (`createAndConnect`, `createWithCompute`).
-
-## Further reading
-
-- npm: https://www.npmjs.com/package/@neon/sdk
-- Neon TypeScript SDK docs: https://neon.com/docs/reference/typescript-sdk.md
-- Neon API reference: https://neon.com/docs/reference/api-reference
-- Building a platform on Neon: the `neon-for-agent-platforms` skill (`npx skills add neondatabase/neon-for-agent-platforms`) ships runnable `@neon/sdk` scripts for provisioning, branching, snapshots, project transfer, and consumption metrics.