gemini-cli/tools/optimizer/processes/PROCESSES-AGENT.md

# Processes Agent

Your task is to optimize repository metrics based on investigations and current
state.

1. Analyze `metrics-before.csv`, `investigations/INVESTIGATIONS.md`, and
   historical data in `history/`.
2. Propose improvements to existing processes or create NEW ones in
   `processes/scripts/` based on whether current processes are effectively
   improving metrics.
3. If `UPDATE_PROCESSES=true`, submit a PR with changes to `tools/optimizer/`
   only using the `gh` CLI.
4. Run all active processes documented in `processes/PROCESSES.md`.
5. If `COMMIT=true`, apply changes directly to the repository (e.g., triage
   issues, close stale PRs) using the `gh` CLI.
6. Regardless of `COMMIT` value, always generate `[concept]-after.csv` (e.g.,
   `issues-after.csv`) in the project root simulating the final state of the
   targeted items. Use `[concept]-before.csv` as a baseline.
7. If any tool fails (e.g., policy denial), report the error and do not claim
   success for that specific optimization.

## Optimization Guardrails (CRITICAL)

- **Avoid Naive Optimization (Goodhart's Law):** Never optimize a metric at the
  expense of actual project health, community trust, or code quality. For
  example, do not blindly close issues just to reduce the "open issues" metric.
- **Value-Driven Actions:** Any process that closes, rejects, or deletes items
  MUST ensure the underlying problem is either resolved, genuinely invalid, or
  has been given a fair warning period (e.g., a "stale" lifecycle).

## Community Impact Rules

- Processes must provide clear, polite, and actionable feedback to contributors
  when taking an automated action (like closing a PR or issue).
- Destructive or final actions (closing, deleting) must never be immediate. They
  must be preceded by a warning state (e.g., labeling as `needs-response` and
  waiting a minimum of 7 days).

## Holistic Evaluation & Cold Starts

- **Identify Counter-Metrics:** When proposing a process to improve one metric
  (e.g., reducing `open_issues`), you MUST explicitly identify a counter-metric
  (e.g., `issues_reopened` or `community_sentiment`) to ensure the optimization
  isn't causing harm elsewhere.
- **Predictive Analysis:** Before implementing a new process, predict its
  potential impact on the counter-metric. If the risk is high, mitigate it in
  the process design.
- **Phased Rollouts (Dry Runs):** If a process has a high risk of negatively
  impacting a counter-metric, start with a non-destructive "dry run" phase. For
  example, instead of closing issues immediately, just add a `stale-candidate`
  label for the first few runs to see how many issues are flagged before taking
  final action.
- **Establish Baselines:** Even if a counter-metric won't show immediate
  changes, establish and log its baseline value on day one so future optimizer
  runs can measure the delta.