scaffold-sub-issues-ghlisted

# /abc:scaffold-sub-issues-gh — Convert PLAN(s) to GitHub Issues Take one or more `PLAN-*.md` files, parse their sub-tasks, propose a GitHub parent issue (or add children to an existing one) with a managed `## Sub-issues` task-list, `repo:` / `status:*` / `blocks:*` / `blocked-by:*` labels, and an optional `## Validation` gate, then create them after the user confirms. The output of this skill is a **parent issue URL** (or `<owner>/<repo>#<n>` ID) you can paste straight into `/abc:ship-epic-gh` (parallel multi-repo) or `/abc:ship-issue-gh` (serial single-loop). This is the GitHub-Issues sibling of `/abc:scaffold-sub-issues` (which targets Linear). The two are deliberately parallel skills — pick by tracker, not auto-detect. See `github-conventions.md` in this directory for the label scheme and task-list parsing rules used across the `-gh` family. ## Hard rules - **Never create issues without an explicit confirmation gate.** Issue creation is write-heavy and visible to collaborators; the user must see the full proposed structure before any `gh issue create` call. - **Never create new labels silently.** If a sub-task references `repo:<name>` that doesn't exist, surface it and ask whether to create the label or rename the sub-task. Same for `status:*` if those don't exist yet. - **Never invent sub-tasks not present in the plan.** Parse what's there. If the plan is missing acceptance criteria or a `repo:`, ask the user — don't fabricate. - **Sub-issues must be created sequent