Build, debug & deploy with AI | Gemini CLI

# Gemini CLI Documentation # [Automation and triage processes](http://geminicli.com/docs/issue-and-pr-automation.md) This document provides a detailed overview of the automated processes we use to manage and triage issues and pull requests. Our goal is to provide prompt feedback and ensure that contributions are reviewed and integrated efficiently. Understanding this automation will help you as a contributor know what to expect and how to best interact with our repository bots. ## Guiding principle: Issues and pull requests First and foremost, almost every Pull Request (PR) should be linked to a corresponding Issue. The issue describes the "what" and the "why" (the bug or feature), while the PR is the "how" (the implementation). This separation helps us track work, prioritize features, and maintain clear historical context. Our automation is built around this principle. <!-- prettier-ignore --> > [!NOTE] > Issues tagged as "🔒Maintainers only" are reserved for project > maintainers. We will not accept pull requests related to these issues. --- ## Detailed automation workflows Here is a breakdown of the specific automation workflows that run in our repository. ### 1. When you open an issue: `Automated Issue Triage` This is the first bot you will interact with when you create an issue. Its job is to perform an initial analysis and apply the correct labels. - **Workflow File**: `.github/workflows/gemini-automated-issue-triage.yml` - **When it runs**: Immediately after an issue is created or reopened. - **What it does**: - It uses a Gemini model to analyze the issue's title and body against a detailed set of guidelines. - **Applies one `area/*` label**: Categorizes the issue into a functional area of the project (for example, `area/ux`, `area/models`, `area/platform`). - **Applies one `kind/*` label**: Identifies the type of issue (for example, `kind/bug`, `kind/enhancement`, `kind/question`). - **Applies one `priority/*` label**: Assig