| name | github-issue-resolve-with-subagent |
| description | GitHub issueを起点に「調査 → worktree作成 → 実装 → PR作成」を一気通貫で実行するSkill。実装はSubAgentに委譲し、commitとPR作成はgit-commit・github-pr-create skillに連結して実行する。「#N をsubagentで解決して」「実装をsubagentに任せてissueからPRまで」のような依頼に使う。 |
| allowed-tools | Task, Read, Write, Bash(gh:*), Bash(git:*), Bash(jq:*), Skill(git-commit), Skill(github-pr-create) |
GitHub Issue Resolve with SubAgent
issue番号を起点に、調査 → 実装 → PR作成までを順に進めるSkill。
メイン会話が担うのは調査・worktree作成・SubAgentへの引き継ぎ・結果検証・クリーンアップであり、実装(Phase 3)はSubAgent(Taskツール)に委譲し、commitとPR作成(Phase 4)はgit-commit skillとgithub-pr-create skillに連結する。
SubAgent機能が使えない環境では、SubAgentの作業をメイン会話内で同じ手順で順に実施する。
Skill toolが使えない環境では、連結先skillのSKILL.mdを直接読み込み、その手順に従って実行する。
Arguments
issue (必須): 解決対象のissue番号。先頭の # は省略可（例: 123 または #123）language (任意): issueコメント・PR本文の言語（例: ja, en）。デフォルトは ja--draft (任意): draft PRとして作成--dry-run (任意): 指定時はPhase 1の調査と実装方針の提示で停止し、worktree作成以降（Phase 2〜）は一切実行しない
GitHub操作は必ずgh CLIで行うこと。GitHub connector/pluginやMCPのGitHubツールは使用しない。
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 に進む。
Phase 2: worktreeの作成
- branch名を決定する:
- 形式:
<type>/<issue-number>-<slug>
<type>: issueのlabelやタイトルから推定する。Conventional Commitsで使われるものにする。（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: 実装
実装には以下のSubAgentを使用する。SubAgent同士は直接やり取りできないため、検証結果の受け取りと修正依頼はすべてメイン会話が仲介する。
modelの選択は、環境のグローバル指示 (CLAUDE.md, AGENTS.md等) にSubAgentのモデル指針があればそれを最優先する。指針が無ければメイン会話と同等のモデルをデフォルトとし、定型的・機械的な作業 (typo修正、単純な置換など) に限り、Implementation SubAgentにより軽量なモデルを指定してよい。Review SubAgentとDebug SubAgentにはImplementation SubAgentと同等以上のモデルを使う。model指定ができない環境では指定せずに起動する。
- Implementation SubAgent: 実装を行うSubAgent。実装に行き詰まった場合はメイン会話に相談し、必要に応じてSubAgentを再起動する。
- Review SubAgent: Implementation SubAgentが実装した変更を敵対的にコードレビューし、問題点をメイン会話に返すSubAgent。
- Debug SubAgent: テスト・linter・formatter・型チェックを実行し、さらに実装結果を実際に動かして期待動作を満たすか確認し、結果をメイン会話に返すSubAgent。
- Implementation SubAgentへの作業指示:
- worktreeの絶対パス。すべてのファイル操作・コマンド実行をこのパス配下で行うこと
- issueの番号・タイトル・本文・コメントの要約・base branch名と作業branch名
- Phase 1で決めた実装方針
- 受け入れ基準・期待動作
- リポジトリの既存コード規約（CLAUDE.md, AGENTS.md, README, 既存実装パターン）に従って実装する
- commit, push, PR作成は行わない
- 完了報告として「変更ファイル一覧・修正できなかった問題」を返す
- Review SubAgentとDebug SubAgentによる実装の検証: 両者を並列に起動し、Implementation SubAgentが返した変更ファイル一覧とworktreeパスを渡して、それぞれの役割の検証を行わせる
- メイン会話で結果を検証する:
- Review SubAgentとDebug SubAgentの結果を受け取り、問題がなければ「実装完了」としてPhase 4に進む。
- 問題があればImplementation SubAgentに修正を依頼し、再度Review SubAgentとDebug SubAgentで検証する。両SubAgentの指摘がなくなるまで、実装と検証を繰り返す。
Phase 4: commitとPR作成（git-commit / github-pr-create に連結）
メイン会話が、作業ディレクトリをworktreeの絶対パスに切り替えた上で、以下の順に連結先skillを起動する。
git-commit skillでcommitを作成する:
- 対象はPhase 3でworktree内に作られたすべての変更
github-pr-create skillでPRを作成する:
language（PRタイトル・本文の言語）と --draft の指定有無を引数として渡す- push・PRタイトルと本文の生成・PR作成の実行はすべて連結先skillが行う。手順をこちらで再実装しない
- メイン会話で結果を検証する:
- 作成されたPRのURLを
gh pr view <url> --json url,state で確認する
- PR本文に
Closes #<issue-number> が含まれるか確認し、無ければ gh pr edit <url> --body-file <修正した本文ファイル> で追記する
- 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の削除に失敗した、など）
