vybekiit 0.7.25 → 0.7.27

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

@@ -15,7 +15,7 @@ to create them.
 - **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 <IOS|ANDROID|WEB> <package-name-or-bundle-id>`
+  `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:
@@ -57,11 +57,11 @@ plugins {
        // ... other dependencies
 
        // Import the Firebase BoM
-       implementation(platform("com.google.firebase:firebase-bom:32.7.0"))
+       implementation(platform("com.google.firebase:firebase-bom:<latest_bom_version>"))
 
        // Add the dependencies for Remote Config and Analytics
-       implementation("com.google.firebase:firebase-config-ktx")
-       implementation("com.google.firebase:firebase-analytics-ktx")
+       implementation("com.google.firebase:firebase-config")
+       implementation("com.google.firebase:firebase-analytics")
    }
    ```
 
@@ -75,17 +75,45 @@ effectively.
 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     <!-- Example Remote Config Defaults File -->     <?xml version="1.0" encoding="utf-8"?>     <defaultsMap>         <entry>             <key>welcome_message</key>             <value>Welcome to the app!</value>         </entry>         <entry>             <key>is_feature_enabled</key>             <value>false</value>         </entry>     </defaultsMap>     `
+```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
 
 To apply values from the cloud, you must fetch them and then activate them.
-`kotlin     remoteConfig.fetchAndActivate()     .addOnCompleteListener(this) { task ->         if (task.isSuccessful) {             val updated = task.result             println("Config params updated: $updated")         } else {             println("Fetch failed")         }         // Access a value         val message = remoteConfig.getString("welcome_message")     }     `
+
+```kotlin
+remoteConfig.fetchAndActivate()
+    .addOnCompleteListener(this) { task ->
+        if (task.isSuccessful) {
+            val updated = task.result
+            println("Config params updated: $updated")
+        } else {
+            println("Fetch failed")
+        }
+        // Access a value
+        val message = remoteConfig.getString("welcome_message")
+    }
+```

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

@@ -16,7 +16,7 @@ Use the `firebase-tools` CLI to set up the project if necessary.
 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>`
+   `npx -y firebase-tools@latest apps:create IOS <display-name> --bundle-id=<bundle-id>`
 1. **Link the GoogleService-Info.plist file:** Use the script in the
    `xcode-project-setup` skill to obtain the config and link.
 
@@ -43,7 +43,6 @@ effectively in your iOS app.
 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">
@@ -56,24 +55,20 @@ backend. Create a property list file (e.g., RemoteConfigDefaults.plist):
 </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 {
@@ -86,4 +81,3 @@ remoteConfig.fetchAndActivate { (status, error) in
     let message = remoteConfig.configValue(forKey: "welcome_message").stringValue
 }
 ```
-````

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

@@ -37,9 +37,9 @@ 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
+   `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
+   (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.
@@ -67,7 +67,18 @@ single hardcoded admin email (e.g., checking request.auth.token.email ==
 - **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" } \] }
+Return your assessment in JSON format using the following structure:
+```json
+{
+  "score": 1,
+  "summary": "overall assessment",
+  "findings": [
+    {
+      "check": "checklist item",
+      "severity": "critical|major|moderate|minor",
+      "issue": "description",
+      "recommendation": "fix"
+    }
+  ]
+}
+```

package/dist/global-skills/{firebase-firestore/references/standard/security_rules.md → firestore-rules-creation/SKILL.md}

@@ -1,4 +1,16 @@
-## 1. Generate Firestore Rules
+---
+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:
+  category: Databases
+---
+
+# 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.
 
 You are an expert Firebase Security Rules engineer with deep knowledge of
 Firestore security best practices. Your task is to generate comprehensive,
@@ -32,8 +44,7 @@ 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. **Document your findings** in a untracked file. Refer to this file 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
 
@@ -173,7 +184,7 @@ function isValidList(list, maxSize) {
 //
 // Validate optional string (if present, must be string and within length)
 function isValidOptionalString(field, minLen, maxLen) {
-  return !('field' in request.resource.data) ||
+  return !(field in request.resource.data) ||
          (request.resource.data[field] is string &&
           request.resource.data[field].size() >= minLen &&
           request.resource.data[field].size() <= maxLen);
@@ -345,12 +356,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 `fieldUnchanged()` 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
 
@@ -358,7 +369,7 @@ Secure rules must enforce the application's business logic. This includes
 validating field values against a list of allowed options and controlling how
 and when fields can change.
 
-\#### 1. Enforce Enum Values
+#### 1. Enforce Enum Values
 
 If a field should only contain specific values (e.g., a status), validate
 against a list.
@@ -375,7 +386,7 @@ against a list.
  allow create: if isValidStatus() && ...
 ```
 
-\#### 2. Validate State Transitions
+#### 2. Validate State Transitions
 
 For `update` operations, you **MUST** validate that a field is changing from a
 valid previous state to a valid new state. This prevents users from bypassing
@@ -538,7 +549,7 @@ 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.
 
-Document each attack attempt and whether it succeeded. 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/grow-my-customers/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: grow-my-customers
+description: Set up or check the five safe customer journeys for welcome, trial reminders, abandoned checkout, upgrades, and win-back.
+---
+
+# Grow my customers
+
+Use this skill when the builder wants automatic customer follow-up.
+
+## Rules
+
+1. Open the Journeys screen and check the current status.
+2. Explain the next single action in plain language, then stop.
+3. Verify the action worked before continuing.
+4. Never send a real test message. Turn on local testing and use **Run safe local test**.
+5. Never weaken permission, unsubscribe, sending-limit, or account-message boundaries.
+6. If a check fails, say what happened and give one action to fix it.
+7. After the local test, confirm each saved enrollment is visible on the Journeys screen.
+8. Record the completed choice in `checklist.md` and update Progress.
+
+## Success
+
+Say: "Your customer journeys are protected and ready 🎉" only after the five journey cards show saved status and no real message was sent.

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

@@ -52,31 +52,31 @@ STEP 6: Set up environment variables.
 
 ## 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
+- `references/react.md` - React feature flags installation
+- `references/react-native.md` - React native feature flags installation
+- `references/web.md` - Web feature flags installation
+- `references/nodejs.md` - Node.js feature flags installation
+- `references/python.md` - Python feature flags installation
+- `references/django.md` - Django
+- `references/flask.md` - Flask
+- `references/php.md` - Php feature flags installation
+- `references/laravel.md` - Laravel
+- `references/ruby.md` - Ruby feature flags installation
+- `references/ruby-on-rails.md` - Ruby on rails
+- `references/go.md` - Go feature flags installation
+- `references/java.md` - Java feature flags installation
+- `references/rust.md` - Rust feature flags installation
+- `references/dotnet.md` - .net feature flags installation
+- `references/dotnet.md` - .net
+- `references/elixir.md` - Elixir feature flags installation
+- `references/android.md` - Android feature flags installation
+- `references/ios.md` - Ios feature flags installation
+- `references/usage.md` - Ios SDK usage
+- `references/flutter.md` - Flutter feature flags installation
+- `references/api.md` - API feature flags installation
+- `references/next-js.md` - Next.js
+- `references/adding-feature-flag-code.md` - Adding feature flag code
+- `references/best-practices.md` - Best practices for production-ready flags
 - `references/COMMANDMENTS.md` - Framework-specific rules the integration must follow
 
 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.