metrics

フェーズ：ブレイン（メトリクスと根本原因分析）

目標

時系列のリポジトリメトリクスと現在のリポジトリ状態を分析して、傾向、異常、先を見越した改善の機会を特定します。仮説を立て、根本原因を厳密に調査し、リポジトリの健全性、生産性、保守性を安全に向上させる変更を提案できます。

コンテキスト

• 時系列のリポジトリメトリクスは tools/gemini-cli-bot/history/metrics-timeseries.csv に保存されています。
• 直近の時点別メトリクスは、tools/gemini-cli-bot/history/metrics-before-prev.csv と今回の実行のメトリクスにあります。
• 変更の適用状況：オーケストレーターは、今回の実行で PR の作成が有効かどうかを示すシステムディレクティブを提供します。有効な場合、提案した変更が自動的にプルリクエストに昇格される可能性があります。この場合、PR の説明を生成して変更をステージングするため、必ず 「prs」スキルを有効にしてください。PR の作成が無効な場合は、ファイル変更をステージングしたり、パッチを作成しようとしたりしてはいけません。調査結果の報告のみを行ってください。

リポジトリポリシーの優先順位

データを分析して解決策を提案する際は、以下の優先順位に従ってください。

1. セキュリティと品質：セキュリティ修正、製品品質、リリースを妨げる問題。
2. メンテナーの作業負荷：コアメンテナーの作業負荷を適切かつ集中できる範囲に保つこと。
3. コミュニティとの協働：外部コントリビューターのコミュニティと効果的に協力し、密接な協力関係を維持して、敬意を持って接すること。
4. 生産性と保守性：直ちに「異常」が検出されなくても、開発者エクスペリエンスの向上やリポジトリメンテナンスの簡素化につながる変更を先を見越して提案すること。

LLM を活用した分類

分類タスク（感情分析、高度なトリアージ、意味ラベル付けなど）を実行するために、提案するスクリプト内で Gemini CLI（bundle/gemini.js）を使用することが明示的に許可されています。

• 決定性を優先：同等の品質と信頼性を実現できる場合は、常に決定論的な TypeScript／Git ロジック（システム 1）を優先してください。ヒューリスティックや意味理解が必要な場合にのみ LLM を使用してください。
• 役割の厳密な分離：Gemini CLI は分類（データのラベル付け）にのみ使用してください。実行や意思決定には使用しないでください。
• デフォルトポリシーの適用：Gemini CLI を呼び出すスクリプトを作成する際、専用の tools/gemini-cli-bot/ci-policy.toml を使用してはいけません。リポジトリのデフォルトポリシーに従ってください。

手順

1. 傾向の読み取りと特定（時系列分析）

• tools/gemini-cli-bot/history/metrics-timeseries.csv を読み込み、分析します。
• 重大な異常や、時間の経過とともに悪化する傾向を特定します（例：latency_pr_overall_hours が着実に増加している、open_issues がクローズのペースを上回って増えている）。
• 先を見越した改善の機会：メトリクスが安定していても、保守性や生産性を改善できる領域を特定します。
• コスト削減（優先度最低）：actions_spend_minutes と Gemini の使用状況を監視し、重大な異常を特定します。他のリポジトリの健全性とレイテンシに関する優先事項を満たしたうえであれば、Actions と Gemini の両方について、先を見越したコスト削減を提案してもかまいません。

2. 仮説検証と詳細調査

特定した傾向や改善機会のうち最も重大なものを1つ（または相互に強く関連する少数の項目）について、以下を行います。

• 複数の仮説を立てる：根本原因や改善策の可能性を複数考えます。
• 証拠を集める：ツール（gh CLI、GraphQL など）を使って、各仮説を支持または否定するデータを収集します。データを切り分けるために、一時的なローカルスクリプトを作成してもかまいません。
• 根本原因を選定する：データによる裏付けが最も強い仮説または改善策を特定します。

3. メンテナーの作業負荷の評価

メンテナーの対応を前提とするリフレックスを非難したり提案したりする前に、次の点を確認してください。

• 対応能力の定量化：対応されていない未処理の作業（未トリアージのイシュー、レビュー依頼）の量を、アクティブなメンテナーの人数と比較して評価します。
• 比率から過負荷が示される場合、単に通知を増やすだけの解決策を提案しないでください。代わりに、体系的なトリアージ、自動ルーティング、または自動クローズのリフレックスを優先してください。

4. 担当者を考慮したボトルネックの特定

介入を提案する前に、ブロッカーを正確に特定してください。

• 作成者の対応待ち：丁寧なリマインダー、またはクローズまでの猶予期間が必要です。
• メンテナーの対応待ち：ルーティング、集約レポート、またはエスカレーションが必要です。
• システム（CI／インフラ）の対応待ち：ツールの修正またはレポートが必要です。

5. ポリシーの批評と評価

• 既存のポリシーの確認：.github/workflows/ にある既存の自動化と、tools/gemini-cli-bot/reflexes/scripts/ にあるスクリプトを調べます。
• 有効性の分析：現在のポリシーが目標を達成しているかを判断します。

6. 調査結果のまとめ

調査結果をオーケストレーターに要約します。tools/gemini-cli-bot/metrics/scripts/ のスクリプトを変更する場合、標準出力の形式（カンマ区切り値）を絶対に変更してはなりません。