name	derive-subissues
description	GitHub Issueを親Issueとしてタスク分解し、子Issueを作成する。
argument-hint	<親Issue番号>
disable-model-invocation	true
allowed-tools	AskUserQuestion, Agent, Read, Glob, Grep, Bash(gh issue view:), Bash(gh repo view:), Bash(gh issue create:), Bash(gh issue edit:)

親Issueからのタスク分解ワークフロー

以下を並列で実行する:

gh issue view $ARGUMENTS --json number,title,body,labels,comments,url で親Issueの内容を取得
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' でデフォルトブランチ名を取得

親Issueの内容を踏まえ、Agentツール（subagent_type: Explore）を使用してコードベースを調査する。調査の目的は、タスク分解の粒度と内容を適切に判断するためである。

親Issueの内容やコードベースの調査結果をもとに、実装方針や分解の方向性について不明点・疑問点がある場合は、AskUserQuestionツールで開発者に確認する。

確認すべき例:

不明点がない場合でも、分解の方向性をユーザーに簡潔に伝え、認識が合っているか確認すること。

親Issueの要件を実装可能な適切な単位に分解する。分解の指針:

各タスクは独立して実装・レビュー・マージできる粒度にする
タスク間の依存関係がある場合は明記する
各タスクには明確な完了条件を含める
作成予定の子Issue同士を参照する必要がある場合、暫定IDとして#1のようなGitHub Issue参照形式を使わない。意図しない既存Issueへのリンクを避けるため、作成前の参照はTASK-Aや<作成後にIssue番号を反映>のようなリンク化されない表記にする

分解したタスク一覧を以下の形式でユーザーに提示する:

親Issue: #<番号> <タイトル>

子Issue一覧:

1. <タイトル1>
   内容: <概要>
   ラベル: <ラベル>

2. <タイトル2>
   内容: <概要>
   ラベル: <ラベル>

...

AskUserQuestionツールで以下を確認:

ユーザーから修正の指示があった場合は内容を修正し、再度確認を求めること。 承認を得るまで子Issueは作成しないこと。

ユーザーの承認を得たら、子Issueを1件ずつ作成する。

各子Issueを作成する直前に、実際に登録する内容を以下の形式でユーザーに提示する:

作成予定の子Issue <現在番号>/<総数>
タイトル: <タイトル>
ラベル: <ラベル>

本文:
<gh issue createに渡す本文全文>

AskUserQuestionツールで、その子Issueを実際に登録してよいかを1件ずつ確認する。

各子Issueの本文には以下を含めること:

作成する子Issueの本文内で、他の作成予定の子Issueを参照する場合:

作成前・確認時点では#1のようなGitHub Issue参照形式を使わない
参照先Issueがすでに作成済みの場合のみ、実際のIssue番号（例: #123）またはURLで参照する
参照先Issueが未作成の場合は、いったんリンク化されない表記（例: TASK-A、<作成後にIssue番号を反映>）で作成し、参照先Issueの作成後に gh issue edit で本文を更新して実際のIssue番号に置き換える
Issue番号の置き換えが必要なIssueは記録しておき、すべての子Issue作成後に漏れなく更新する

各子Issueを作成したら、GitHub CLIで親Issueと関連付ける。子Issueは gh issue create の戻り値URLを指定し、親Issueは手順1で取得した親Issue番号または $ARGUMENTS を指定する。

gh issue edit '<子IssueのURL>' --parent '<親Issue番号またはURL>'

以下をユーザーに報告する: