triage

# Issue / PR トリアージ GitHub Issue または PR の番号を受け取り、コードベースを調査して対応判断に必要な情報をレポートする。 ## 使い方 ``` /triage 42 /triage #8 ``` ## トリアージ手順 ### Phase 1: 情報収集 #### 1-1. Issue/PR の取得 番号からIssueかPRかを自動判定する。 ```bash # まずIssueとして取得を試みる gh issue view <番号> --json number,title,body,labels,state,comments,author,createdAt # 404なら PRとして取得 gh pr view <番号> --json number,title,body,labels,state,files,comments,author,reviews,createdAt ``` #### 1-2. コメント・議論の確認 ```bash # Issueのコメント gh issue view <番号> --json comments --jq '.comments[].body' # PRのレビューコメント gh pr view <番号> --json reviews --jq '.reviews[].body' ``` #### 1-3. 種別の判定 IssueテンプレートやラベルからIssueの種別を判定する: | 種別 | 判定基準 | |------|---------| | Bug Report | `bug` ラベル、テンプレートのフィールド | | Feature Request | `enhancement` ラベル、Proposal セクション | | Prompt Request | テンプレートに「プロンプト」「AI tool」セクション | | Dependabot | author が `dependabot[bot]` | | 外部PR | authorがリポジトリオーナー以外 | #### 1-4. プラットフォームサポート状況の判定 Issue / PR が以下に該当するかを確認する: - **正式サポート環境**: メンテナが普段利用・検証できる環境 - **experimental / best-effort 環境**: 動作報告やPRは歓迎するが、メンテナが常時検証できない環境 - **未サポート環境**: 再現・修正・保守を約束しない環境 現時点では、少なくとも以下は `experimental / best-effort` または未サポート寄りとして扱う: - Bridge Server on Windows - Flutter mobile app on macOS この種のIssueでは、通常のバグ判定に加えて以下も見る: - メンテナがローカルで再現できるか - 自動テストで担保できる部分があるか - 投稿者側で動作検証済みか - OS依存分岐や外部プロセス起動など、実機検証なしでは危険な変更か ### Phase 2: コードベース調査 要望の内容に基づいて、関連するコードを調査する。 Explore サブエージェントを活用して並列に調査を進める。 #### 調査観点 1. **関連コード**: 変更が必要になりそうなファイル・モジュール 2. **既存機能**: 要望を既に満たしている（または部分的に満たしている...