Menü
GitHub Issueを親Issueとしてタスク分解し、子Issueを作成する。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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:*) |
以下を並列で実行する:
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の要件を実装可能な適切な単位に分解する。分解の指針:
#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件ずつ確認する。
gh issue create で作成する各子Issueの本文には以下を含めること:
作成する子Issueの本文内で、他の作成予定の子Issueを参照する場合:
#1のようなGitHub Issue参照形式を使わない#123）またはURLで参照するTASK-A、<作成後にIssue番号を反映>）で作成し、参照先Issueの作成後に gh issue edit で本文を更新して実際のIssue番号に置き換える各子Issueを作成したら、GitHub CLIで親Issueと関連付ける。
子Issueは gh issue create の戻り値URLを指定し、親Issueは手順1で取得した親Issue番号または $ARGUMENTS を指定する。
gh issue edit '<子IssueのURL>' --parent '<親Issue番号またはURL>'
以下をユーザーに報告する:
GitHub Issueに対して現在のブランチのローカル実装をレビューする
変数や関数の命名候補を複数提案し、それぞれのニュアンスを解説する。
piコーディングエージェントのextensionを作成する
与えられた指示に対して、コードベースを探索してリポジトリ構造と関連箇所を把握し、開発者と一問一答で実装方針・設計・タスク分解を固める。実装前の壁打ちやPlanモード的な相談に使う。
TDD（テスト駆動開発）のRed-Green-Refactorサイクルに従って機能を実装する
GitHub Issue番号と任意の分岐元ブランチ名を受け取り、実装方針策定・ブランチ作成・TDD実装・コードレビュー修正ループを一連で実行する