vybekiit 0.4.0 → 0.6.0

package/dist/global-skills/building-native-ui/references/zoom-transitions.md

@@ -0,0 +1,158 @@
+# Apple Zoom Transitions
+
+Fluid zoom transitions for navigating between screens. iOS 18+, Expo SDK 55+, Stack navigator only.
+
+```tsx
+import { Link } from "expo-router";
+```
+
+## Basic Zoom
+
+Use `withAppleZoom` on `Link.Trigger` to zoom the entire trigger element into the destination screen:
+
+```tsx
+<Link href="/photo" asChild>
+  <Link.Trigger withAppleZoom>
+    <Pressable>
+      <Image
+        source={{ uri: "https://example.com/thumb.jpg" }}
+        style={{ width: 120, height: 120, borderRadius: 12 }}
+      />
+    </Pressable>
+  </Link.Trigger>
+</Link>
+```
+
+## Targeted Zoom with `Link.AppleZoom`
+
+Wrap only the element that should animate. Siblings outside `Link.AppleZoom` are not part of the transition:
+
+```tsx
+<Link href="/photo" asChild>
+  <Link.Trigger>
+    <Pressable style={{ alignItems: "center" }}>
+      <Link.AppleZoom>
+        <Image
+          source={{ uri: "https://example.com/thumb.jpg" }}
+          style={{ width: 200, aspectRatio: 4 / 3 }}
+        />
+      </Link.AppleZoom>
+      <Text>Caption text (not zoomed)</Text>
+    </Pressable>
+  </Link.Trigger>
+</Link>
+```
+
+`Link.AppleZoom` accepts only a single child element.
+
+## Destination Target
+
+Use `Link.AppleZoomTarget` on the destination screen to align the zoom animation to a specific element:
+
+```tsx
+// Destination screen (e.g., app/photo.tsx)
+import { Link } from "expo-router";
+
+export default function PhotoScreen() {
+  return (
+    <View style={{ flex: 1 }}>
+      <Link.AppleZoomTarget>
+        <Image
+          source={{ uri: "https://example.com/full.jpg" }}
+          style={{ width: "100%", aspectRatio: 4 / 3 }}
+        />
+      </Link.AppleZoomTarget>
+      <Text>Photo details below</Text>
+    </View>
+  );
+}
+```
+
+Without a target, the zoom animates to fill the entire destination screen.
+
+## Custom Alignment Rectangle
+
+For manual control over where the zoom lands on the destination, use `alignmentRect` instead of `Link.AppleZoomTarget`:
+
+```tsx
+<Link.AppleZoom alignmentRect={{ x: 0, y: 0, width: 200, height: 300 }}>
+  <Image source={{ uri: "https://example.com/thumb.jpg" }} />
+</Link.AppleZoom>
+```
+
+Coordinates are in the destination screen's coordinate space. Prefer `Link.AppleZoomTarget` when possible — use `alignmentRect` only when the target element isn't available as a React component.
+
+## Controlling Dismissal
+
+Zoom screens support interactive dismissal gestures by default (pinch, swipe down when scrolled to top, swipe from leading edge). Use `usePreventZoomTransitionDismissal` on the destination screen to control this.
+
+### Disable all dismissal gestures
+
+```tsx
+import { usePreventZoomTransitionDismissal } from "expo-router";
+
+export default function PhotoScreen() {
+  usePreventZoomTransitionDismissal();
+  return <Image source={{ uri: "https://example.com/full.jpg" }} />;
+}
+```
+
+### Restrict dismissal to a specific area
+
+Use `unstable_dismissalBoundsRect` to prevent conflicts with scrollable content:
+
+```tsx
+usePreventZoomTransitionDismissal({
+  unstable_dismissalBoundsRect: {
+    minX: 0,
+    minY: 0,
+    maxX: 300,
+    maxY: 300,
+  },
+});
+```
+
+This is useful when the destination contains a zoomable scroll view — the system gives that scroll view precedence over the dismiss gesture.
+
+## Combining with Link.Preview
+
+Zoom transitions work alongside long-press previews:
+
+```tsx
+<Link href="/photo" asChild>
+  <Link.Trigger withAppleZoom>
+    <Pressable>
+      <Image
+        source={{ uri: "https://example.com/thumb.jpg" }}
+        style={{ width: 120, height: 120 }}
+      />
+    </Pressable>
+  </Link.Trigger>
+  <Link.Preview />
+</Link>
+```
+
+## Best Practices
+
+**Good use cases:**
+- Thumbnail → full image (gallery, profile photos)
+- Card → detail screen with similar visual content
+- Source and destination with similar aspect ratios
+
+**Avoid:**
+- Skinny full-width list rows as zoom sources — the transition looks unnatural
+- Mismatched aspect ratios between source and destination without `alignmentRect`
+- Using zoom with sheets or popovers — only works in Stack navigator
+- Hiding the navigation bar — known issues with header visibility during transitions
+
+**Tips:**
+- Always provide a close or back button — dismissal gestures are not discoverable
+- If the destination has a zoomable scroll view, use `unstable_dismissalBoundsRect` to avoid gesture conflicts
+- Source view doesn't need to match the tap target — only the `Link.AppleZoom` wrapped element animates
+- When source is unavailable (e.g., scrolled off screen), the transition zooms from the center of the screen
+
+## References
+
+- Expo Router Zoom Transitions: https://docs.expo.dev/router/advanced/zoom-transition/
+- Link.AppleZoom API: https://docs.expo.dev/versions/v55.0.0/sdk/router/#linkapplezoom
+- Apple UIKit Fluid Transitions: https://developer.apple.com/documentation/uikit/enhancing-your-app-with-fluid-transitions

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

@@ -0,0 +1,64 @@
+---
+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.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: buy-domain
+
+**Goal:** the app uses the builder's own web address instead of a temporary one.
+
+**Contract:** one action at a time · verify-before-advance · plain language (`language.md`) ·
+translate every error · celebrate. You do the connecting; the builder chooses the name and pays for
+it.
+
+> (Under the hood — agent-only) Register and connect through `@vybekiit/deploy`'s `resolveHosting()`
+> — Cloudflare by default, AWS if the builder's setup uses it. Never name the host to the builder.
+> When nameserver automation needs registrar API keys (Namecheap or GoDaddy), use
+> `registrar-vybekiit.md` + `vybekiit-automate nc|gd setup --json` before step 2.
+
+## Steps
+
+<!-- vybekiit:page-recipe-install -->
+0. **Install the launch checklist recipe first (catalog SSOT — Option C).**
+   Copy `apps/componentLibrary/src/pageRecipes/LaunchChecklistPage.tsx` export `LaunchChecklistPage` into the buyer app at route `/dashboard/launch`
+   (reuse if `go-live` already installed it).
+   Recipe id: `launch-checklist`. Preset: job_runs when deploy jobs are tracked.
+   Keep every `TODO:` in the recipe and wire domain checklist items after the route renders.
+   Also reference `packages/agentKit` `getPageRecipeInstall('buy-domain')` / page-recipe-manifest.json.
+   **Verify:** `/dashboard/launch` builds with practice checklist UI.
+
+1. **Help them choose a name.** Talk through a web address they'd like. Check it's available and
+   guide registration **one step at a time** — they pay for it (it's their address).
+   **Verify:** the domain is registered to them.
+
+2. **Connect it to the live app.** Point the new address at their app for them.
+   **Verify:** the connection is set up. Note the address can take a little while to start
+   working — don't move on until it actually loads.
+
+3. **Update the app's web address settings.** Set `APP_URL` (and the sign-in addresses) to the new
+   domain for them — never make them hand-edit settings.
+   **Verify:** the settings point to the new address.
+
+4. **Open it for real.** Visit the new web address.
+   **Verify:** the app loads at their domain over a secure (padlock) connection.
+   🎉 *Celebrate* — the app lives at their own address now.
+
+## If anything breaks
+
+Run `doctor`. A new address often just needs a little more time to start working, or one setting
+still points at the old address — fix it for them, don't explain the internals.
+
+## Definition of done
+
+The app loads at the builder's own web address with the padlock showing, and its address settings
+match.
+
+## After completing this skill
+
+Append one entry to `checklist.md` Decision log using `formatChecklistEntry({ from, to, because })`.
+
+If MCP or first debug fails once, run `vybekiit doc-fallback <tech-id>` and tell the builder only: *"I'm double-checking the official setup guide for this — hang tight, I'll have the next step in a moment."*

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

@@ -0,0 +1,94 @@
+---
+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.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: check-safety
+
+**Goal:** confirm the app is protected end-to-end before ship — abuse, database safety, and every
+API route classified correctly. Output a plain pass/fail summary for the builder.
+
+**Contract:** one action at a time · verify-before-advance · plain language · celebrate when green.
+
+## Steps
+
+<!-- vybekiit:page-recipe-install -->
+0. **Install the page recipe first (catalog SSOT — Option C).**
+   Copy `apps/componentLibrary/src/pageRecipes/SafetyPage.tsx` export `SafetyPage` into the buyer app at route `/dashboard/safety`.
+   Recipe id: `safety`. Presets: none.
+   Keep every `TODO:` in the recipe and wire each one after the route renders.
+   Also reference `packages/agentKit` `getPageRecipeInstall('check-safety')` / page-recipe-manifest.json.
+   **Verify:** route builds and shows practice UI before provider wiring.
+
+
+1. **Abuse / DDoS layer.** Confirm `SECURITY_RATE_LIMIT` and `SECURITY_ORIGIN_LOCK` are `on` in
+   `.env`. Confirm `middleware.ts` passes the request path for tiered limits. Confirm `/api/webhook`
+   is **not** blocked by origin lock (payment providers POST cross-origin). Run quick probes: hammer
+   `/api/auth/signin` → expect "slow down"; submit `/api/contact` at human pace → still works.
+   **Verify:** login protected; contact form not throttled like login.
+
+1b. **Scheduled tasks (cron safety).** If the app has any scheduled tasks (cron jobs, Vercel crons,
+   Supabase pg_cron, Cloudflare Cron Triggers):
+   - Confirm interval is 15 minutes or more for any task that touches the database
+   - Confirm tasks only run during active hours (not 24/7) unless truly needed
+   - If on a free-tier database (Supabase Free, Neon Free): warn that frequent crons prevent
+     auto-suspend and burn compute quota — the app will go down with no way to deploy a fix
+   **Verify:** no cron will silently exhaust the free tier.
+
+2. **SQL / database safety.** Grep for raw SQL, `$executeRaw`, or string-built queries — replace with
+   `@vybekiit/db` `DataProvider`. If Supabase: confirm RLS on buyer tables. Every API route validates
+   input with zod at the boundary.
+   **Verify:** no raw SQL in app code; DataProvider-only data access.
+
+3. **Endpoint taxonomy.** Audit every `/api/*` route:
+   - Public forms (contact, waitlist) → lenient limit, no session
+   - Auth routes → strict limit
+   - Webhooks → signature verified, origin lock off
+   - `/api/me` and user data → session required
+   - Admin / bulk export → must not exist without auth
+   **Verify:** each route matches the table; fix misclassified routes.
+
+4. **Toolchain.** Run `vybekiit doctor` — agent CLIs, cloud CLIs, platform skills present.
+   If Google sign-in was requested: `GOOGLE_OAUTH_*` populated, gcloud signed in.
+
+5. **Edge (at go-live).** Confirm `infra/cloudflare/` edge worker uses the same `SECURITY_*` toggles.
+   **Verify:** dual-layer protection documented in go-live.
+
+6. **Code readiness (agent-only checks).** Run silently; summarize in plain English:
+   - `node scripts/checkNoConsole.mjs` — no debug `console.log` in `app/` or `src/`
+   - Scan `src/lib/` for duplicate exported function names; merge duplicates
+   - Spot-check API routes use `@/lib/logger` instead of bare console
+   - If going live with alerts: when `OBSERVABILITY_PROVIDER=sentry`, confirm `SENTRY_DSN` is set
+   - Scan for fire-and-forget async calls in API routes and crons: any `logX()`, `trackX()`, or
+     `sendX()` called without `await` (or without `waitUntil`). In serverless, un-awaited async
+     work is killed after response — the work silently never happens. Flag and fix.
+   - Never remove a navigation or layout component without confirming which element the builder
+     means (contract rule ⑨).
+   **Verify:** tell the builder *"Your app is quiet in production and uses one place for each kind of logic."*
+
+7. **UI consistency (agent-only).** Grep checks:
+   - Raw `<button` / `<input` outside `src/components/ui/` in `app/` and feature components → fix to kit primitives
+   - Forbidden UI libs (`@mui/`, `@chakra-ui/`, `antd`, `nativewind`, `@heroui/`) → must be empty in `app/` and `src/` except mirrored namespaces
+   - Namespaced mirrors (`src/components/bundui/`, `magicui/`, etc.) are upstream copies — normalize when composing screens in `app/`
+   - Arbitrary Tailwind `h-[`, `w-[`, `gap-[`, `mt-[` in `app/` → review and normalize
+   **Verify:** tell the builder *"Your app's buttons, spacing, and colors all match — it looks like one professional product."*
+
+8. **Quality smoke (soft).** Run `pnpm verify` — format, lint, typecheck, and tests. Report pass/fail
+   in plain English. On warn-only Biome issues: fix obvious ones; do not block ship on style warnings
+   unless egregious.
+   **Verify:** tell the builder *"Your app is tested and tidy."*
+
+## Definition of done
+
+Plain-language summary: login protected, contact works, webhooks verified, database safe, code quiet in
+production, UI consistent, tests and lint green, doctor green. 🎉 *Celebrate* when all layers pass.
+
+## After completing this skill
+
+Append one entry to `checklist.md` Decision log using `formatChecklistEntry({ from, to, because })`.
+
+If MCP or first debug fails once, run `vybekiit doc-fallback <tech-id>` and tell the builder only: *"I'm double-checking the official setup guide for this — hang tight, I'll have the next step in a moment."*

package/dist/global-skills/claimable-postgres/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: claimable-postgres
+description: >-
+  Provision instant temporary Postgres databases via Claimable Postgres by Neon
+  (neon.new) with no login, signup, or credit card. Supports REST API, CLI, and
+  SDK. Use when users ask for a quick Postgres environment, a throwaway
+  DATABASE_URL for prototyping/tests, or "just give me a DB now". Triggers
+  include: "quick postgres", "temporary postgres", "no signup database",
+  "no credit card database", "instant DATABASE_URL", "npx neon-new", "neon.new",
+  "neon.new API", "claimable postgres API".
+---
+
+# Claimable Postgres
+
+Instant Postgres databases for local development, demos, prototyping, and test environments. No account required. Databases expire after 72 hours unless claimed to a Neon account.
+
+## Quick Start
+
+```bash
+curl -s -X POST "https://neon.new/api/v1/database" \
+  -H "Content-Type: application/json" \
+  -d '{"ref": "agent-skills"}'
+```
+
+Parse `connection_string` and `claim_url` from the JSON response. Write `connection_string` to the project's `.env` as `DATABASE_URL`.
+
+For other methods (CLI, SDK, Vite plugin), see [Which Method?](#which-method) below.
+
+## Which Method?
+
+- **REST API**: Returns structured JSON. No runtime dependency beyond `curl`. Preferred when the agent needs predictable output and error handling.
+- **CLI** (`npx neon-new@latest --yes`): Provisions and writes `.env` in one command. Convenient when Node.js is available and the user wants a simple setup.
+- **SDK** (`neon-new/sdk`): Scripts or programmatic provisioning in Node.js.
+- **Vite plugin** (`vite-plugin-neon-new`): Auto-provisions on `vite dev` if `DATABASE_URL` is missing. Use when the user has a Vite project.
+- **Browser**: User cannot run CLI or API. Direct to https://neon.new.
+
+## REST API
+
+**Base URL:** `https://neon.new/api/v1`
+
+### Create a database
+
+```bash
+curl -s -X POST "https://neon.new/api/v1/database" \
+  -H "Content-Type: application/json" \
+  -d '{"ref": "agent-skills"}'
+```
+
+| Parameter                    | Required | Description                                                                                                           |
+| ---------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------- |
+| `ref`                        | Yes      | Tracking tag that identifies who provisioned the database. Use `"agent-skills"` when provisioning through this skill. |
+| `enable_logical_replication` | No       | Enable logical replication (default: false, cannot be disabled once enabled)                                          |
+
+The `connection_string` returned by the API is a pooled connection URL. For a direct (non-pooled) connection (e.g. Prisma migrations), remove `-pooler` from the hostname. The CLI writes both pooled and direct URLs automatically.
+
+**Response:**
+
+```json
+{
+  "id": "019beb39-37fb-709d-87ac-7ad6198b89f7",
+  "status": "UNCLAIMED",
+  "neon_project_id": "gentle-scene-06438508",
+  "connection_string": "postgresql://...",
+  "claim_url": "https://neon.new/claim/019beb39-...",
+  "expires_at": "2026-01-26T14:19:14.580Z",
+  "created_at": "2026-01-23T14:19:14.580Z",
+  "updated_at": "2026-01-23T14:19:14.580Z"
+}
+```
+
+### Check status
+
+```bash
+curl -s "https://neon.new/api/v1/database/{id}"
+```
+
+Returns the same response shape. Status transitions: `UNCLAIMED` -> `CLAIMING` -> `CLAIMED`. After the database is claimed, `connection_string` returns `null`.
+
+### Error responses
+
+| Condition              | HTTP | Message                          |
+| ---------------------- | ---- | -------------------------------- |
+| Missing or empty `ref` | 400  | `Missing referrer`               |
+| Invalid database ID    | 400  | `Database not found`             |
+| Invalid JSON body      | 500  | `Failed to create the database.` |
+
+## CLI
+
+```bash
+npx neon-new@latest --yes
+```
+
+Provisions a database and writes the connection string to `.env` in one step. Always use `@latest` and `--yes` (skips interactive prompts that would stall the agent).
+
+### Pre-run Check
+
+Check if `DATABASE_URL` (or the chosen key) already exists in the target `.env`. The CLI exits without provisioning if it finds the key.
+
+If the key exists, offer the user three options:
+
+1. Remove or comment out the existing line, then rerun.
+2. Use `--env` to write to a different file (e.g. `--env .env.local`).
+3. Use `--key` to write under a different variable name.
+
+Get confirmation before proceeding.
+
+### Options
+
+| Option                  | Alias | Description                                                           | Default        |
+| ----------------------- | ----- | --------------------------------------------------------------------- | -------------- |
+| `--yes`                 | `-y`  | Skip prompts, use defaults                                            | `false`        |
+| `--env`                 | `-e`  | .env file path                                                        | `./.env`       |
+| `--key`                 | `-k`  | Connection string env var key                                         | `DATABASE_URL` |
+| `--prefix`              | `-p`  | Prefix for generated public env vars                                  | `PUBLIC_`      |
+| `--seed`                | `-s`  | Path to seed SQL file                                                 | none           |
+| `--logical-replication` | `-L`  | Enable logical replication                                            | `false`        |
+| `--ref`                 | `-r`  | Referrer id (use `agent-skills` when provisioning through this skill) | none           |
+
+Alternative package managers: `yarn dlx neon-new@latest`, `pnpm dlx neon-new@latest`, `bunx neon-new@latest`, `deno run -A neon-new@latest`.
+
+### Output
+
+The CLI writes to the target `.env`:
+
+```
+DATABASE_URL=postgresql://...              # pooled (use for application queries)
+DATABASE_URL_DIRECT=postgresql://...       # direct (use for migrations, e.g. Prisma)
+PUBLIC_POSTGRES_CLAIM_URL=https://neon.new/claim/...
+```
+
+## SDK
+
+Use for scripts and programmatic provisioning flows.
+
+```typescript
+import { instantPostgres } from "neon-new";
+
+const { databaseUrl, databaseUrlDirect, claimUrl, claimExpiresAt } =
+  await instantPostgres({
+    referrer: "agent-skills",
+    seed: { type: "sql-script", path: "./init.sql" },
+  });
+```
+
+Returns `databaseUrl` (pooled), `databaseUrlDirect` (direct, for migrations), `claimUrl`, and `claimExpiresAt` (Date object). The `referrer` parameter is required.
+
+## Vite Plugin
+
+For Vite projects, `vite-plugin-neon-new` auto-provisions a database on `vite dev` if `DATABASE_URL` is missing. Install with `npm install -D vite-plugin-neon-new`. See the [Claimable Postgres docs](https://neon.com/docs/reference/claimable-postgres#vite-plugin) for configuration.
+
+## Agent Workflow
+
+### API path
+
+1. **Confirm intent:** If the request is ambiguous, confirm the user wants a temporary, no-signup database. Skip this if they explicitly asked for a quick or temporary database.
+2. **Provision:** POST to `https://neon.new/api/v1/database` with `{"ref": "agent-skills"}`.
+3. **Parse response:** Extract `connection_string`, `claim_url`, and `expires_at` from the JSON response.
+4. **Write .env:** Write `DATABASE_URL=<connection_string>` to the project's `.env` (or the user's preferred file and key). Do not overwrite an existing key without confirmation.
+5. **Seed (if needed):** If the user has a seed SQL file, run it against the new database:
+   ```bash
+   psql "$DATABASE_URL" -f seed.sql
+   ```
+6. **Report:** Tell the user where the connection string was written, which key was used, and share the claim URL. Remind them: the database works now; claim within 72 hours to keep it permanently.
+7. **Optional:** Offer a quick connection test (e.g. `SELECT 1`).
+
+### CLI path
+
+1. **Check .env:** Check the target `.env` for an existing `DATABASE_URL` (or chosen key). If present, do not run. Offer remove, `--env`, or `--key` and get confirmation.
+2. **Confirm intent:** If the request is ambiguous, confirm the user wants a temporary, no-signup database. Skip this if they explicitly asked for a quick or temporary database.
+3. **Gather options:** Use defaults unless context suggests otherwise (e.g., user mentions a custom env file, seed SQL, or logical replication).
+4. **Run:** Execute with `@latest --yes` plus the confirmed options. Always use `@latest` to avoid stale cached versions. `--yes` skips interactive prompts that would stall the agent.
+   ```bash
+   npx neon-new@latest --yes --ref agent-skills --env .env.local --seed ./schema.sql
+   ```
+5. **Verify:** Confirm the connection string was written to the intended file.
+6. **Report:** Tell the user where the connection string was written, which key was used, and that a claim URL is in the env file. Remind them: the database works now; claim within 72 hours to keep it permanently.
+7. **Optional:** Offer a quick connection test (e.g. `SELECT 1`).
+
+### Output Checklist
+
+Always report:
+
+- Where the connection string was written (e.g. `.env`)
+- Which variable key was used (`DATABASE_URL` or custom key)
+- The claim URL (from `.env` or API response)
+- That unclaimed databases are temporary (72 hours)
+
+## Claiming
+
+Claiming is optional. The database works immediately without it. To optionally claim, the user opens the claim URL in a browser, where they sign in or create a Neon account to claim the database.
+
+- **API/SDK:** Give the user the `claim_url` from the create response.
+- **CLI:** `npx neon-new@latest claim` reads the claim URL from `.env` and opens the browser automatically.
+
+Users cannot claim into Vercel-linked orgs; they must choose another Neon org.
+
+## Neon Infrastructure as Code (`neon.ts`)
+
+Claimable databases are deliberately throwaway and provisioned through `neon.new` (above), so they aren't managed by `neon.ts`. Once a user **claims** a database into a Neon account it becomes a normal Neon project — at which point `neon.ts`, Neon's infrastructure-as-code file, is how you manage it going forward (see the `neon` skill for the full reference): declare the services its branches should have, program per-branch compute, and get type-safe env vars.
+
+```bash
+npm i @neon/config
+```
+
+```typescript
+// neon.ts
+import { defineConfig } from "@neon/config/v1";
+
+export default defineConfig({
+  auth: true, // Neon Auth, once you outgrow a bare connection string
+  dataApi: true, // Data API
+  branch: (branch) => (branch.exists ? {} : { ttl: "7d" }), // ephemeral non-default branches
+});
+```
+
+```bash
+neon config apply   # provision the declared services (neon deploy is an alias)
+```
+
+If a project needs branching, multiple services, or durable infrastructure tracked in version control, recommend claiming first and then adopting `neon.ts` — rather than re-provisioning throwaway claimable databases.
+
+## Defaults and Limits
+
+| Parameter | Value     |
+| --------- | --------- |
+| Provider  | AWS       |
+| Region    | us-east-2 |
+| Postgres  | 17        |
+
+Region cannot be changed for claimable databases. Unclaimed databases have stricter quotas. Claiming resets limits to free plan defaults.
+
+|            | Unclaimed | Claimed (Free plan) |
+| ---------- | --------- | ------------------- |
+| Storage    | 100 MB    | 512 MB              |
+| Transfer   | 1 GB      | ~5 GB               |
+| Branches   | No        | Yes                 |
+| Expiration | 72 hours  | None                |
+
+## Auto-provisioning
+
+If the agent needs a database to fulfill a task (e.g. "build me a todo app with a real database") and the user has not provided a connection string, provision one via the API and inform the user. Include the claim URL so they can keep it.
+
+## Safety and UX Notes
+
+- Do not overwrite existing env vars. Check first, then use `--env` or `--key` (CLI) or skip writing (API) to avoid conflicts.
+- Ask before running destructive seed SQL (`DROP`, `TRUNCATE`, mass `DELETE`).
+- For production workloads, recommend standard Neon provisioning instead of temporary claimable databases.
+- If users need long-term persistence, instruct them to open the claim URL right away.
+- After writing credentials to an .env file, check that it's covered by .gitignore. If not, warn the user. Do not modify `.gitignore` without confirmation.

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

@@ -0,0 +1,38 @@
+---
+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.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: configure-capabilities
+
+**Goal:** the app has **only the permissions it needs** — the builder never thinks about Info.plist, Android manifest, or Expo plugins.
+
+**Contract:** invisible to the builder · verify-before-advance · plain language if App Store / Play review needs a human step.
+
+> (Agent-only) Read `expo-deployment` / platform skills. Apply **least privilege** — Apple and Google expect minimal permissions with clear purpose strings for reviewers (agent writes those strings; builder does not edit them).
+
+## When to run
+
+- Adding camera, photos, location, notifications, Bluetooth, background modes, etc.
+- Before EAS build / store submit if `app.json` may be stale vs features shipped
+
+## Steps
+
+1. Inventory features and native APIs used in the codebase.
+2. Add only required Expo config plugins and permission entries.
+3. Write App Store / Play purpose strings where required (agent-only, factual).
+4. **Verify:** `pnpm typecheck`; config matches shipped features.
+
+## Definition of done
+
+`app.json` / native config matches shipped features with minimum permissions; builder was not asked to choose permission names.
+
+## After completing this skill
+
+Append one entry to `checklist.md` Decision log using `formatChecklistEntry({ from, to, because })`.
+
+If MCP or first debug fails once, run `vybekiit doc-fallback <tech-id>` and tell the builder only: *"I'm double-checking the official setup guide for this — hang tight, I'll have the next step in a moment."*

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

@@ -0,0 +1,64 @@
+---
+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.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: connect-account
+
+**Goal:** people can create accounts and sign in **inside the app**.
+
+**Contract:** one action at a time · verify-before-advance · plain language (`language.md`) ·
+translate every error · celebrate. You wire all the code; the builder only approves or pastes a value
+when a step truly needs it.
+
+> (Under the hood — agent-only) A phone can't hold server secrets, so sign-in runs on the **backend**
+> (the web app), not the device. The app calls the backend's auth endpoints over `APP_URL` via
+> `src/lib/auth-client.ts` (using `postJson` from `fetch-json.ts`); the server side resolves the
+> provider (`resolveAuthProvider()` — better-auth by default, Cognito on AWS). The device stores only
+> the returned session pass, in the OS secure store (expo-secure-store). Never name any of this to the
+> builder.
+
+## Steps
+
+1. **Make sure the backend can sign people in.** Run `vybekiit plan-readiness sign-in mobile` and
+   execute every orchestration step (scaffold `backend/` if needed, wire auth, set
+   `EXPO_PUBLIC_APP_URL`) without asking the builder to choose.
+   **Verify:** backend `/health` or web sign-in works and `EXPO_PUBLIC_APP_URL` points at it.
+
+2. **Connect the sign-in screens.** In `src/lib/auth-client.ts`, replace the stubbed
+   `signInWithPassword` / `signUpWithPassword` / `sendEmailCode` / `verifyEmailCode` with real calls
+   to the backend's auth endpoints (these resolve the `TODO(vybekiit): … — skill: connect-account`
+   markers; grep them). Save the returned session pass to the device's secure store, and send it on
+   later requests.
+   **Verify:** the sign-up and login screens accept a real account against the backend.
+
+3. **Protect the dashboard.** Send the user to the login screen when no one is signed in; show the
+   dashboard when they are. This resolves the dashboard's sign-in marker.
+   **Verify:** signed out → sent to login; signed in → see the dashboard.
+
+4. **Write a passing test** covering sign-up → login, and keep it green.
+
+5. **Try it for real on the phone.** Create an account, sign in, and land on the dashboard.
+   **Verify:** the full sign-up → sign-in → dashboard flow works on the device.
+   🎉 *Celebrate* — people can now have their own accounts in the app.
+
+## If anything breaks
+
+Run `doctor`. If backend auth or MCP fails once, run `vybekiit doc-fallback better-auth` and use the
+plain stuck phrase — never say MCP to the builder. Usual causes are also the backend address
+(`APP_URL`) not pointing at the deployed web app, or sign-in not set up yet on the backend.
+
+## Definition of done
+
+A real account can sign up, sign in, and reach the protected dashboard on the phone; a passing test
+covers it; no `connect-account` markers remain (re-grep `TODO(vybekiit)`).
+
+## After completing this skill
+
+Append one entry to `checklist.md` Decision log using `formatChecklistEntry({ from, to, because })`.
+
+If MCP or first debug fails once, run `vybekiit doc-fallback <tech-id>` and tell the builder only: *"I'm double-checking the official setup guide for this — hang tight, I'll have the next step in a moment."*