vybekiit 0.4.0 → 0.6.0

package/dist/global-skills/neon-postgres-egress-optimizer/SKILL.md

@@ -0,0 +1,247 @@
+---
+name: neon-postgres-egress-optimizer
+description: >-
+  Diagnose and fix excessive Postgres egress (network data transfer) in a codebase.
+  Use when a user mentions high database bills, unexpected data transfer costs,
+  network transfer charges, egress spikes, "why is my Neon bill so high",
+  "database costs jumped", SELECT * optimization, query overfetching,
+  reduce Neon costs, optimize database usage, or wants to reduce data sent
+  from their database to their application. Also use when reviewing query
+  patterns for cost efficiency, even if the user doesn't explicitly mention
+  egress or data transfer.
+---
+
+# Postgres Egress Optimizer
+
+Guide the user through diagnosing and fixing application-side query patterns that cause excessive data transfer (egress) from their Postgres database. Most high egress bills come from the application fetching more data than it uses.
+
+## Step 1: Diagnose
+
+Identify which queries transfer the most data. The primary tool is the `pg_stat_statements` extension.
+
+### Check if pg_stat_statements is available
+
+```sql
+SELECT 1 FROM pg_stat_statements LIMIT 1;
+```
+
+If this errors, the extension needs to be created:
+
+```sql
+CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
+```
+
+On Neon, it is available by default but may need this CREATE EXTENSION step.
+
+### Handle empty stats
+
+Stats are cleared when a Neon compute scales to zero and restarts. If the stats are empty or the compute recently woke up:
+
+1. Reset the stats to start a clean measurement window: `SELECT pg_stat_statements_reset();`
+2. Let the application run under representative traffic for at least an hour.
+3. Return and run the diagnostic queries below.
+
+If the user has stats from a production database, use those. If they have no access to production stats, proceed to Step 2 and analyze the codebase directly — code-level patterns are often sufficient to identify the worst offenders.
+
+### Diagnostic queries
+
+Run these to identify the top egress contributors. Focus on queries that return many rows, return wide rows (JSONB, TEXT, BYTEA columns), or are called very frequently.
+
+**Queries returning the most total rows:**
+
+```sql
+SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
+FROM pg_stat_statements
+WHERE calls > 0
+ORDER BY rows DESC
+LIMIT 10;
+```
+
+**Queries returning the most rows per execution** (poorly scoped SELECTs, missing pagination):
+
+```sql
+SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
+FROM pg_stat_statements
+WHERE calls > 0
+ORDER BY avg_rows_per_call DESC
+LIMIT 10;
+```
+
+**Most frequently called queries** (candidates for caching):
+
+```sql
+SELECT query, calls, rows AS total_rows, rows / calls AS avg_rows_per_call
+FROM pg_stat_statements
+WHERE calls > 0
+ORDER BY calls DESC
+LIMIT 10;
+```
+
+**Longest running queries** (not a direct egress measure, but helps identify problem queries during a spike):
+
+```sql
+SELECT query, calls, rows AS total_rows,
+  round(total_exec_time::numeric, 2) AS total_exec_time_ms
+FROM pg_stat_statements
+WHERE calls > 0
+ORDER BY total_exec_time DESC
+LIMIT 10;
+```
+
+### Interpret the results
+
+Rank findings by estimated egress impact:
+
+- **High row count + wide rows** = biggest egress. A query returning 1,000 rows where each row includes a 50KB JSONB column transfers ~50MB per call.
+- **Extreme call frequency** on even small queries adds up. A query called 50,000 times/day returning 10 rows each = 500,000 rows/day.
+- **Cross-reference with the schema** to identify which columns are wide. Look for JSONB, TEXT, BYTEA, and large VARCHAR columns.
+
+## Step 2: Analyze codebase
+
+For each query identified in Step 1, or for each database query in the codebase if no stats are available, check:
+
+- Does it select only the columns the response needs?
+- Does it return a bounded number of rows (LIMIT/pagination)?
+- Is it called frequently enough to benefit from caching?
+- Does it fetch raw data that gets aggregated in application code?
+- Does it use a JOIN that duplicates parent data across child rows?
+
+## Step 3: Fix
+
+Apply the appropriate fix for each problem found. Below are the most common egress anti-patterns and how to fix them.
+
+### Unused columns (SELECT \*)
+
+**Problem:** The query fetches all columns but the application only uses a few. Large columns (JSONB blobs, TEXT fields) get transferred over the wire and discarded.
+
+**Before:**
+
+```sql
+SELECT * FROM products;
+```
+
+**After:**
+
+```sql
+SELECT id, name, price, image_urls FROM products;
+```
+
+### Missing pagination
+
+**Problem:** A list endpoint returns all rows with no LIMIT. This is an unbounded egress risk — every new row in the table increases data transfer on every request. Flag this regardless of current table size.
+
+This is easy to miss because the application may work fine with small datasets. But at scale, an unpaginated endpoint returning 10,000 rows with even moderate column widths can transfer hundreds of megabytes per day.
+
+**Before:**
+
+```sql
+SELECT id, name, price FROM products;
+```
+
+**After:**
+
+```sql
+SELECT id, name, price FROM products
+ORDER BY id
+LIMIT 50 OFFSET 0;
+```
+
+When adding pagination, check whether the consuming client already supports paginated responses. If not, pick sensible defaults and document the pagination parameters in the API.
+
+### High-frequency queries on static data
+
+**Problem:** A query is called thousands of times per day but returns data that rarely changes. Every call transfers the same rows from the database. This pattern is only visible from `pg_stat_statements` — the code itself looks normal.
+
+Look for queries with extremely high call counts relative to other queries. Common examples: configuration tables, category lists, feature flags, user role definitions.
+
+**Fix:** Add a caching layer between the application and the database so it avoids hitting the database on every request.
+
+### Application-side aggregation
+
+**Problem:** The application fetches all rows from a table and then computes aggregates (averages, counts, sums, groupings) in application code. The full dataset transfers over the wire even though the result is a small summary.
+
+**Fix:** Push the aggregation into SQL.
+
+**Before:** The application fetches entire tables and aggregates in code with loops or `.reduce()`.
+
+**After:**
+
+```sql
+SELECT p.category_id,
+       AVG(r.rating) AS avg_rating,
+       COUNT(r.id) AS review_count
+FROM reviews r
+INNER JOIN products p ON r.product_id = p.id
+GROUP BY p.category_id;
+```
+
+### JOIN duplication
+
+**Problem:** A JOIN between a wide parent table and a child table duplicates all parent columns across every child row. If a product has 200 reviews and the product row includes a 50KB JSONB column, the join sends that 50KB × 200 = ~10MB for a single request.
+
+This is distinct from the SELECT \* problem. Even if you select only needed columns, a JOIN still repeats the parent data for every child row. The fix is structural: avoid the join entirely.
+
+**Before:**
+
+```sql
+SELECT * FROM products
+LEFT JOIN reviews ON reviews.product_id = products.id
+WHERE products.id = 1;
+```
+
+**After (two separate queries):**
+
+```sql
+SELECT id, name, price, description, image_urls FROM products WHERE id = 1;
+SELECT id, user_name, rating, body FROM reviews WHERE product_id = 1;
+```
+
+Two queries instead of one JOIN. The product data is fetched once. The reviews are fetched once. No duplication.
+
+## Step 4: Verify
+
+After applying fixes:
+
+1. **Run existing tests** to confirm nothing broke.
+2. **Check the responses** — make sure the API still returns the same data shape. Column selection and pagination changes can break clients that depend on specific fields or full result sets.
+3. **Measure the improvement** — if pg_stat_statements data is available, reset it (`SELECT pg_stat_statements_reset();`), let traffic run, then re-run the diagnostic queries to compare before and after.
+
+## Neon Infrastructure as Code (`neon.ts`)
+
+The fixes above cut **egress** (data transferred out of Postgres). The other big non-prod cost lever is **compute**, and you can codify it durably in `neon.ts` — Neon's infrastructure-as-code file (see the `neon` skill for the full reference) — so dev, preview, and CI branches stay cheap by default instead of relying on per-branch flags:
+
+```bash
+npm i @neon/config
+```
+
+```typescript
+// neon.ts
+import { defineConfig } from "@neon/config/v1";
+
+export default defineConfig({
+  branch: (branch) => {
+    if (branch.exists || branch.isDefault) return {}; // don't touch prod
+    return {
+      ttl: "7d", // ephemeral branches auto-expire instead of accruing storage
+      postgres: {
+        computeSettings: {
+          autoscalingLimitMinCu: 0.25, // scale to zero when idle
+          autoscalingLimitMaxCu: 1, // cap autoscaling on throwaway branches
+          suspendTimeout: "5m",
+        },
+      },
+    };
+  },
+});
+```
+
+```bash
+neon config apply   # apply to the current branch (neon deploy is an alias)
+```
+
+This is complementary, not a substitute: query-pattern fixes are what actually reduce egress charges, while these settings keep non-production compute and storage from quietly inflating the same bill. Because `neon checkout` applies the policy when it creates a branch, new dev/preview branches inherit the cheap profile automatically.
+
+## Further reading
+
+- https://neon.com/docs/introduction/network-transfer.md
+- https://neon.com/docs/introduction/cost-optimization.md

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

@@ -0,0 +1,101 @@
+---
+name: onboarding
+description: take the builder from "I just bought this" to **their app running and visible in front of. Use when the builder says something like: set up my app; let's start; get me going; just bought.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: onboarding
+
+**Goal:** take the builder from "I just bought this" to **their app running and visible in front of
+them** in this one session. This is the keystone — the moment that proves the purchase was worth it.
+
+**Contract:** one action at a time · verify-before-advance · plain language (`language.md`) ·
+translate every error · celebrate. Decide all technical choices yourself.
+
+## Steps
+
+<!-- vybekiit:page-recipe-install -->
+0. **Install the end-user onboarding recipe when the builder 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 builder 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. Ask: *"In one sentence, what do you want to build?"* Use their answer to tailor the
+   starter page later — don't turn it into a technical interview.
+
+1b. **One-time planning offer** (skip if `.vybekiit/state/planning-intro-seen` exists).
+   Ask: *"Before we start building — want to **think it through together** first? I'll ask one question
+   at a time until we're totally aligned. Or we can jump straight to building."*
+   - **Yes** → run `plan-my-idea.md` with their one-sentence answer as seed; when done, continue to
+     step 2.
+   - **No** → continue to step 2.
+   Create `.vybekiit/state/planning-intro-seen` (any content) so this offer never repeats.
+
+2. **Set up the tools, then get the preview running.**
+   First run `vybekiit doctor` — it installs the tools the app will need (for the database and for
+   putting the app online) so the builder never configures anything. It may say a tool "isn't signed
+   in yet" — that's fine for now; sign-in happens later, only when a step needs it (one browser click
+   each). Then install the project's building blocks and start the app yourself, in plain words.
+   After dependencies install, run **quality smoke** yourself: `pnpm verify` (format, lint, typecheck,
+   tests). Confirm `.cursorignore` hides `.env` (doctor checks this). Optionally install UI walkthrough
+   browsers: `pnpm exec playwright install chromium` (agent-only — see `playwright-vybekiit.md`).
+   Fix anything red before showing the preview. The builder hears: *"Everything checks out."*
+   **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`
+   > (Cursor, Claude Desktop, Codex). MongoDB and AWS are advanced only.
+   >
+   > **Payment MCP tier:** Stripe and PayPal use `mcp-stripe.json` / `mcp-paypal.json` when
+   > `setup-payments` runs — same merge guide.
+
+3. **Show them their app.**
+   Give them the one link to open (`http://localhost:3000`) and tell them what they'll see.
+   **Verify:** ask them to confirm they can see the page. Don't continue until they say yes.
+   🎉 *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."*
+
+4. **Make it theirs.**
+   Edit the starter page to reflect the one sentence from step 1 (headline + intro). Keep it simple.
+   **Verify:** the preview updated; they confirm it looks like their idea.
+
+5. **Offer the next goal.**
+   Ask what they want next and route via `goal-index.md`:
+   - take money → `setup-payments`
+   - put it online for real → `go-live`
+   - let people sign in → `add-signin`
+   - save their data → `save-data`
+   - save progress online → `back-up-my-code` (optional nudge after meaningful progress)
+
+## If anything breaks
+
+Stop the steps and run `doctor`. Never show a raw error — say what happened and the one fix.
+
+## Definition of done
+
+The builder has seen their own app running and personalized, and knows the next thing they can ask
+for. Save progress for them (don't make them think about it).
+
+## After completing this skill
+
+Update checklist.md Progress (mark done, note next). If checklist.md doesn't exist yet, create it:
+
+```markdown
+## Progress
+- [x] App running locally (onboarding)
+- [ ] ← next
+
+## Decision log
+```
+
+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/plan-my-idea/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: plan-my-idea
+description: help the builder figure out exactly what they want **before** you build — so the first. Use when the builder says something like: help me plan; figure out my idea; think it through; marketplace; like airbnb.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: plan-my-idea
+
+**Goal:** help the builder figure out exactly what they want **before** you build — so the first
+version matches their idea instead of your guess.
+
+**Contract:** one question at a time · wait for their answer before the next · recommend an answer
+each time · plain language (`language.md`) · never say "grill", "skill", "ADR", slash commands, or
+file names like `CONTEXT.md` (say *"your app's word list"* instead). Decide technical choices
+yourself once the idea is clear.
+
+> (Agent-only) Read `.vybekiit/platform-skills/planning-vybekiit.md` for glossary format and how to
+> challenge fuzzy language. Update `CONTEXT.md` inline as terms resolve — don't batch at the end.
+
+## When to use
+
+- The builder asks to plan, think it through, or figure out their idea first.
+- They describe something big and vague ("a marketplace", "like Airbnb") without specifics.
+- Onboarding offered planning and they said yes.
+- `AGENTS.md` suggests planning and they accept.
+
+## Steps
+
+1. **Open in plain words.** One sentence: *"Let's think this through together — I'll ask one question
+   at a time until we're totally aligned."* If they gave a seed idea, repeat it back so they know you
+   heard them.
+
+2. **Walk the decision tree — one question at a time.**
+   - Ask **one** question, then **stop and wait** for their answer.
+   - For each question, include your **recommended answer** and why (in plain words).
+   - If the answer is in the codebase, explore the code instead of asking.
+   - When they use a fuzzy word ("account", "user", "order"), sharpen it: *"Do you mean someone who
+     pays, or someone who just logs in?"*
+   - When a term is resolved, update `CONTEXT.md` immediately (see `planning-vybekiit.md`).
+
+3. **Stress-test with a concrete scenario** once the shape is emerging.
+   Invent one realistic example that probes edge cases (*"What happens when…?"*). Fix gaps before
+   building.
+
+4. **Close with a plain summary.**
+   Three to five bullets of what you agreed — no jargon. Then offer the **next concrete goal** from
+   `goal-index.md` (payments, sign-in, put it online, build the page, etc.).
+
+## Rules
+
+- Never rush — impatient builders can say "just build it" anytime; honor that and exit gracefully.
+- Never write code during this skill — planning only.
+- If `CONTEXT.md` conflicts with what they just said, call it out gently and reconcile.
+
+## Definition of done
+
+You and the builder share a clear picture of what to build, `CONTEXT.md` captures the agreed words,
+and they know the one thing to ask for next.
+
+## 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/publish-app/SKILL.md

@@ -0,0 +1,72 @@
+---
+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 builder says something like: put it online; publish; make it live; ship it; deploy; publish app.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: publish-app
+
+**Goal:** the builder's app is **in the App Store and Google Play** for anyone to download. This is
+the marquee mobile skill — the payoff a phone app exists for.
+
+**Contract:** one action at a time · verify-before-advance · plain language (`language.md`) ·
+translate every error · celebrate. You run the build and submit; the builder does only the few
+account steps the stores legally require, one at a time.
+
+> (Under the hood — agent-only) Build + submit through the `launch` CLI (launch-store) using the
+> template's `launch.config.ts`. Follow `platform-skills/launch-store-vybekiit.md` and pinned
+> `.agents/skills/expo-deployment`.
+
+## Steps
+
+1. **Pre-flight (code readiness).** Run `check-safety` steps 3–4 (no debug console, kit logger, UI
+   consistency, no forbidden libs) and **quality smoke** (`pnpm verify`) before packaging. Fix
+   anything red before continuing.
+   **Verify:** code checks and quality smoke green.
+
+2. **Confirm the app's identity.** Resolve the `TODO(vybekiit)` markers in `app.json`: a real app
+   **name**, a permanent **unique id** for each store (reverse-domain, e.g. `com.theirbrand.app`),
+   and a tap-to-open address. Set the listing details in `launch.config.ts` (age rating, category,
+   review contact). Decide sensible defaults; confirm the name with the builder.
+   **Verify:** the app's identity is set and no `publish-app` markers remain (re-grep `TODO(vybekiit)`).
+
+3. **The one-time store accounts (they cost money — say so plainly).** Tell them, in plain words,
+   that each store needs a paid developer account (Apple's is a yearly fee; Google's is a one-time
+   fee) and walk them through creating each — **one step at a time**, where to tap. Then guide the
+   one sign-in the build tool needs (a browser opens; they approve).
+   **Verify:** both accounts exist and the tools report they're signed in (run `vybekiit doctor`).
+
+4. **Build the installable version.** Run the build yourself. Explain in one line: *"I'm packaging
+   your app for the stores now — this runs in the cloud and can take a little while."*
+   **Verify:** the build finishes green and an installable file is produced. If it fails, run `doctor`
+   and read the one real cause — never paste the red log.
+
+5. **Submit to the stores.** Send the build in for review.
+   **Verify:** each store confirms the submission was received. 🎉 *Celebrate this milestone* — it's
+   submitted.
+
+6. **Set expectations on review.** Tell them plainly: the stores read every app before it goes
+   public, which can take anywhere from a few hours to a few days — nothing is broken while they
+   wait. Check the review state with `launch status` and report it in plain words; don't claim it's
+   live until the store says so.
+   **Verify:** before telling them it's public, confirm the store shows "ready for sale" / "live".
+   🎉 *Celebrate* — their app is in the stores; give them the links to share.
+
+## If anything breaks
+
+Run `doctor`. The common blockers are: not signed in to a store account, the app's unique id not set,
+or a missing review detail — fix the one cause for them, don't explain the internals.
+
+## Definition of done
+
+The app is submitted (and, once approved, live) on both stores, its identity markers are resolved,
+and the builder has the store links.
+
+## 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/publish-extension/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: publish-extension
+description: the builder's extension is **listed in the Chrome Web Store** for anyone to install. Use when the builder says something like: put it online; publish; make it live; ship it; deploy; chrome store.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: publish-extension
+
+**Goal:** the builder's extension is **listed in the Chrome Web Store** for anyone to install.
+
+**Contract:** one action at a time · verify-before-advance · plain language · celebrate.
+
+> (Agent-only) Use `@vybekiit/browser-automation` (`cws` target) + `chrome-extension-vybekiit.md`.
+> CLI: `vybekiit-automate cws …` or programmatic CWS verb exports.
+> Listing source: `.vybekiit/store/extension/cws-listing.ts`. Never say Chrome Web Store jargon to the builder — say "the extension store."
+
+## Steps
+
+1. **Resolve identity markers.** Fill `TODO(vybekiit): … — skill: publish-extension` in manifest and
+   listing files; confirm name, description, icons with the builder.
+   **Verify:** re-grep shows no publish markers left.
+
+2. **Backend must be live.** Extension features that need accounts/data/payments require the web app
+   online first — run web `go-live` if needed.
+   **Verify:** backend URL loads.
+
+3. **Build the store package.** Produce the zip the store accepts.
+   **Verify:** build succeeds.
+
+4. **One-time developer account.** Plain words: paid Chrome developer registration; one step at a time.
+   **Verify:** account exists.
+
+5. **Submit via automation.** Import or refresh listing from the live store when needed (`vybekiit-automate extension import --json`), edit `.vybekiit/store/extension/cws-listing.ts`, then push (`vybekiit-automate extension update --json`) after verify gate.
+   **Verify:** store dashboard shows the submission. 🎉 Celebrate.
+
+## Definition of done
+
+Store listing submitted (or live) and builder has the public install link when approved.
+
+## 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."*