MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-05-14 13:53:02 -07:00
Code Issues Packages Projects Releases Wiki Activity

Issue fixer.

Browse Source
This commit is contained in:
Christian Gunderman
2026-05-12 13:38:18 -07:00
parent 2334e9b1c4
commit a11f347928
4 changed files with 57 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/gemini-cli-bot/.gemini/skills/issue-fixer/SKILL.md
+22
View File
@@ -0,0 +1,22 @@
# Skill: issue-fixer
## Objective
Proactively identify and implement surgical fixes for "small effort" issues and maintain existing PRs to reduce the repository backlog.
## High-Level Expectations
1. **Maintenance**: Prioritize driving existing `bot-fix` PRs to completion. Check for CI failures, merge conflicts, or requested changes.
2. **Discovery**: Find open issues labeled `effort/small`. Prioritize those with clear reproduction steps.
3. **Autonomous Implementation**: You are responsible for the entire fix: research, code changes, and test verification.
4. **Surgical Precision**: Changes must be minimal and strictly focused on the identified issue. Avoid "drive-by" refactoring.
5. **Local Verification**: You MUST run `npm run preflight` locally and iterate on any failures before finalizing your PR.
6. **Expert Mentions**: Identify the domain expert for the affected files and CC them in the PR description.
7. **Focused contributions**: limit your active PRs to ~10 at a time. Try to complete existing PRs before opening new ones. If a maintainer closes a PR, that may be an indication that they are rejecting the fix.
## Workflow
1. **Inventory & Drive PRs**: Use the `prs` skill to list all open PRs labeled `bot-fix`.
- If any require attention (CI failure, requested changes), focus your entire run on resolving ONE of them.
- Do NOT start a new issue fix if an existing PR needs work.
2. **Search for candidates**: If no PRs need attention, search for `effort/small` issues: `gh issue list --label "effort/small" --limit 10`.
3. **Select ONE issue** and implement a fix on a new branch.
4. **Verify** via `npm run preflight`.
5. **Use the `prs` skill** to stage changes and prepare the draft PR (label: `bot-fix`).
tools/gemini-cli-bot/.gemini/skills/metrics/SKILL.md
+1
View File
@@ -21,6 +21,7 @@ maintainability.
`tools/gemini-cli-bot/history/metrics-before-prev.csv` and the current run's
metrics.
- **Preservation Status**: The orchestrator will provide a System Directive telling you whether PR creation is enabled for this run. If enabled, your proposed changes may be automatically promoted to a Pull Request. In this case, you MUST activate the **'prs' skill** to generate a PR description and stage your changes. If PR creation is NOT enabled, you MUST NOT stage file changes or attempt to create a patch. Instead, simply report your findings.
- **Ownership Mandate**: Any PR generated by this skill MUST use the `bot-fix` label.
## Repo Policy Priorities
tools/gemini-cli-bot/.gemini/skills/prs/SKILL.md
+8 -2
View File
@@ -10,6 +10,12 @@ description: Expertise in managing the Git and GitHub Pull Request lifecycle, in
Standardize how the Gemini CLI Bot stages its changes, generates Pull Request
descriptions, and manages the lifecycle of both new and existing PRs.
## Mandatory PR Driver (Ownership)
You are the "owner" of all PRs labeled `bot-fix`. You MUST proactively drive them to completion:
1. **Inventory**: Use `gh pr list --label "bot-fix" --json number,title,headRefName,statusCheckRollup,comments` to find your active PRs.
2. **Proactive Maintenance**: If a `bot-fix` PR has failing status checks or new maintainer comments, you MUST prioritize fixing the CI or responding to the feedback before starting new work.
## Staging & Patch Preparation (MANDATORY)
If you are proposing fixes and PR creation is enabled (per the System Directive):
@@ -23,8 +29,8 @@ If you are proposing fixes and PR creation is enabled (per the System Directive)
2. **Generate PR Description**: Use the `write_file` tool to create
`pr-description.md`.
- **Title**: The very first line MUST be a concise, conventional title.
- **Body**: The rest should be the markdown body explaining the change, why
it is recommended, and the expected impact.
- **Body**: Explain the change and expected impact. You MUST identify the domain expert for the affected files and mention them (cc @<user>).
- **Labels**: Always apply the `bot-fix` label.
3. **Stage Fixes**: You MUST explicitly stage your fixes using the
`git add <files>` command.
4. **Internal File Protection (CRITICAL)**: You are STRICTLY FORBIDDEN from