| name | github-issue-resolve |
| description | GitHub issueを起点に「調査 → worktree作成 → 実装 → PR作成」を一気通貫で実行するSkill。「#N を解決して」「issueから実装してPRまで」のような複合依頼に使う。 |
| allowed-tools | Skill, Bash(gh:*), Bash(git:*), Bash(jq:*), Bash(mkdir:*), Bash(rm:*), Bash(cd:*), Bash(ls:*), Bash(cat:*), Bash(mktemp:*), Read, Write, Edit |
GitHub Issue Resolve
GitHub操作は必ずgh CLIで行うこと。GitHub connector/pluginやMCPのGitHubツールは使用しない。
issue番号を起点に、調査 → 実装 → PR作成までを順に進めるSkill。
個々の作業は既存Skillへ委譲する。
本Skillが担うのはフェーズ間の判断と引き継ぎだけであり、PR作成手順やcommit手順を独自に再実装しない。
- PR本文生成・関連Issue検出・base branch決定・push処理 →
github-pr-create
- commitメッセージ生成・commit分割 →
git-commit
- 既存PRの扱い →
github-pr-create
Arguments
issue (必須): 解決対象のissue番号。先頭の # は省略可（例: 123 または #123）language (任意): issueコメント・PR本文の言語（例: ja, en）。デフォルトは ja。github-pr-create にもそのまま転送する--draft (任意): draft PRとして作成（github-pr-create に転送）--dry-run (任意): 指定時はPhase 1の調査と実装方針の提示で停止し、worktree作成以降（Phase 2〜）は一切実行しない
Task
Phase 1: 事前調査と分析
- 以下を取得して状況を確認する:
- リポジトリ情報:
gh repo view --json defaultBranchRef,nameWithOwner --jq '{default: .defaultBranchRef.name, repo: .nameWithOwner}'
- 対象issue:
gh issue view <number> --json number,title,state,body,labels,assignees,comments,url
- 現在のbranch:
git branch --show-current
- 既存worktree:
git worktree list --porcelain
- issueが
state: CLOSED の場合は中止し、ユーザーに「issue #N は既にclosedです」と通知する。
- 取得したissue本文・コメント・labelを読み、実装方針を決める:
- 受け入れ基準・期待動作・既存コメントの合意事項を抽出する
- 仕様が曖昧な場合は、コードベースを探索し、推奨の方針で判断する
- どうしても実装不能な情報が欠けている場合のみ中止し、欠落情報を具体的に伝え、ユーザーに質問する
- 実装方針は簡潔にユーザーへ提示する。確認は取らず Phase 2 に進む。
--dry-run が指定された場合はここで停止し、Phase 2以降は実行しない。
Phase 2: worktreeの作成
- branch名を決定する:
- 形式:
<type>/<issue-number>-<slug>
<type>: issueのlabelやタイトルから推定（fix, feat, docs, chore, refactor 等。判別不能なら feat）<slug>: issueタイトルからkebab-caseで生成（英数字とハイフンのみ、40文字以内）
- 例:
feat/123-add-oauth-login, fix/456-handle-empty-response
- 既に同名のlocal branchがある場合は末尾に
-2, -3 を付けて衝突を避ける
- worktreeのパスを決定する:
- 形式:
<repo-root>/.tmp/<repo-name>-worktrees/<branch-name>
- 既存worktreeと衝突する場合は末尾に
-2, -3 を付けて衝突を避ける
- worktree作成:
git worktree add -b <branch-name> <worktree-path> <base-branch><base-branch>は最新のdefault branch- 同じ path の worktree が存在し、未commit変更がある場合は中止する。clean な場合のみ作り直してよい。
- 作成失敗時は中止し、エラー内容をユーザーに伝える
- 作成したworktree情報を記録する（中止時のクリーンアップで使う）:
- branch名
- worktreeパス
- base branch名
Phase 3: 実装
- 作業ディレクトリをworktreeに切り替える:
- 以降の
git / gh / ファイル操作は worktreeパス配下で実行する
cd <worktree-path> をBashで実行するか、ファイル操作の絶対パスを worktreeパス起点で組み立てる
- issueの内容に応じて実装する:
- issue本文・コメントから受け入れ基準・期待動作を抽出
- リポジトリの既存コード規約（CLAUDE.md, AGENTS.md, README, 既存実装パターン）に従う
- 必要なファイルを Read → Edit / Write で修正
- このフェーズはSkill側でロジックを規定しない。issueの内容に応じて適切に判断する
- 品質チェック:
- リポジトリにテスト・linter・formatter・型チェックの設定がある場合は実行する（例:
pytest, npm test, ruff check, eslint, tsc --noEmit）
- リポジトリのCLAUDE.md / AGENTS.mdに指定がある場合はそちらを優先する
- 失敗した場合は修正してから次に進む。修正困難な場合はユーザーに相談し、ユーザー判断で Phase 4 に進むか中止するかを決める
- commit:
git-commit Skillで委譲してcommitする（Conventional Commits準拠のメッセージを自動生成）- 複数の論理的変更がある場合は複数commitに分けるよう
git-commit Skillに任せる
Phase 4: PR作成（github-pr-create に委譲）
- Skillツールで
github-pr-create Skillを起動する（Skillツールが使えない環境では、委譲先skillのSKILL.mdを直接読み込み、その手順に従って実行する）
- 受け取った引数を以下のように転送する:
language: そのまま転送--draft: 指定されていれば転送
- PR作成に失敗した場合はworktreeをクリーンアップせず（手動修正の余地を残す）、ユーザーにエラーを伝えて中止する
Phase 5: 結果の表示
以下を簡潔にまとめて出力する:
- Issue: #N タイトル / URL
- Branch: 作成したbranch名
- PR: 作成したPRのURL
- 変更概要: ファイル数、追加/削除行数（
git diff --stat <base>..HEAD の結果）
Phase 6: worktreeクリーンアップ
実装完了後とPhase 2-5の途中でエラーが出たりユーザーが中止を選んだ場合の両方で、以下のクリーンアップ処理を行う:
git worktree remove --force <worktree-path>git branch -D <branch-name>（ローカルbranchも削除する）- クリーンアップに失敗した場合はユーザーに警告する（例: worktreeは削除できたがbranchの削除に失敗した、など）
