Claude CodeにGitHub Issueの”判断”を任せる──トリアージ自動化と委譲設計の実践ガイド

---
name: triage-issues
description: GitHubのopen issueをトリアージする（close/PR/保留の3択判定）
allowed-tools: Bash
---

以下の手順でopen issueをトリアージしてください。

## 判定基準（この順序で確認する）

### closeしてよいIssue
以下をすべて満たす場合、issueを閉じる：
- 関連するPRがすでにマージされている（gh pr list --search で確認）
- コードを確認して問題が解消されている（gh api / git grep で確認）
- issueのコメントで「解決した」旨の報告がある

### PRを作れるIssue
以下をすべて満たす場合、git worktreeでブランチを作ってPRを出す：
- 設定値の変更、文言修正、軽微なバグ修正レベルの変更
- 影響範囲が明確で、テストで検証できる
- 別リポジトリに同内容のPRがまだ存在しない

### 保留にするIssue（コメントだけ残す）
以下のどれかに該当する場合、コメントだけ残して撤退する：
- 仕様の解釈が必要、または複数の解釈が可能
- 影響範囲が不明確
- 設計判断が必要
- 上記判定基準のどれにも当てはまらない（迷ったら保留）

## 処理フロー

```
for each open issue:
  1. gh issue view <id> --comments でissue全体を確認
  2. gh pr list --search "<issue title keywords>" で関連PRを検索
  3. 上記判定基準を適用
  4. 対応を実施:
     - close: gh issue close <id> --comment "<理由>"
     - PR: git worktreeでブランチ作成 → 修正 → gh pr create
     - 保留: gh issue comment <id> --body "/triage-issues: <判断理由・必要な情報>"
  5. 次のissueへ
```

## 安全装置
- 一度コメントに "/triage-issues:" を含むissueは再処理しない（無限ループ防止）
- PRを作るときは必ずgit worktreeを使い、現在のブランチを汚さない
- 同内容のPRが別リポジトリに存在する場合はPR作成しない
- issueの数が多い場合は最初の10件だけ処理して結果を報告する

# issue一覧（open状態）
gh issue list --state open --limit 50

# issueの詳細＋コメント
gh issue view 123 --comments

# 関連PRを検索（タイトルキーワードで）
gh pr list --search "fix login error" --state merged

# 同じissueに対するPRが別リポジトリにないか確認
gh pr list --repo owner/other-repo --search "closes #123"

# issueのコードを確認
gh api repos/owner/repo/contents/src/auth.ts | base64 -d

# 類似issueを検索
gh issue list --search "login error" --state closed --limit 10

# 新しいworktreeを作成（別ディレクトリに新ブランチが作られる）
git worktree add ../fix-issue-123 -b fix/issue-123

# worktree内で作業
cd ../fix-issue-123
# ... 修正を加える ...

# テスト
npm test

# コミット
git add -A
git commit -m "fix: issue #123 - ログインエラーの修正"

# PR作成（issueに紐付ける）
gh pr create   --title "fix: ログインエラーを修正 #123"   --body "Fixes #123"   --base main

# worktreeの掃除
cd ../your-main-repo
git worktree remove ../fix-issue-123

# NG例 - 何が「対応済み」かを定義していない
「対応済みのissueを閉じてください」

# NG例 - 「小さな修正」の定義がない
「小さな修正なら自動でPRを出してください」

# OK例 - 事実確認できる条件に分解する
"""
以下をすべて満たす場合のみcloseする：
1. gh pr list --search で関連PRがマージ済みと確認できる
2. git grep / ファイル確認で問題箇所がコードに存在しない
3. issue本文またはコメントに「解決した」「動いた」などの確認がある
→ 上記3つを確認できない場合はcloseしない
"""

# OK例 - 「小さな修正」を具体的に定義する
"""
以下のどれかに該当する場合のみPRを作る：
- 設定ファイルの値変更（変更量が5行以内）
- エラーメッセージ・ログ文言の修正
- コメント・ドキュメントの誤字修正
→ ロジック変更が必要な場合はPRを作らない
"""

# パターン1: 迷ったら保留（最も重要）
"""
上記のいずれかの判断基準に当てはまらない場合、
またはどちらか迷う場合は、issueにコメントを残して撤退する。
勝手に判断しない。
"""

# パターン2: 影響範囲が不明なら止まる
"""
修正の影響が1ファイル・1関数を超える可能性がある場合は、
PRを作らずにissueに調査結果をコメントして保留にする。
"""

# パターン3: テストが通らなければ止まる
"""
修正後にテストを実行し、失敗した場合は修正を取り消して保留にする。
「多分大丈夫」で進めない。
"""

# パターン4: 同内容の作業が既存する場合は止まる
"""
別リポジトリに同内容のPRや同じissueが存在する場合、
重複作業を避けるためPR作成を中止してリンクをコメントに残す。
"""

# .claude/settings.json のStop hookで通知を送る
{
  "hooks": {
    "Stop": [{
      "type": "command",
      "command": "bash -c 'INPUT=$(cat); RESULT=$(echo "$INPUT" | jq -r ".last_assistant_message"); curl -s -X POST $SLACK_WEBHOOK -H Content-Type:application/json -d "{\"text\":\"[triage-issues] $RESULT\"}"'"
    }]
  }
}

# triage-issues コマンドの最後に追加
以下の形式でログを出力してください：

## 処理結果サマリー
- 処理したissue数: X件
- closeしたissue: #123, #456 （理由: 関連PRがマージ済み）
- PRを作成したissue: #789 （PR: #101）
- 保留にしたissue: #234（理由: 仕様の確認が必要）, #567（理由: 影響範囲が不明）

ログファイル: .claude/triage-log-YYYYMMDD.md に保存してください