用途：在用户或调用方已批准 GitHub 写入及对 docs/<ISSUE_SLUG>-tasks.md 的限定更新后，为已澄清的 Phase 4 任务计划创建或对账 GitHub 子任务 issue。
主要能力：编排器从 ISSUE_URL 推导 OWNER、REPO、PARENT_NUMBER 和 ISSUE_SLUG（<owner>-<repo>-<parent_number>），调度 task-issue-creator 子代理；子代理负责计划解析、gh CLI 与 REST API 调用、能力检测、计划文件编辑和验证。编排器只保留判定、路径、计数、写入路径元数据、警告和失败信息。
使用方式：输入 ISSUE_URL（必填）和 APPROVED_MUTATION_SCOPE（可选）。正常编排运行会传入批准范围；直接独立运行时可先向用户收集批准。若缺少或格式错误的 ISSUE_URL，返回阻塞摘要，Parent 与 ISSUE_SLUG 为 UNKNOWN，计划文件未更新，计数为零，Write model 为 unknown，Capability 为 not checked，Validation 为 NOT_RUN。若批准缺失或被拒绝，返回相同形状的阻塞摘要。随后读取并调度 ./subagents/task-issue-creator.md，按返回的 TASK_ISSUES 与 Validation 行路由。
适用场景：需要将已批准的任务计划落地为 GitHub 子任务 issue，并保持任务列表可追溯性的工作流。
限制：仅在批准后运行；GitHub 子 issue 支持因 CLI 版本、仓库、API 可用性和已安装扩展而异，运行时路径对调用方很重要。报告 GitHub 结果时始终包含 Write model 和 Capability。Validation: NOT_RUN 视为不完整的 Phase 4 输出。实现工作尚未开始。外部 URL 为可选即时来源，网络不可用时技能仍可从捆绑文件执行。