feat(commands): Add new commands for docs, git, and PR review (#7853)

.gemini/commands/find-docs.toml

@@ -0,0 +1,30 @@
+description = "Find relevant documentation and output GitHub URLs."
+
+prompt = """
+## Mission: Find Relevant Documentation
+
+Your task is to find documentation files relevant to the user's question within the current git repository and provide a list of GitHub URLs to view them.
+
+### Workflow:
+
+1.  **Identify Repository Details**:
+    *   You may use shell commands like `git` or `gh` to get the remote URL of the repository.
+    *   From the remote URL, parse and construct the base GitHub URL (e.g., `https://github.com/user/repo`). You must handle both HTTPS (`https://github.com/user/repo.git`) and SSH (`git@github.com:user/repo.git`) formats.
+    *   Determine the default branch name. You can assume `main` for this purpose, as it is the most common.
+
+2.  **Search for Documentation**:
+    *   First, perform a targeted search across the repository for documentation files (e.g., `.md`, `.mdx`) that seem directly related to the user's question.
+    *   If this initial search yields no relevant results, and a `docs/` directory exists, read the content of all files within the `docs/` directory to find relevant information.
+    *   If you still can't find a direct match, broaden your search to include related concepts and synonyms of the keywords in the user's question.
+    *   For each file you identify as potentially relevant, read its content to confirm it addresses the user's query.
+
+3.  **Construct and Output URLs**:
+    *   For each file you identify as relevant, construct the full GitHub URL by combining the base URL, branch, and file path. **Do not use shell commands for this step.**
+    *   The URL format should be: `{BASE_GITHUB_URL}/blob/{BRANCH_NAME}/{PATH_TO_FILE_FROM_REPO_ROOT}`.
+    *   Present the final list to the user as a markdown list. Each item in the list should be the URL to the document, followed by a short summary of its content.
+    *   If, after all search attempts, you cannot find any relevant documentation, ask the user clarifying questions to better understand their needs. Do not return any URLs in this case.
+
+### QUESTION:
+
+{{args}}
+"""

.gemini/commands/github/cleanup-back-to-main.toml

@@ -0,0 +1,13 @@
+description = "Go back to main and clean up the branch."
+
+prompt = """
+I'm done with the work on this branch, and I'm ready to go back to main and clean up.
+
+Here is the workflow I'd like you to follow:
+
+1.  **Get Current Branch:** First, I need you to get the name of the current branch and save it.
+2.  **Branch Check:** Check if the current branch is `main`. If it is, I need you to stop and let me know.
+3.  **Go to Main:** Next, I need you to checkout the main branch.
+4.  **Pull Latest:** Once you are on the main branch, I need you to pull down the latest changes to make sure I'm up to date.
+5.  **Branch Cleanup:** Finally, I need you to delete the branch that you noted in the first step.
+"""

.gemini/commands/oncall/pr-review.toml

@@ -0,0 +1,47 @@
+description = "Review a specific pull request"
+
+prompt = """
+## Mission: Comprehensive Pull Request Review
+
+Today, our mission is to meticulously review community pull requests (PRs) for this project. We will proceed systematically, evaluating each candidate PR for its quality, adherence to standards, and readiness for merging.
+
+### Workflow:
+
+1.  **PR Preparation & Initial Assessment**:
+    * **You will check out the designated PR {{args}}** into a temporary branch.
+    * **Execute the preflight checks (`npm run preflight`)**. This includes building, linting, and running all unit tests.
+    * Analyze the output of these preflight checks, noting any failures, warnings, or linting issues.
+
+2.  **In-Depth Code Review**:
+    * **Your primary role is to conduct a thorough and in-depth code review** of the changes introduced in the PR. Focus your analysis on the following criteria:
+        * **Correctness**: Does the code achieve its stated purpose without bugs or logical errors?
+        * **Maintainability**: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.
+        * **Readability**: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines?
+        * **Efficiency**: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?
+        * **Security**: Are there any potential security vulnerabilities or insecure coding practices?
+        * **Edge Cases and Error Handling**: Does the code appropriately handle edge cases and potential errors?
+        * **Testability**: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.
+    * Based on your analysis, you will determine if the PR is **safe to merge**.
+
+3.  **Reviewing Previous Feedback**:
+    * **Access and examine the PR's history** to identify any **outstanding requests or unresolved comments from previous reviews**. Incorporate these into your current review and explicitly highlight if they have been adequately addressed in the current state of the PR.
+
+4.  **Decision and Output Generation**:
+    * **If the PR is deemed safe to merge** (after your comprehensive review and considering previous feedback):
+        * Draft a **friendly, concise, and professional approval message**.
+        * **The approval message should:**
+            * Clearly state that the PR is approved.
+            * Briefly acknowledge the quality or value of the contribution (e.g., "Great work on X feature!" or "Appreciate the fix for Y issue!").
+            * **Do NOT mention the preflight checks or unit testing**, as these are internal processes.
+            * Be suitable for public display on GitHub.
+    * **If the PR is NOT safe to merge**:
+        * Provide a **clear, constructive, and detailed summary of the issues found**.
+        * Suggest **specific actionable changes** required for the PR to become merge-ready.
+        * Ensure the feedback is professional and encourages the contributor.
+
+### Post-PR Action:
+
+* After providing your review and decision for the current PR, I will wait for you to perform any manual testing you wish to do. Please let me know when you are finished.
+* Once you have confirmed that you are done, I will switch to the `main` branch, clean up the local branch, and perform a pull to ensure we are synchronized with the latest upstream changes for the next review.
+
+"""

.gitignore

@@ -3,8 +3,14 @@
 .env~
 
 # gemini-cli settings
-.gemini/
-!gemini/config.yaml
+# We want to keep the .gemini in the root of the repo and ignore any .gemini
+# in subdirectories. In our root .gemini we want to allow for version control
+# for subcommands.
+**/.gemini/
+!/.gemini/
+.gemini/*
+!.gemini/config.yaml
+!.gemini/commands/
 
 # Note: .gemini-clipboard/ is NOT in gitignore so Gemini can access pasted images