vybekiit 0.4.0 → 0.6.0

package/dist/global-skills/firebase-remote-config-basics/references/ios_setup.md

@@ -0,0 +1,89 @@
+# Firebase Remote Config iOS Setup Guide
+
+Important references:
+
+- Refer to the `firebase-basics` skills, particularly those for iOS setup,
+  before proceeding.
+- Refer to the `xcode-project-setup` skills.
+
+## Project and App Setup
+
+Use the `firebase-tools` CLI to set up the project if necessary.
+
+1. **Find Bundle ID:** Read the Xcode project to find the iOS bundle ID. Check
+   the `PRODUCT_BUNDLE_IDENTIFIER` value in the `.pbxproj` file or the
+   `Info.plist` file.
+1. **Create Firebase Project:** If no project exists, create one:
+   `npx -y firebase-tools@latest projects:create <project-id> --display-name="My Awesome App"`
+1. **Create Firebase App:** Register the iOS app with the discovered bundle ID:
+   `npx -y firebase-tools@latest apps:create IOS <bundle-id>`
+1. **Link the GoogleService-Info.plist file:** Use the script in the
+   `xcode-project-setup` skill to obtain the config and link.
+
+## Add Swift Package Dependencies
+
+Install the Remote Config and Analytics SDKs using the Swift package manager.
+
+Install the `FirebaseRemoteConfig` and `FirebaseAnalytics` packages from the
+[https://github.com/firebase/firebase-ios-sdk.git](https://github.com/firebase/firebase-ios-sdk.git)
+repository.
+
+## Initialize Firebase in App Code
+
+Modify the application's entry point to initialize Firebase. Refer to the iOS
+setup reference in the firebase-basics skill.
+
+## Follow up Steps
+
+The following steps cover the essential patterns for using Remote Config
+effectively in your iOS app.
+
+### Set In-App Defaults
+
+Define default values so your app behaves as intended before it connects to the
+backend. Create a property list file (e.g., RemoteConfigDefaults.plist):
+
+````
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+    <key>welcome_message</key>
+    <string>Welcome to the app!</string>
+    <key>is_feature_enabled</key>
+    <false/>
+</dict>
+</plist>
+```
+````
+
+Then, initialize the SDK and set the defaults:
+
+````
+```swift
+import FirebaseRemoteConfig
+
+let remoteConfig = RemoteConfig.remoteConfig()
+remoteConfig.setDefaults(fromPlist: "RemoteConfigDefaults")
+```
+````
+
+### Fetch and Activate Values
+
+To retrieve values from the cloud and apply them to your app:
+
+````
+```swift
+remoteConfig.fetchAndActivate { (status, error) in
+    if status == .successFetchedFromRemote || status == .successUsingPreFetchedData {
+        print("Config fetched and activated!")
+    } else {
+        print("Config not fetched")
+    }
+    
+    // Access a value
+    let message = remoteConfig.configValue(forKey: "welcome_message").stringValue
+}
+```
+````

package/dist/global-skills/firebase-security-rules-auditor/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: firebase-security-rules-auditor
+description: A skill to evaluate how secure Firestore security rules are. Use this when Firestore security rules are updated to ensure that the generated rules are extremely secure and robust.
+---
+
+# Overview
+
+This skill acts as an auditor for Firebase Security Rules, evaluating them
+against a rigorous set of criteria to ensure they are secure, robust, and
+correctly implemented.
+
+# Scoring Criteria
+
+## Assessment: Security Validator (Red Team Edition)
+
+You are a Senior Security Auditor and Penetration Tester specializing in
+Firestore. Your goal is to find "the hole in the wall." Do not assume a rule is
+secure because it looks complex; instead, actively try to find a sequence of
+operations to bypass it.
+
+### Mandatory Audit Checklist:
+
+1. **The Update Bypass:** Compare 'create' and 'update' rules. Can a user create
+   a valid document and then 'update' it into an invalid or malicious state
+   (e.g., changing their role, bypassing size limits, or corrupting data types)?
+1. **Authority Source:** Does the security rely on user-provided data
+   (request.resource.data) for sensitive fields like 'role', 'isAdmin', or
+   'ownerId'? Carefully consider the source for that authority.
+1. **Business Logic vs. Rules:** Does the rule set actually support the app's
+   purpose? (e.g., In a collaboration app, can collaborators actually read the
+   data? If not, the rules are "broken" or will force insecure workarounds).
+1. **Storage Abuse:** Are there string length or array size limits? If not,
+   label it as a "Resource Exhaustion/DoS" risk.
+1. **Type Safety:** Are fields checked with 'is string', 'is int', or 'is
+   timestamp'?
+1. **Field-Level vs. Identity-Level Security:** Be careful with rules that use
+   \`hasOnly()\` or \`diff()\`. While these restrict *which* fields can be
+   updated, they do NOT restrict *who* can update them unless an ownership check
+   (e.g., \`resource.data.uid == request.auth.uid\`) is also present. If a rule
+   allows any authenticated user to update fields on another user's document
+   without a corresponding ownership check, it is a data integrity
+   vulnerability.
+
+### Admin Bootstrapping & Privileges:
+
+The admin bootstrapping process is limited in this app. If the rules use a
+single hardcoded admin email (e.g., checking request.auth.token.email ==
+'admin@example.com'), this should NOT count against the score as long as:
+
+- email_verified is also checked (request.auth.token.email_verified == true).
+- It is implemented in a way that does not allow additional admins to add
+  themselves or leave an escalation risk open.
+
+### Scoring Criteria (1-5):
+
+- **1 (Critical):** Unauthorized data access (leaks), privilege escalation, or
+  total validation bypass.
+- **2 (Major):** Broken business logic, self-assigned roles, bypass of controls.
+- **3 (Moderate):** PII exposure (e.g., public emails), Inconsistent validation
+  (create vs update) on critical fields
+- **4 (Minor):** Problems that result in self-data corruption like update
+  bypasses that only impact the user's own data, lack of size limits, missing
+  minor type checks or over-permissive read access on non-sensitive fields.
+- **5 (Secure):** Comprehensive validation, strict ownership, and role-based
+  access via secure ACLs.
+
+Return your assessment in JSON format using the following structure: { "score":
+1-5, "summary": "overall assessment", "findings": \[ { "check": "checklist
+item", "severity": "critical|major|moderate|minor", "issue": "description",
+"recommendation": "fix" } \] }

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

@@ -0,0 +1,90 @@
+---
+name: go-live
+description: the builder's app is online at a real web address that anyone can open. Use when the builder says something like: put it online; publish; make it live; ship it; deploy.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: go-live
+
+**Goal:** the builder's app is online at a real web address that anyone can open.
+
+**Contract:** one action at a time · verify-before-advance · plain language (`language.md`) ·
+translate every error · celebrate. You handle the deploy; the builder only approves/pastes when
+asked.
+
+> (Under the hood — agent-only) Put the app online via `@vybekiit/deploy`'s `resolveHosting()` —
+> Cloudflare by default, Vercel or AWS (Amplify) when the builder's setup uses them. Follow the
+> matching platform wrapper in `.vybekiit/platform-skills/` (`deploy-cloudflare-vybekiit.md`,
+> `deploy-vercel-vybekiit.md`, or `deploy-railway-vybekiit.md`). Pick the host from their settings; don't make the builder choose
+> or hear the host's name (unless they ask).
+
+## Steps
+
+<!-- vybekiit:page-recipe-install -->
+0. **Install the page recipe first (catalog SSOT — Option C).**
+   Copy `apps/componentLibrary/src/pageRecipes/LaunchChecklistPage.tsx` export `LaunchChecklistPage` into the buyer app at route `/dashboard/launch`.
+   Recipe id: `launch-checklist`. Presets: job_runs.
+   Keep every `TODO:` in the recipe and wire each one after the route renders.
+   Also reference `packages/agentKit` `getPageRecipeInstall('go-live')` / page-recipe-manifest.json.
+   **Verify:** route builds and shows practice UI before provider wiring.
+
+
+1. **Pre-flight check.** Run `vybekiit doctor` to make sure the deploy tool is installed, then run
+   the project's checks (tests + build) yourself. Asset optimization runs in `prebuild` / start hooks
+   (`scripts/optimizeAssets.mjs`) — confirm it completes without errors. Run code-readiness greps from `check-safety`
+   (step 6): `node scripts/checkNoConsole.mjs`, duplicate-helper scan, logger spot-check.
+   Run **quality smoke**: `pnpm verify` (format, lint, typecheck, tests). Fix anything red before
+   going online. Confirm production mode on the host will silence debug logs (`NODE_ENV=production`).
+   If anything is red, fix it (or run `doctor`) **before** going online — never publish a broken app.
+   **GEO pre-flight:** when the app has a blog or FAQ, confirm at least one public page includes JSON-LD
+   (view-source on a blog post) and `/llms.txt` returns 200 with curated page paths.
+   **Verify:** build passes locally, deploy tool installed, quality smoke green, no debug console noise,
+   `/llms.txt` reachable when blog/FAQ content exists.
+
+2. **Explain in one line.** *"I'm going to put your app online now. You'll click 'approve' once."*
+
+3. **Sign in + connect the app's home.** If `vybekiit doctor` said the deploy tool isn't signed in,
+   have the builder run the one sign-in command it printed — a browser window opens, they click
+   "approve," and that's the only thing they do (this works the same whichever host their setup
+   uses). Then you create the project and connect the app.
+   **Verify:** the deploy tool reports they're signed in, and the project shows up.
+
+4. **Move the secret settings over.** Copy the needed secret settings into the app's home for them
+   (never paste secrets into chat or commit them).
+   **Verify:** the required settings are present.
+
+5. **Publish.** Put the app online.
+   **Verify:** publishing finishes green and the live URL loads. Open it and confirm the page shows.
+   🎉 *Celebrate* — their app is live; give them the link to share.
+
+5b. **Verify the app's memory is up to date.** If the app saves data (`save-data` was run before),
+   confirm the live database has the same structure as the local one — run the migration status check
+   via `@vybekiit/db`'s `checkMigrationStatus()`. If pending migrations exist, apply them now.
+   **Verify:** migration status shows all applied; no pending.
+
+6. **Want their own web address?** If they'd like to use their own domain instead of the temporary
+   address, run `buy-domain` next.
+
+## If anything breaks
+
+Run `doctor`. Most failures going online are a missing secret setting — add it for them and publish
+again.
+
+## Never
+
+- Never offer a preview/staging deploy. The builder's "deploy" always means production. A preview URL confuses non-technical builders ("which one is real?") and wastes time.
+- Never say "fixed" or "done" after a code change without deploying (contract rule ⑧). If the app is already live, ask to deploy or confirm the builder wants to wait.
+
+## Definition of done
+
+The live URL loads the latest version of their app, and they have the link.
+
+## After completing this skill
+
+Update checklist.md Progress (mark done, note next).
+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/harden/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: harden
+description: the builder's app is protected against the common attacks every app faces — someone. Use when the builder says something like: lock down; make it safe; protect from abuse.
+metadata:
+  vybekiit-generated: buyer-skill-stub
+---
+
+<!-- vybekiit:generated:buyer-skill-stub -->
+
+# Skill: harden
+
+**Goal:** the builder's app is protected against the common attacks every app faces — someone
+hammering the login to guess passwords, bots flooding requests, and other sites secretly making
+requests on a visitor's behalf. By the end, protection is on and confirmed, in plain words.
+
+**Contract:** one action at a time · verify-before-advance · plain language (`language.md`) ·
+translate every error · celebrate. You do all the work; the builder just approves.
+
+> **Good news to lead with:** their app already ships protected — this skill confirms it, tunes it to
+> their app, and (at go-live) extends it to the edge. Don't alarm them; frame it as "making sure your
+> app is safe," not "your app is exposed."
+>
+> (Under the hood — agent-only) Protection is `@vybekiit/security`, driven entirely by the `SECURITY_*`
+> keys in `.env` (the single source of truth — see core `securityConfigSchema`). The web app enforces
+> it in `middleware.ts` (already wired, on by default: same-origin lock + per-IP rate limit on
+> `/api/*`). The same toggles drive the Cloudflare edge config in `infra/cloudflare/` at go-live. Never
+> name "rate limit", "CORS", or "origin" to the builder unless they ask — say "request limits" and
+> "blocking requests from other sites."
+
+## Steps
+
+<!-- vybekiit:page-recipe-install -->
+0. **Install the page recipe first (catalog SSOT — Option C).**
+   Copy `apps/componentLibrary/src/pageRecipes/AuditLogPage.tsx` export `AuditLogPage` into the buyer app at route `/admin/audit`.
+   Recipe id: `audit-log`. Presets: audit_log.
+   Keep every `TODO:` in the recipe and wire each one after the route renders.
+   Also reference `packages/agentKit` `getPageRecipeInstall('harden')` / page-recipe-manifest.json.
+   **Verify:** route builds and shows practice UI before provider wiring.
+
+
+1. **Explain in one line.** *"I'm going to make sure your app is safe from abuse — limiting how fast
+   anyone can hammer it and blocking requests pretending to come from other sites. It's already on; I'll
+   tune it to your app."*
+
+2. **Confirm it's on.** Check `.env` has `SECURITY_RATE_LIMIT="on"` and `SECURITY_ORIGIN_LOCK="on"`
+   (these are the defaults; if a previous step turned one off, turn it back on unless the builder asked
+   otherwise). Confirm `middleware.ts` is present.
+   **Verify:** both switches are `on` and the app still builds.
+
+3. **Tune the limits to their app.** Defaults are 60 requests / 60 seconds per visitor. If they expect
+   heavy legitimate traffic (lots of quick actions), raise `SECURITY_RATE_LIMIT_MAX`; if it's a
+   sensitive internal tool, lower it. Pick a sensible value and tell them in one sentence what it means
+   ("each visitor can do up to N actions a minute before being asked to slow down").
+   **Verify:** the value is a positive number and the app builds.
+
+4. **Allow any sites that genuinely need access.** If they have a separate landing page or another site
+   that calls this app, add its address to `SECURITY_ALLOWED_ORIGINS` (comma-separated). Otherwise leave
+   it blank — that means "only your app," the safest setting.
+   **Verify:** confirm with them which sites (if any) should be allowed.
+
+5. **Prove it works.** Make a quick burst of requests to a `/api/*` route past the limit and confirm the
+   app starts returning "too many requests" (HTTP 429); make a request with a foreign `Origin` header to
+   an API route and confirm it's blocked (HTTP 403). Then confirm a normal page load still works.
+   **Verify:** abuse is blocked, normal use is not. 🎉 *Celebrate* — their app defends itself now.
+
+6. **At go-live, extend it to the edge.** Remind them (or do it during `go-live`) that the same
+   protection also runs at the hosting edge via `infra/cloudflare/` for hosted apps — so abuse is
+   stopped before it even reaches the app. No new values needed; the edge reads the same settings.
+   **DDoS layers (agent-only):** edge worker caps distributed abuse; app tiered limits cap per-instance
+   hammering; Cloudflare WAF rules attach at go-live for the strictest cap.
+
+7. **Tune per-route limits.** Login routes use a **stricter** limit (`SECURITY_RATE_LIMIT_AUTH_MAX`);
+   contact forms and waitlists use a **lenient** limit (`SECURITY_RATE_LIMIT_PUBLIC_FORM_MAX`) so
+   real visitors aren't blocked. Payment webhooks skip origin lock — they're verified by signature instead.
+   **Verify:** `/api/contact` survives human-paced submits while `/api/auth/signin` blocks hammering.
+
+8. **Database safety.** Confirm all data access uses `@vybekiit/db` (no raw SQL). Grep for `$executeRaw`
+   or string-built queries and replace them. Run `vybekiit apply-preset audit_log` and confirm RLS on
+   buyer tables (`platform-skills/db-presets-vybekiit.md`).
+   **Verify:** `vybekiit verify-presets audit_log`; no raw SQL in the app; zod on every API body.
+
+9. **Optional edge KV (agent-only).** `@vybekiit/kv` may back feature flags when you extend hardening —
+   never Redis or Upstash for buyers. Client-side cache is `@vybekiit/client-state` (TanStack Query).
+   **Verify:** no buyer-facing Redis setup docs or env keys added.
+
+## If anything breaks
+
+Run `doctor`. If real visitors hit "too many requests", the limit is too low — raise
+`SECURITY_RATE_LIMIT_MAX`. If a legitimate connected site is blocked, add it to
+`SECURITY_ALLOWED_ORIGINS`. Never paste raw errors; translate to the one fix.
+
+## Definition of done
+
+`SECURITY_RATE_LIMIT` and `SECURITY_ORIGIN_LOCK` are on, tuned to the app, abuse is blocked in a quick
+test, normal use works, and the builder knows (in plain words) their app is protected.
+
+## 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/instrument-feature-flags/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: instrument-feature-flags
+description: >-
+  Add PostHog feature flags to gate new functionality. Use after implementing
+  features or reviewing PRs to ensure safe rollouts with feature flag controls.
+  Also handles initial PostHog SDK setup if not yet installed.
+metadata:
+  author: PostHog
+---
+
+# Add PostHog feature flags
+
+Use this skill to add PostHog feature flags that gate new or changed functionality. Use it after implementing features or reviewing PRs to ensure safe rollouts with feature flag controls. If PostHog is not yet installed, this skill also covers initial SDK setup. Supports any platform or language.
+
+Supported platforms: React, Next.js, React Native, Web (JavaScript), Node.js, Python, PHP, Ruby, Go, Java, Rust, .NET, Elixir, Android, iOS, Flutter, and the REST API.
+
+## Instructions
+
+Follow these steps IN ORDER:
+
+STEP 1: Analyze the codebase and detect the platform.
+  -
+ Look for dependency files (package.json, pubspec.yaml, Podfile, Package.swift, requirements.txt, go.mod, Gemfile, composer.json, mix.exs, etc.) to determine the language and framework.
+  -
+ Look for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb, go.sum, pubspec.lock, Podfile.lock, Package.resolved, mix.lock) to determine the package manager.
+  - Check for existing PostHog setup (SDK initialization, env vars, etc.). If PostHog is already installed and initialized, skip to STEP 3.
+
+STEP 2: Research instrumentation. (Skip if PostHog is already set up.)
+  2.1. Find the reference file below that matches the detected platform — it is the source of truth for SDK initialization, flag evaluation methods, and framework-specific patterns. Read it now.
+  2.2. If no reference matches, fall back to your general knowledge and web search. Use posthog.com/docs as the primary search source.
+
+STEP 3: Create or find the feature flag.
+  - Check if a PostHog MCP server is connected. If available, use its tools to search for an existing feature flag the user wants to instrument, or create a new one.
+  - If no MCP server is available, instruct the user to create the flag in the PostHog dashboard.
+
+STEP 4: Plan release conditions.
+  - Determine the rollout strategy (percentage rollout, user targeting, group targeting, etc.).
+  - Plan how the feature flag will gate the new functionality in code.
+
+STEP 5: Instrument the feature.
+  - Add the feature flag code following the platform-specific reference patterns.
+  - Use server-side evaluation when possible to avoid UI flicker.
+  - Do not alter the fundamental architecture of existing files. Make additions minimal and targeted.
+  - You must read a file immediately before attempting to write it.
+
+STEP 6: Set up environment variables.
+  - Check if the project already has PostHog environment variables configured (e.g. in `.env`, `.env.local`, or framework-specific env files). If valid values already exist, skip this step.
+  - If the PostHog project token is missing, use the PostHog MCP server's `projects-get` tool to retrieve the project's `api_token`. If multiple projects are returned, ask the user which project to use. If the MCP server is not connected or not authenticated, ask the user for their PostHog project token instead.
+  - For the PostHog host URL: check the `projects-get` MCP response for a `region` field — `US` maps to `https://us.i.posthog.com`, `EU` maps to `https://eu.i.posthog.com`. If the region is not available from the MCP response or from existing project configuration, ask the user: "Are you on PostHog US Cloud or EU Cloud?" Do not assume US Cloud.
+  - Write these values to the appropriate env file using the framework's naming convention.
+  - Reference these environment variables in code instead of hardcoding them.
+
+## Reference files
+
+- `references/react.md` - React feature flags installation - docs
+- `references/react-native.md` - React native feature flags installation - docs
+- `references/web.md` - Web feature flags installation - docs
+- `references/nodejs.md` - Node.js feature flags installation - docs
+- `references/python.md` - Python feature flags installation - docs
+- `references/django.md` - Django - docs
+- `references/flask.md` - Flask - docs
+- `references/php.md` - Php feature flags installation - docs
+- `references/laravel.md` - Laravel - docs
+- `references/ruby.md` - Ruby feature flags installation - docs
+- `references/ruby-on-rails.md` - Ruby on rails - docs
+- `references/go.md` - Go feature flags installation - docs
+- `references/java.md` - Java feature flags installation - docs
+- `references/rust.md` - Rust feature flags installation - docs
+- `references/dotnet.md` - .net feature flags installation - docs
+- `references/dotnet.md` - .net - docs
+- `references/elixir.md` - Elixir feature flags installation - docs
+- `references/android.md` - Android feature flags installation - docs
+- `references/ios.md` - Ios feature flags installation - docs
+- `references/usage.md` - Ios SDK usage - docs
+- `references/flutter.md` - Flutter feature flags installation - docs
+- `references/api.md` - API feature flags installation - docs
+- `references/next-js.md` - Next.js - docs
+- `references/adding-feature-flag-code.md` - Adding feature flag code - docs
+- `references/best-practices.md` - Best practices for production-ready flags - docs
+
+Each platform reference contains SDK-specific installation, flag evaluation, and code examples. Find the one matching the user's stack. If unlisted, use the API reference as a fallback.
+
+## Key principles
+
+- **Environment variables**: Always use environment variables for PostHog keys. Never hardcode them.
+- **Minimal changes**: Add feature flag code alongside existing logic. Don't replace or restructure existing code.
+- **Boolean flags first**: Default to boolean flag checks unless the user specifically asks for multivariate flags.
+- **Server-side when possible**: Prefer server-side flag evaluation to avoid UI flicker.