creating-work-item-children

作業項目の子項目を作成する

あなたは Phase 4 の子作業項目コーディネーターです。プラットフォームを検出し、有効なプレイブックに従ってワークフローキーを導き出し、変更承認の境界を守り、child-work-item-creator に処理を委任し、その構造化サマリーのみを伝えてください。

このスキルは、実際のリモートトラッカーとローカルのワークフロープランを変更します。プランの解析、プラットフォームの読み取りと書き込み、冪等な調整、プランファイルの編集、検証はクリエイターが担当します。生のプラットフォームペイロード、プラン全体の内容、コマンドの出力をコーディネーターのコンテキストに含めないでください。

プラットフォームの検出

正規の親 URL からプラットフォームを検出し、プラットフォーム固有の判断にはすべて、該当するプレイブックを読み込んでください。

入力シグナル	プラットフォーム	プレイブック
ISSUE_URL が https://<host>/<owner>/<repo>/issues/<N> に一致する（GitHub Enterprise を含む）	github	./references/github-playbook.md
JIRA_URL が https://<workspace>.atlassian.net/browse/<KEY> に一致する	jira	./references/jira-playbook.md

いずれのシグナルも存在しない場合、または参照先が曖昧な場合は、処理の委任や変更を行う前に、焦点を絞った確認質問を1つしてください。ISSUE_SLUG を分割して GitHub のオーナー名、リポジトリ名、番号を導き出さないでください。オーナー名とリポジトリ名にはハイフンが含まれる場合があります。Phase 4 の GitHub の実行には、完全な ISSUE_URL が必要です。

共通のワークフローキーは <KEY> です。確立された別名 TICKET_KEY で渡してください。Jira ではチケットキーを使用し、GitHub ではプレイブックから導き出した ISSUE_SLUG の値を使用します。

入力

入力	必須	例
有効なプレイブックで指定された正規の親 URL	はい	ISSUE_URL=https://github.com/acme/app/issues/42 または JIRA_URL=https://workspace.atlassian.net/browse/PROJ-123
APPROVED_MUTATION_SCOPE	通常のオーケストレーション実行では必須。直接呼び出し時は一度だけ確認できます	Tasks 1-3 の不足している子作業項目を作成し、docs/<KEY>-tasks.md を更新する

承認には、有効なプレイブックで定められた正確なリモート書き込みモデルと、ローカルファイル docs/<KEY>-tasks.md のみを含める必要があります。直接呼び出しで承認の内容が不明確な場合は、一度だけ確認してください。承認がない場合、または承認が拒否された場合は、有効なプレイブックのブロック時サマリー全文を Validation: NOT_RUN とともに返してください。何も作成または編集しないでください。

変更範囲の境界

APPROVED_MUTATION_SCOPE から今回の実行における変更範囲を導き出し、その内容を変更せずに作成者へ渡します。

• 変更を行う前に、親項目、計画、および既存の子項目との関連付けを確認します。
• 検証済みの関連付けがすでに満たされている場合は、成功として再利用します。課題、サブタスク、親リンク、コメント、ラベル、タスクリスト項目、またはトランジションを重複して作成しないでください。
• リモートへの書き込みは、docs/<KEY>-tasks.md から解析されたタスクと特定された親項目に対する、アクティブなプレイブックで承認された Phase 4 のアクションに限定されます。
• 変更できるローカルファイルは docs/<KEY>-tasks.md のみです。
• 修復サイクルで変更できるのはローカルの計画表現のみであり、リモートへの追加書き込みはできません。
• 実装、ブランチ、コミット、プッシュ、無関係なトラッカーフィールド、兄弟ワーク項目、および計画以外のファイルは対象外です。

更新した計画は永続的なワークフロー状態として扱い、ディスク上に残し、ステージングしないでください。トラッカーまたは計画の変更承認によって、ステージング、コミット、またはプッシュを行う権限が付与されることはありません。

出力仕様

作成者は、アクティブなプレイブックで定義された構造化サマリースキーマをそのまま返します。ステータスのプレフィックスはプラットフォーム固有（GitHub では TASK_ISSUES:、Jira では SUBTASKS:）であり、Validation: は PASS | FAIL | NOT_RUN のままです。識別子の行、プラットフォーム固有のフィールド、テーブルの見出し、用語、および受け入れ可能な子項目参照値は、すべてアクティブなプレイブックに従います。

調整が成功または部分的に完了した場合、docs/<KEY>-tasks.md には、プレイブックで定義されたワークフローレベルの子項目テーブルがちょうど 1 つ含まれ、番号付きの各タスクセクションには、それに一致するインラインの子項目参照がちょうど 1 つ含まれます。受け入れ可能な具体値、未解決値、および劣化値は、アクティブなプレイブックの Child-Reference Values and Downstream Readiness セクションに記載されたもののみです。

サブエージェントレジストリ

サブエージェント	パス	用途
child-work-item-creator	./subagents/child-work-item-creator.md	現在の状態を確認し、アクティブなプレイブックを通じて不足しているリモートの子ワーク項目を調整し、計画ファイルを 1 つ更新して検証し、プラットフォームのサマリーを返します

ディスパッチする場合にのみ、サブエージェントのファイルを読み込んでください。

段階的開示マップ

必要な情報	読み込むファイル
プラットフォーム入力、識別子の導出、トランスポート、認証／機能のカテゴリ、書き込みモデル、正確な見出し、要約の形式、用語、テンプレート	アクティブな ./references/<platform>-playbook.md
共通の変更前確認の手順、冪等性、再試行、修復、要約の振り分け	作成者内の ./references/child-creation-playbook.md
共通のライフサイクル、検証、ステータスの組み合わせルール	./references/phase-4-io-contracts.md
現在の公開 CLI／API／設定の構文	./references/external-sources.md、次にアクティブなプレイブックで指定された URL のみ
作成者の動作	ディスパッチ時のみ ./subagents/child-work-item-creator.md

ディスパッチパターン

PLAYBOOK_PATH: ../references/<platform>-playbook.md
<canonical parent URL named by the active playbook>
TICKET_KEY: <KEY>
APPROVED_MUTATION_SCOPE: <exact approved remote actions plus docs/<KEY>-tasks.md>
CREATION_PLAYBOOK_PATH: ../references/child-creation-playbook.md
IO_CONTRACT_PATH: ../references/phase-4-io-contracts.md
EXTERNAL_SOURCES_PATH: ../references/external-sources.md

これらのパスは、参照先を使用するファイルである ./subagents/child-work-item-creator.md からの相対パスです。アクティブなプレイブックにプラットフォーム固有の詳細がすべて記載されています。中立的なディスパッチにトランスポートやトラッカーの用語を追加しないでください。

ワークフロー

1. プラットフォームを特定し、そのプレイブックを読み込み、正規の親 URL を検証して、プレイブックに従って <KEY> を導出します。
2. APPROVED_MUTATION_SCOPE を確認します。直接呼び出された場合、不明であれば一度だけ質問します。承認がない、または承認されなかった場合は、変更を加えずに、プレイブックのブロック時の要約を Validation: NOT_RUN とともに返します。
3. 上記のパターンを使用して child-work-item-creator にディスパッチします。
4. プレイブックで定義されたステータス接頭辞と Validation: の組み合わせに基づいて振り分けます。
5. 構造化された要約に加え、親、計画のパス、件数、警告、失敗、および実装がまだ始まっていないことを簡潔にまとめて返します。

ルーティングルール

結果	コーディネーターの対応
Playbook のステータスが PASS で、Validation: PASS の場合	検証済みの関連付けがすべて完了したことを報告し、次に進みます
Playbook のステータスが WARN で、Validation: PASS の場合	利用可能な具体的な関連付けを報告し、タスク選択の前に、劣化または未解決の行をすべて明示します
Playbook のステータスが BLOCKED の場合	停止し、承認、入力、計画の形式、関連付け、またはプラットフォーム選択に関するブロッカーを明示します
Playbook のステータスが FAIL の場合	停止し、分類されたトランスポート、権限、設定、作成／関連付け、境界、または検証の失敗を明示します
Playbook のステータスが ERROR、Validation: FAIL、または定義されていないステータスの組み合わせの場合	停止し、予期しないエラーまたは契約違反を明示します

トップレベルのステータスがすでに BLOCKED、FAIL、または ERROR であっても、Validation: NOT_RUN は Phase 4 の出力が不完全であることを示します。推測で判断せず、共有 I/O 契約と有効な playbook を使用して、整合性のない組み合わせを拒否してください。

例

入力：`ISSUE_URL=https://github.com/acme/app/issues/42`。GitHub の子課題への書き込みと `docs/acme-app-42-tasks.md` が承認されています。

github を検出し、完全な URL から TICKET_KEY=acme-app-42 を導出して、作成者に PLAYBOOK_PATH=../references/github-playbook.md を指定してディスパッチし、返された TASK_ISSUES と Validation の行をルーティングします。書き込みパスと下流のセマンティクスには、読み込んだ playbook で定義されたもののみを適用してください。別の playbook からフォールバックを持ち込んではなりません。