/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かを自動判定する。

# まず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. コメント・議論の確認

# 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の場合の追加調査

# 変更ファイル一覧
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: レポート出力

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

## 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のトリアージレポートでは、推奨アクションに取り込み方針を含める:

### 推奨アクション
- **取り込み方針**: [そのままマージ / 一部修正して取り込み / 参考にして再実装]
- **修正が必要な点**: [具体的な修正箇所]
- **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 が崩れていないか確認する

例:

cat <<'EOF' >/tmp/comment.md
First