Tweak the connect prompt to look at gitignored files and to be less eager to do more than check your login status (#9133)

* Tweak the connect prompt to look at gitignored files and to be less eager to do more than check your login status

* Loosen prescriptiveness, ease testing proactivity, come up with multiple root causes

* Respond to prompt review comments.

Author: schnecle

src/mcp/prompts/crashlytics/connect.ts

@@ -24,19 +24,36 @@ Active user: ${accountEmail || "<NONE>"}
 ## Required first steps! Absolutely required! Incredibly important!
 
   1. **Make sure the user is logged in. No Crashlytics tools will work if the user is not logged in.**
-    a. Use the \`firebase_get_environment\` tool to verify that the user is logged in,
-       and find the active Firebase project.
+    a. Use the \`firebase_get_environment\` tool to verify that the user is logged in.
     b. If the Firebase 'Active user' is set to <NONE>, instruct the user to run \`firebase login\` 
-       before continuing. 
-
-  2. **Get the app_id for the Firebase application.** 
-    a. If this is an Android app, read the mobilesdk_app_id value specified in the 
-       google-services.json file. If there are multiple files or multiple app ids in a 
-       single file, ask the user to choose one by providing a numbered list of all the package names.
-    b. If this is an iOS app, read the GOOGLE_APP_ID from GoogleService-Info.plist file. 
-       If there are multiple files or multiple app ids in single file, ask the user to 
-       choose one by providing a numbered list of all the bundle names.
-    c. If you can't find either of the above, just ask the user for the app id.
+       before continuing. Ignore other fields that are set to <NONE>. We are just making sure the
+       user is logged in. 
+
+  2. **Get the app ID for the Firebase application.** 
+     
+    Use the information below to help you find the developer's app ID. If you cannot find it after 2-3 
+    attempts, just ask the user for the value they want to use, providing the description of what the 
+    value looks like.
+    
+    * **Description:** The app ID we are looking for contains four colon (":") delimited parts: a version 
+      number (typically "1"), a project number, a platform type ("android", "ios", or "web"), 
+      and a sequence of hexadecimal characters. This can be found in the project settings in the Firebase Console
+      or in the appropriate google services file for the application type.
+    * For Android apps, you will typically find the app ID in a file called google-services.json under the
+      mobilesdk_app_id key. The file is most often located in the app directory that contains the src directory.
+    * For iOS apps, you will typically find the app ID in a property list file called GoogleService-Info.plist under the
+      GOOGLE_APP_ID key. The plist file is most often located in the main project directory.
+    * Sometimes developers will not check in the google services file because it is a shared or public
+      repository. If you can't find the file, the files may be included in the .gitignore. Check again for the file 
+      removing restrictions around looking for tracked files.
+    * Developers may have multiple google services files that map to different releases. In cases like this,
+      developers may create different directories to hold each like alpha/google-services.json or alpha/GoogleService-Info.plist.
+      In other cases, developers may change the suffix of the file to something like google-services-alpha.json or 
+      GoogleService-Alpha.plist. Look for as many google services files as you can find.
+    * Sometimes developers may include the codebase for both the Android app and the iOS app in the same repository.
+    * If there are multiple files or multiple app IDs in a single file, ask the user to choose one by providing 
+      a numbered list of all the package names.
+    * Again, if you have trouble finding the app ID, just ask the user for it.
 
 ## Next steps
 
@@ -70,6 +87,7 @@ Follow these steps to fetch issues and prioritize them.
         * <the issue subtitle>
         * **Description:** <a discription of the issue based on information from the tool response>
         * **Rationale:** <the reason this issue was prioritized in the way it was>
+  6. Ask the user if they would like to diagnose and fix any of the issues presented
 
 ### How to diagnose and fix issues
 
@@ -80,16 +98,18 @@ Follow these steps to diagnose and fix issues.
   3. Use the 'crashlytics_list_events' tool to get an example crash for this issue.
     3a. Apply the same filtering criteria that you used to find the issue, so that you find an appropriate event.
   4. Read the files that exist in the stack trace of the issue to understand the crash deeply.
-  5. Determine the root cause of the crash.
-  6. Write out a plan using the following criteria:
-    6a. Write out a description of the issue and including
+  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. Write out a plan for the most likely root cause using the following criteria:
+    8a. Write out a description of the issue and including
         * A brief description of the cause of the issue
-        * A determination of your level of confidence in the cause of the issue
+        * A determination of your level of confidence in the cause of the issue using your analysis.
         * A determination of which library is at fault, this codebase or a dependent library
         * A determination for how complex the fix will be
-    6b. The plan should include relevant files to change
-    6c. The plan should include a test plan to verify the fix
-    6d. Use the following format for the plan:
+    8b. The plan should include relevant files to change
+    8c. The plan should include a test plan for how the user might verify the fix
+    8d. Use the following format for the plan:
 
     ## Cause
     <A description of the root cause leading to the issue>
@@ -105,12 +125,15 @@ Follow these steps to diagnose and fix issues.
     <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
+    1. <Another possible root cause>
+    2. <Another possible root cause>
       
-  7. Present the plan to the user and get approval before making the change.
-  8. Fix the issue.
-    8a. Be mindful of API contracts and do not add fields to resources without a clear way to populate those fields
-    8b. 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. Ask the developer if they would like you to test the fix for them.
+  9. Present the plan to the user and get approval before making the change.
+  10. Only if they approve the plan, create a fix for the issue.
+    10a. Be mindful of API contracts and do not add fields to resources without a clear way to populate those fields
+    10b. 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.
 `.trim(),
         },
       },