doc: update crashlytics skill description for consistency

Author: MichaelDoyle

skills/firebase-crashlytics-basics/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: firebase-crashlytics-basics
-description: Instrument mobile applications with Firebase Crashlytics, access crash reports and debug issues. Trigger when the user requests to instrument their mobile application or access crash reports.
+description: Comprehensive guide for Firebase Crashlytics, including SDK setup, instrumentation, and accessing crash reports. Use this skill when the user needs to instrument their mobile application, configure advanced reporting, or debug issues using crash data.
 compatibility: This skill is best used with the Firebase CLI, but does not require it. Install it by running `npm install -g firebase-tools`.
 ---
 
@@ -28,4 +28,4 @@ Access crash reports and manage issues directly through the MCP server:
 
 *   **Reports**: [reports.md](references/reports.md)
 *   **Issues**: [issues.md](references/issues.md)
-*   **Investigations**: [investigations.md](references/investigations.md)
+*   **Investigations**: [investigations.md](references/investigations.md)

skills/firebase-crashlytics-basics/references/android_sdk.md

@@ -113,7 +113,6 @@ firebaseCrashlytics {
     // Enable processing and uploading of native symbols to Crashlytics.
     // This flag is disabled by default because it requires you to have the Android NDK installed.
     nativeSymbolUploadEnabled true
-    
     // Enable uploading of ProGuard/R8 mapping files
     // This is required for de-obfuscating stack traces if your app is minified.
     mappingFileUploadEnabled true
@@ -133,7 +132,6 @@ If you are using NDK and dont see symbolicated stack traces:
 Crashlytics automatically captures ANR (Application Not Responding) events on Android 11+ devices.
 *   **Requirement:** The app must be installed from the Google Play Store (or recognized by Play Services) for ANRs to be reported in many cases, though strictly local debugging often catches them too.
 *   **No Extra Code:** You generally do not need extra code to enable ANR reporting with the latest SDKs.
-```
 
 > **Note:** For the BoM and plugin versions, please refer to the official Firebase documentation for the latest versions.
 

skills/firebase-crashlytics-basics/references/instrument_analytics.md

@@ -168,4 +168,4 @@ private void performSearch(final String query) {
 
 ---
 
-By following these steps, effectively instrument Firebase Analytics events to gain deeper insights into user behavior within the application. Remember to always consider privacy and avoid logging sensitive user data.
+By following these steps, you can effectively instrument Firebase Analytics events to gain deeper insights into user behavior within the application. Remember to always consider privacy and avoid logging sensitive user data.

skills/firebase-crashlytics-basics/references/investigations.md

@@ -6,53 +6,51 @@ Follow these steps to diagnose bugs and and propose fixes for issues.
 2. Use the `crashlytics_get_issue` tool to get more context on the issue.
 3. Use the `crashlytics_batch_get_events` tool to get an example crash for this issue. Use the event names in the sampleEvent fields.
    3a. If you need to read more events, use the `crashlytics_list_events` tool.
-   3b. Apply the same filtering criteria that you used to find the issue, so that you find a appropriate events.
+   3b. Apply the same filtering criteria that you used to find the issue, so that you find appropriate events.
 4. Read the files that exist in the stack trace of the issue to understand the crash deeply.
 5. Determine possible root causes for the crash - no more than 5 potential root causes.
 6. Critique your own determination, analyzing how plausible each scenario is given the crash details.
 7. Choose the most likely root cause given your analysis.
 8. Create a plan for the most likely root cause using the following format for the plan:
 
-```
-## Cause
+    ```
+    ## Cause
 
-<A description of the root cause leading to the issue>
-  - **Fault**: <a determination of whether this code base is at fault or a dependent library is at fault>
-  - **Complexity**: <one of "simple", "moderately simple", "moderately hard", "hard", "oof, I don't know where to start">
+    <A description of the root cause leading to the issue>
+      - **Fault**: <a determination of whether this code base is at fault or a dependent library is at fault>
+      - **Complexity**: <one of "simple", "moderately simple", "moderately hard", "hard", "oof, I don't know where to start">
 
-## Fix
+    ## Fix
 
-<A description of the fix for this issue and a break down of the changes.>
-  1. <Step 1>
-  2. <Step 2>
+    <A description of the fix for this issue and a break down of the changes.>
+      1. <Step 1>
+      2. <Step 2>
 
-## Test
+    ## Test
 
-<A plan for how to test that the issue has been fixed and protect against regressions>
-  1. <Test case 1>
-  2. <Test case 2>
+    <A plan for how to test that the issue has been fixed and protect against regressions>
+      1. <Test case 1>
+      2. <Test case 2>
 
-## Other potential causes
+    ## Other potential causes
 
-1. <Another possible root cause>
-2. <Another possible root cause>
-```
+    1. <Another possible root cause>
+    2. <Another possible root cause>
+    ```
 
-### 9. Special Investigations
+9. If there is not enough information in the crash report to find a root cause, describe why you cannot fix the issue instead of making a guess.
 
-#### 9.1 Analyzing NDK (Native) Crashes
+### Special Investigations
+
+#### Analyzing NDK (Native) Crashes
 Native crashes often look intimidating but follow predictable patterns.
 *   **Signal 11 (SIGSEGV):** Segmentation violation. Usually a null pointer dereference (`*ptr = 0`) or accessing freed memory (Use-after-free).
 *   **Signal 6 (SIGABRT):** Abort. The app deliberately killed itself, often because of an unhandled C++ exception or a failed assertion (`assert(condition)`).
 *   **Missing Symbols:** If the stack trace shows `(missing)` or hex addresses (e.g., `0x000532`), you cannot debug it. Check if `nativeSymbolUploadEnabled` is on and if the correct mappings were uploaded.
 
-#### 9.2 Analyzing ANRs (Application Not Responding)
+#### Analyzing ANRs (Application Not Responding)
 *   **The "Main" Culprit:** Look immediately at the thread named `main`. This is the UI thread.
 *   **Blocked vs. Busy:**
     *   *Blocked:* The main thread is waiting on a lock (monitor contention) held by another thread. Look for "Waiting to lock..." in the stack trace, then find the thread holding that lock.
     *   *Busy:* The main thread is doing too much work (e.g., heavy JSON parsing, sorting a huge list, image processing) directly on the UI thread.
 *   **Deadlocks:** If Thread A holds Lock 1 and wants Lock 2, while Thread B holds Lock 2 and wants Lock 1, nobody moves.
-
-### 10. Finalize the Plan
-
-10. If there is not enough information in the crash report to find a root cause, describe why you cannot fix the issue instead of making a guess.

skills/firebase-crashlytics-basics/references/reports.md

@@ -75,5 +75,5 @@ When displaying a list of issues, use the following format:
   1. Issue <full issue id>
     * <the issue title>
     * <the issue subtitle>
-    * **Description:** <a discription of the issue based on information from the tool response>
+    * **Description:** <a description of the issue based on information from the tool response>
   ```