vybekiit 0.7.29 → 0.7.33

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

@@ -1,108 +1,99 @@
-# Firebase Remote Config Android Setup Guide
-
-Important references:
-
-- Refer to the `firebase-basics` skills, particularly those for project and app
-  setup, before proceeding.
-
-## Project and App Setup
-
-Before you begin, ensure you have the following. If a `google-services.json`
-file is present, then use that Firebase project and app. Otherwise you may need
-to create them.
-
-- **Firebase CLI**: Installed and logged in (see `firebase-basics`).
-- **Firebase Project**: Created via
-  `npx -y firebase-tools@latest projects:create` (see `firebase-basics`).
-- **Firebase App**: Created via
-  `npx -y firebase-tools@latest apps:create ANDROID <display-name> --package-name=<package-name>`
-
-The `google-services.json` file must be present in the Android app's module
-directory. If missing, get the config using the Firebase CLI:
-`npx -y firebase-tools@latest apps:sdkconfig ANDROID <App-ID>`.
-
-## Add Dependencies to Gradle Build
-
-These changes are made to your Android project's Gradle files. Google Analytics
-is highly recommended as it enables conditional targeting based on user
-properties and audiences.
-
-### Project-level `build.gradle.kts` (`<project>/build.gradle.kts`)
-
-Ensure the Google Services plugin is in the `plugins` block:
+# Firebase Remote Config - Android Setup Guide (Kotlin)
+
+This guide describes the SDK setup and basic usage patterns for Firebase Remote
+Config in an Android app using Kotlin DSL (`build.gradle.kts`) and Kotlin code.
+
+## Prerequisites
+
+IMPORTANT: Before specifically working with Firebase Remote Config, make sure to
+use the skill and reference `firebase_basics/references/android_setup` to ensure
+the following is done.
+
+- The Firebase CLI is available and authenticated.
+- An Android project exists and is registered with a Firebase Project.
+- The Android project has a Firebase config file (`google-services.json`) and
+  the Google services Gradle plugin (`google-services`).
+
+## 1. Add dependencies to Gradle build files
+
+> [!IMPORTANT] **[AGENT] RESOLVING THE SDK VERSION DETERMINISTICALLY** Never
+> guess or hardcode a memorized out-of-date SDK or plugin version. Before adding
+> dependencies, you MUST query the latest available versions directly from the
+> Google Maven Repository:
+>
+> ```bash
+> # Find the latest Firebase Android BoM version
+> curl -s https://dl.google.com/dl/android/maven2/com/google/firebase/firebase-bom/maven-metadata.xml | grep -oE '<latest>[^<]+' | cut -d'>' -f2
+>
+> # Find the latest firebase-config version
+> curl -s https://dl.google.com/dl/android/maven2/com/google/firebase/firebase-config/maven-metadata.xml | grep -oE '<latest>[^<]+' | cut -d'>' -f2
+> ```
+>
+> If the dependency is already declared, fetch the exact resolved version
+> currently active in the workspace's build graph:
+>
+> ```bash
+> ./gradlew -q :app:dependencyInsight --dependency firebase-config --configuration releaseRuntimeClasspath
+> ```
+
+These changes are made to the Android project's Gradle files.
+
+Google Analytics for Firebase is highly recommended as it enables conditional
+targeting based on user properties and audiences. Additional manual setup for
+Google Analytics is required (see "Before you begin" in
+https://firebase.google.com/docs/analytics/android/get-started.md.txt)
+
+In the **module (app-level)** `build.gradle.kts` (usually
+`<project>/<app-module>/build.gradle.kts`), add the dependencies for Firebase
+Remote Config and Google Analytics:
 
 ```kotlin
-plugins {
-    // ... other plugins
-    id("com.google.gms.google-services") version "4.4.0" apply false
+dependencies {
+    // [AGENT] Fetch the latest resolved version using the Gradle command above
+    implementation(platform("com.google.firebase:firebase-bom:<latest_bom_version>"))
+
+    // Add the dependencies for the Firebase Remote Config and Analytics libraries
+    // When using the BoM, don't specify versions in Firebase library dependencies
+    implementation("com.google.firebase:firebase-config")
+    implementation("com.google.firebase:firebase-analytics")
 }
 ```
 
-### App-level `build.gradle.kts` (`<project>/<app-module>/build.gradle.kts`)
-
-1. Add the Google Services plugin to the `plugins` block:
-
-   ```kotlin
-   plugins {
-       // ... other plugins
-       id("com.google.gms.google-services")
-   }
+______________________________________________________________________
+
+## 2. Set in-app defaults
+
+1. Define default values so the app has functional logic before it ever fetches
+   a template from the server. Create an XML file (e.g.,
+   `res/xml/remote_config_defaults.xml`):
+
+   ```xml
+   <?xml version="1.0" encoding="utf-8"?>
+   <!-- Example Remote Config Defaults File -->
+   <defaultsMap>
+       <entry>
+           <key>welcome_message</key>
+           <value>Welcome to the app!</value>
+       </entry>
+       <entry>
+           <key>is_feature_enabled</key>
+           <value>false</value>
+       </entry>
+   </defaultsMap>
    ```
 
-1. Add the Firebase Remote Config and Analytics dependencies. Using the Firebase
-   Bill of Materials (BoM) is the best practice for version management.
+1. Initialize the SDK in the Activity or Application class:
 
    ```kotlin
-   dependencies {
-       // ... other dependencies
-
-       // Import the Firebase BoM
-       implementation(platform("com.google.firebase:firebase-bom:<latest_bom_version>"))
-
-       // Add the dependencies for Remote Config and Analytics
-       implementation("com.google.firebase:firebase-config")
-       implementation("com.google.firebase:firebase-analytics")
-   }
+   val remoteConfig = Firebase.remoteConfig
+   remoteConfig.setDefaultsAsync(R.xml.remote_config_defaults)
    ```
 
-## Follow up Steps
-
-The following steps cover the essential patterns for using Remote Config
-effectively.
-
-### Set In-App Defaults
-
-Define default values so your app has functional logic before it ever fetches a
-template from the server. Create an XML file (e.g.,
-`res/xml/remote_config_defaults.xml`):
-```xml
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Example Remote Config Defaults File -->
-<defaultsMap>
-    <entry>
-        <key>welcome_message</key>
-        <value>Welcome to the app!</value>
-    </entry>
-    <entry>
-        <key>is_feature_enabled</key>
-        <value>false</value>
-    </entry>
-</defaultsMap>
-```
-
-Then, initialize the SDK in your Activity or Application class:
-
-```kotlin
-import com.google.firebase.Firebase
-import com.google.firebase.remoteconfig.remoteConfig
-
-val remoteConfig = Firebase.remoteConfig
-remoteConfig.setDefaultsAsync(R.xml.remote_config_defaults)
-```
+______________________________________________________________________
 
-### Fetch and Activate Values
+## 3. Fetch and activate values
 
-To apply values from the cloud, you must fetch them and then activate them.
+To apply values from the cloud, fetch them and then activate them in the app:
 
 ```kotlin
 remoteConfig.fetchAndActivate()

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

@@ -3,7 +3,9 @@ name: firebase-security-rules-auditor
 description: >-
   Audits Firebase (Firestore, Cloud Storage) security rules for vulnerabilities, privilege escalation, role bypasses, create vs update inconsistencies, resource exhaustion, type safety, size limits, and hasOnly ownership checks. Use when auditing/reviewing rules, running red-team rule assessments, or scoring against auditor checklists. Don't use for Firebase CLI (login, deploy), Auth, Crashlytics, Remote Config, or database queries.
 metadata:
+  author: Google LLC
   category: CloudSecurity
+disable-model-invocation: true
 ---
 
 # Overview
@@ -37,12 +39,11 @@ operations to bypass it.
 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.
+   `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:
 
@@ -68,6 +69,7 @@ single hardcoded admin email (e.g., checking request.auth.token.email ==
   access via secure ACLs.
 
 Return your assessment in JSON format using the following structure:
+
 ```json
 {
   "score": 1,

package/dist/global-skills/firestore-rules-creation/SKILL.md

@@ -3,14 +3,24 @@ name: firestore-rules-creation
 description: >-
   Designs, authors, refactors, and hardens production-grade Cloud Firestore Security Rules (firestore.rules). IMPORTANT: If subagent delegation AND the firestore-rules-author subagent are available in your environment, delegate authoring firestore.rules to the firestore-rules-author subagent. If subagent delegation is unavailable (e.g. not enabled in the IDE), firestore-rules-author is not installed, or you are running inside firestore-rules-author, follow this skill directly.
 metadata:
+  author: Google LLC
   category: Databases
+disable-model-invocation: true
 ---
 
 # Firestore Security Rules Creation
 
 > [!IMPORTANT] **Subagent Delegation vs. Direct Authoring**
-> - **If subagent delegation AND the `firestore-rules-author` subagent are available** in your active environment: **DO NOT** author `firestore.rules` directly in the main agent. Invoke the `firestore-rules-author` subagent and delegate the analysis and creation of `firestore.rules` to it.
-> - **If subagent delegation is unavailable** (e.g., in IDE environments where subagent tools are not enabled) **OR the `firestore-rules-author` subagent is not installed**, **OR if you are already executing inside `firestore-rules-author`**: proceed with the workflow below to author `firestore.rules` directly.
+>
+> - **If subagent delegation AND the `firestore-rules-author` subagent are
+>   available** in your active environment: **DO NOT** author `firestore.rules`
+>   directly in the main agent. Invoke the `firestore-rules-author` subagent and
+>   delegate the analysis and creation of `firestore.rules` to it.
+> - **If subagent delegation is unavailable** (e.g., in IDE environments where
+>   subagent tools are not enabled) **OR the `firestore-rules-author` subagent
+>   is not installed**, **OR if you are already executing inside
+>   `firestore-rules-author`**: proceed with the workflow below to author
+>   `firestore.rules` directly.
 
 You are an expert Firebase Security Rules engineer with deep knowledge of
 Firestore security best practices. Your task is to generate comprehensive,
@@ -44,7 +54,9 @@ Follow this structured workflow strictly:
    - CRUD operations (create, read, update, delete)
    - Authentication patterns (Firebase Auth, custom tokens, anonymous)
    - Access patterns and business logic rules
-1. **Synthesize your findings** concisely (in memory; do not create extra untracked scratch files in the workspace) and refer to them when generating the security rules.
+1. **Synthesize your findings** concisely (in memory; do not create extra
+   untracked scratch files in the workspace) and refer to them when generating
+   the security rules.
 
 #### Phase-2: Security Rules Generation
 
@@ -356,12 +368,12 @@ match /users/{userId} {
   pollution. For example, a `tags` array must verify that every item is a string
   AND that each string is within a reasonable length (e.g., < 20 chars).
 
--   **Permission-Field Lockdown:** Fields that control access (e.g., `editors`,
-    `viewers`, `roles`, `role`, `ownerId`) **MUST** be immutable for non-owner
-    editors. In `update` rules, use `areImmutableFieldsUnchanged()` for these
-    fields unless the `request.auth.uid` matches the document's original
-    owner/creator. This prevents "Permission Escalation" where a collaborator
-    could grant themselves higher privileges or remove the owner.
+- **Permission-Field Lockdown:** Fields that control access (e.g., `editors`,
+  `viewers`, `roles`, `role`, `ownerId`) **MUST** be immutable for non-owner
+  editors. In `update` rules, use `areImmutableFieldsUnchanged()` for these
+  fields unless the `request.auth.uid` matches the document's original
+  owner/creator. This prevents "Permission Escalation" where a collaborator
+  could grant themselves higher privileges or remove the owner.
 
 ### Advanced Validation for Business Logic
 
@@ -549,7 +561,8 @@ following attack vectors. You MUST document the outcome of each attempt.
    ones) call the `isValidX()` function? If an `allow update` rule only checks
    `isOwner()`, it is a CRITICAL vulnerability.
 
-Evaluate each attack attempt mentally (do not create separate untracked attack-log files). If ANY attack succeeds:
+Evaluate each attack attempt mentally (do not create separate untracked
+attack-log files). If ANY attack succeeds:
 
 - Fix the security hole
 - Regenerate the rules

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

@@ -30,13 +30,10 @@ asked.
 ## 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.
-
+0. **Add the ready-made page first.** Run `vybekiit add page-recipe launch-checklist`. It adds the page
+   at `/launch` and lists any data setup to run next. Keep every `TODO:` in the page and fill
+   each one in as you connect the real service.
+   **Verify:** `/launch` opens and shows practice content.
 
 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
@@ -56,6 +53,9 @@ asked.
    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.
+   Going online with Cloudflare and need its access key? Run `vybekiit-automate cf setup --json`.
+   The builder signs in to Cloudflare once in the browser it opens; it then creates the key and saves
+   `CLOUDFLARE_ACCOUNT_ID` and `CLOUDFLARE_API_TOKEN` to `.env`, printing only their names.
    **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

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

@@ -1,6 +1,6 @@
 ---
 name: harden
-description: "the builder's app is protected against the common attacks every app faces — someone. Use when the vibe coder says something like: lock down; make it safe; protect from abuse."
+description: "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. Use when the vibe coder says something like: lock down; make it safe; protect from abuse."
 metadata:
   vybekiit-generated: buyer-skill-stub
 ---
@@ -29,7 +29,7 @@ translate every error · celebrate. You do all the work; the builder just approv
 > 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
+> keys in `settings.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
@@ -38,19 +38,16 @@ translate every error · celebrate. You do all the work; the builder just approv
 ## 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.
-
+0. **Add the ready-made page first.** Run `vybekiit add page-recipe audit-log`. It adds the page
+   at `/admin/audit-log` and lists any data setup to run next. Keep every `TODO:` in the page and fill
+   each one in as you connect the real service.
+   **Verify:** `/admin/audit-log` opens and shows practice content.
 
 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"`
+2. **Confirm it's on.** Check `settings.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.

package/dist/global-skills/instrument-feature-flags/SKILL.md

@@ -6,6 +6,7 @@ description: >-
   Also handles initial PostHog SDK setup if not yet installed.
 metadata:
   author: PostHog
+disable-model-invocation: true
 ---
 
 # Add PostHog feature flags

package/dist/global-skills/instrument-product-analytics/SKILL.md

@@ -6,6 +6,7 @@ description: >-
   are captured. Also handles initial PostHog SDK setup if not yet installed.
 metadata:
   author: PostHog
+disable-model-invocation: true
 ---
 
 # Add PostHog product analytics events

package/dist/global-skills/manifest.json

@@ -98,6 +98,7 @@
     "mongodb-connection",
     "mongodb-mcp-setup",
     "mongodb-natural-language-querying",
+    "mongodb-qe-size-estimation",
     "mongodb-query-optimizer",
     "mongodb-schema-design",
     "mongodb-search-and-ai",
@@ -151,5 +152,5 @@
   "resources": [
     "vybekiitReferences"
   ],
-  "count": 147
+  "count": 148
 }

package/dist/global-skills/mongodb-atlas-stream-processing/SKILL.md

@@ -5,6 +5,7 @@ license: Apache-2.0
 metadata:
   version: "1.0.0"
   user-invocable: "true"
+disable-model-invocation: true
 ---
 
 # MongoDB Atlas Streams

package/dist/global-skills/mongodb-connection/SKILL.md

@@ -4,6 +4,7 @@ description: Optimize MongoDB client connection configuration (pools, timeouts,
 license: Apache-2.0
 metadata:
   version: "1.0.0"
+disable-model-invocation: true
 ---
 
 # MongoDB Connection Optimizer

package/dist/global-skills/mongodb-mcp-setup/SKILL.md

@@ -4,6 +4,7 @@ description: Guide users through configuring key MongoDB MCP server options. Use
 license: Apache-2.0
 metadata:
   version: "1.0.0"
+disable-model-invocation: true
 ---
 
 # MongoDB MCP Server Setup

package/dist/global-skills/mongodb-natural-language-querying/SKILL.md

@@ -5,6 +5,7 @@ license: Apache-2.0
 metadata:
   version: "1.0.0"
 allowed-tools: mcp__mongodb__*
+disable-model-invocation: true
 ---
 
 # MongoDB Natural Language Querying