Triage

---
name: triage
description: "GitHub Issue・PRのトリアージ。番号を渡すと、要望の要約・実現難易度・既存機能との重複チェック・対応判断を調査してレポートする。Issue/PRの番号が出てきたとき、トリアージ、優先度判断、対応判断と言われたときに使用する。"
---

# 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. **既存機能**: 要望を既に満たしている（または部分的に満たしている）機能がないか
3. **影響範囲**: 変更した場合に影響を受ける他の機能・モジュール
4. **プロトコル変更**: WebSocketプロトコルの変更が必要か（Bridge + Flutter双方の変更が必要になる）

#### PRの場合の追加調査

```bash
# 変更ファイル一覧
gh pr view <番号> --json files --jq '.files[].path'

# diff の取得
gh pr diff <番号>
```

- 変更内容がプロジェクトの規約に沿っているか
- テストが追加されているか
- セキュリティ上の懸念はないか（特にBridge Serverのファイルシステムアクセス周り）

### Phase 3: 難易度・工数の見積もり

調査結果をもとに、実装の難易度を判定する。

| 難易度 | 基準 | 工数目安 |
|--------|------|---------|
| **Low** | 単一ファイルの修正、UIの微調整、既存パターンの踏襲 | ~1時間 |
| **Medium** | 複数ファイルの変更、新しいWidgetの追加、既存APIの拡張 | 数時間 |
| **High** | プロトコル変更（Bridge + Flutter両方）、新機能のフルスタック実装 | 1日以上 |
| **Very High** | アーキテクチャ変更、外部依存の追加、セキュリティモデルの変更 | 数日以上 |

判定の根拠を具体的なファイルパスや変更箇所とともに示す。

### Phase 4: レポート出力

以下のフォーマットで会話内にレポートを出力する。

```markdown
## Triage Report: #<番号> <タイトル>

### 概要
[1-2文で要望の要約]

### 種別
[Bug / Feature / Prompt Request / Dependabot / 外部PR]

### プラットフォーム状況
[正式サポート / experimental / 未サポート]

### 推奨ラベル
- [例: `platform:windows`]
- [例: `status:experimental`]
- [例: `help wanted`]

### 既存機能チェック
- [既に実現済みの機能があれば記載]
- [部分的に実現されている場合はその旨と差分]
- [完全に新規の場合は「該当なし」]

### 実現難易度: [Low / Medium / High / Very High]

**根拠:**
- [変更が必要なファイル・モジュール]
- [プロトコル変更の有無]
- [影響範囲]

### 対応判断

| 観点 | 評価 |
|------|------|
| ユーザー価値 | [高/中/低] — [理由] |
| 実装コスト | [高/中/低] — [理由] |
| リスク | [高/中/低] — [理由] |
| 推奨 | [対応する / 保留 / 見送り] |

### 推奨アクション
- [具体的な次のステップ]
- [必要なら「PRなら受け入れ可能な条件」]
```

## 種別ごとの判断基準

### Bug Report
- 再現手順が明確か
- 影響範囲（全ユーザー vs 特定環境）
- ワークアラウンドの有無
- 上流（Claude Code / Codex）起因かccpocket起因か

#### experimental / 未サポート環境のBug Report

Windows や macOS版モバイルのように、メンテナが継続的に検証していない環境に関するIssueでは、次の基準を追加で適用する:

- メンテナが再現できない場合、Issue単体では着手保証しない
- 文字列ベースや純粋関数ベースで再現できる部分は、テスト追加前提なら受けやすい
- 実環境依存（spawn, shell, filesystem, GUI, OS API）の変更は、投稿者側の検証結果がほぼ必須
- 既存の正式サポート環境に影響しうる変更は慎重に扱う
- 対応判断は `対応する` だけでなく、`外部PR待ち` や `best-effort` と明記してよい

推奨ラベル例:

- `platform:windows`
- `platform:macos`
- `status:experimental`
- `status:unsupported`
- `needs-repro`
- `needs-test`
- `help wanted`

推奨アクション例:

- Issueには「未サポート/experimental 環境のため、メンテナ側では再現・検証できない」旨を明記
- 修正を歓迎する場合は「小さく閉じたPR」「自動テスト追加」「投稿者側の実機検証」を条件に案内
- 変更が危険なら、テスト付きPRでも保留または見送りと判断する

### Feature Request
- プロジェクトの方向性と合致するか
- 実装コストに対するユーザー価値
- 代替手段（既存機能で賄えないか）

### Prompt Request
- プロンプトの再現性
- 変更がコードベースの規約に沿うか
- そのまま適用可能か、調整が必要か

### Dependabot PR
- breaking changesの有無
- CHANGELOGの確認
- CI が通っているか

### 外部PR
- CONTRIBUTING.md の手順に沿っているか（Issue先行が推奨）
- テストの追加
- プロジェクト規約への準拠
- セキュリティレビューの必要性

#### experimental / 未サポート環境向けPRの受け入れ基準

以下を満たすPRは `best-effort` でレビュー・取り込み候補にしてよい:

- 変更範囲が限定的である
- 正式サポート環境への影響が小さい
- 自動テストを追加している
- 投稿者が対象環境での動作確認結果を書いている
- 失敗時の挙動やOS分岐が明示されている

逆に、以下に当てはまるPRは慎重に扱う:

- 実機検証なしでプロセス起動やパス処理を大きく変える
- サポート済み環境の起動経路まで巻き込む
- 再現条件や検証結果が曖昧
- テスト不能で回帰リスクが高い

## 外部PRの取り込み運用

外部PRはそのままマージするのではなく、内容を精査してメンテナが取り込む方針を取っている。
これは、PRの意図は良くても実装の一部を修正・調整したいケースが多いため。

### 取り込みフロー

1. **トリアージ**: 本スキルでPRの内容・品質・方向性を評価
2. **取り込み判断**: レポートの推奨アクションに基づいて判断
3. **実装**: PRの変更を参考に、メンテナが自分のブランチで実装する
   - そのまま使える部分はチェリーピックまたはコピー
   - 修正が必要な部分はメンテナ側で調整
   - プロジェクト規約（Conventional Commits、コード構造等）に合わせる
4. **クレジット**: コミットに `Co-authored-by` を付与して貢献者をクレジットする
   ```
   Co-authored-by: username <email>
   ```
   - PRのauthorのGitHub情報から取得: `gh api users/<username> --jq '.name, .email'`
   - メールが非公開の場合は `<id>+<username>@users.noreply.github.com` を使用
5. **PRクローズ**: 取り込み完了後、感謝のコメントとともにPRをクローズ
   - 何を取り込み、何を変更したかを説明する
   - Co-authored-by でクレジットした旨を伝える

### レポートへの反映

外部PRのトリアージレポートでは、推奨アクションに取り込み方針を含める:

```markdown
### 推奨アクション
- **取り込み方針**: [そのままマージ / 一部修正して取り込み / 参考にして再実装]
- **修正が必要な点**: [具体的な修正箇所]
- **Co-authored-by**: `Co-authored-by: Name <email>`
```

## 返信コメントの言語ルール

Issue/PRにコメントを投稿する際は、投稿者の言語に合わせて対応する:

- **英語で書かれている場合**: 英語のみで返信
- **英語以外の言語で書かれている場合**: 元の言語 + 英語の両方で返信

Issue/PRのタイトル・本文・コメントから投稿者の言語を判定する。
バイリンガル返信の場合は、元言語を先に書き、`---` で区切って英語を後に続ける。

**例: 日本語のIssueへの返信**
```
ご提案ありがとうございます！この機能は v1.5.0 で実装済みです。
セッション一覧画面で未読インジケーターが表示されます。

---

Thank you for the suggestion! This feature has been implemented in v1.5.0.
You'll see unread indicators on the session list screen.
```

## コメント投稿時の注意

- `gh issue comment` / `gh pr comment` で複数段落の本文を投稿する場合は、シェルクォートで本文を直接 `--body` に埋め込まない
- 改行・バッククォート・引用記号が崩れやすいため、**必ず一時ファイルを作って `--body-file` で渡す**
- 既存コメントを修正する場合も同様に、本文ファイルを作ってから API 経由で更新する
- 投稿後は `gh issue view` / `gh pr view` で最新コメントを取得し、改行や Markdown が崩れていないか確認する

例:

```bash
cat <<'EOF' >/tmp/comment.md
First paragraph.

- bullet 1
- bullet 2
EOF

gh pr comment <number> --body-file /tmp/comment.md
```