Files
gemini-cli/tools/gemini-cli-bot
gemini-cli-robot 7faa50cbae # Improve Metric Accuracy for Issues, PRs, and Review Distribution
## 1. What the change is
This PR refactors the `open_issues.ts` and `open_prs.ts` metric scripts to use the GitHub GraphQL API's `totalCount` field instead of relying on the CLI's `gh issue list` command with a hardcoded limit. It also updates `review_distribution.ts` to include `COLLABORATOR` in the maintainer association check.

## 2. Why it is recommended
The current implementation of `open_issues.ts` and `open_prs.ts` used `--limit 1000`, which caused metrics to be capped at 1000 even when the actual backlog was much larger (~2400 issues). This provided a misleading view of repository health and the true scale of the backlog. Using GraphQL `totalCount` ensures accurate counts regardless of list size.

Additionally, `review_distribution.ts` was inconsistently excluding `COLLABORATOR` associations, which could lead to an inaccurate representation of review work distribution if many maintainers are designated as Collaborators. This led to a `review_distribution_variance` of 0 in recent runs.

## 3. Which metric or aspect of productivity is expected to be improved
- **open_issues**: Will now reflect the true total count (expected to jump from 1000 to ~2400).
- **open_prs**: Will reflect the true total count of open pull requests.
- **review_distribution_variance**: Will more accurately reflect how review work is shared among all maintainers (including collaborators).

## 4. By how much the metric is expected to improve
The `open_issues` metric is expected to increase by approximately **140%** (from 1000 to ~2400) once accurate data is collected. The `review_distribution_variance` is expected to become non-zero, providing a real baseline for monitoring reviewer workload balance.
2026-04-28 17:18:16 +00:00
..

Gemini CLI Bot (Cognitive Repository)

This directory contains the foundational architecture for the gemini-cli-bot, transforming the repository into a proactive, evolutionary system.

It implements a dual-layer approach to balance immediate responsiveness with long-term strategic optimization.

Layered Execution Model

1. System 1: The Pulse (Reflex Layer)

  • Purpose: High-frequency, deterministic maintenance.
  • Frequency: 30-minute cron (.github/workflows/gemini-cli-bot-pulse.yml).
  • Implementation: Pure TypeScript/JavaScript scripts.
  • Classification: Optionally utilizes Gemini CLI for high-confidence semantic classification (e.g., triage, labeling, sentiment) while preferring deterministic logic for equivalent tasks.
  • Phases:
    • Reflex Execution: Runs triage, routing, and automated maintenance scripts in reflexes/scripts/.
  • Output: Real-time action execution.

2. System 2: The Brain (Reasoning Layer)

  • Purpose: Strategic investigation, policy refinement, and proactive self-optimization.
  • Frequency: 24-hour cron (.github/workflows/gemini-cli-bot-brain.yml).
  • Implementation: Agentic Gemini CLI phases.
  • Phases:
    • Metrics Collection: Executes scripts in metrics/scripts/ to track repository health (Open issues, PR latency, throughput, etc.).
    • Phase 1: Reasoning (Metrics & Root-Cause Analysis): Analyzes time-series metric trends and repository state to identify bottlenecks or productivity gaps, tests hypotheses, and proposes script or configuration changes to improve repository health and maintainability.
    • Phase 2: Critique: A technical and logical validation layer that reviews proposed changes for robustness, actor-awareness, and anti-spam protocols.
    • Phase 3: Publish: Automatically promotes approved changes to Pull Requests, handles branch management, and responds to maintainer feedback.

Directory Structure

  • metrics/: Deterministic runner (index.ts) and scripts for tracking repository metrics via GitHub CLI.
  • reflexes/scripts/: Deterministic triage and routing scripts executed by the Pulse.
  • brain/: Prompt templates and logic for strategic root-cause analysis (Phase 1: metrics.md) and technical validation (Phase 2: critique.md).
  • history/: Persistent storage for time-series metrics artifacts.
  • lessons-learned.md: The bot's structured memory, containing the Task Ledger, Hypothesis Ledger, and Decision Log.

Usage

Local Metrics Collection

To manually collect repository metrics locally, run the following command from the workspace root:

npx tsx tools/gemini-cli-bot/metrics/index.ts

This will execute all scripts within metrics/scripts/ and output the results to tools/gemini-cli-bot/history/metrics-before.csv.

Development

When modifying the bot's logic:

  1. Reflexes: Add or update scripts in reflexes/scripts/.
  2. Reasoning: Update the prompts in brain/ to refine how the bot identifies bottlenecks.
  3. Critique: Update the prompts in critique/ to strengthen the validation of proposed changes.