scaffold-sub-issueslisted

# /abc:scaffold-sub-issues — Convert PLAN(s) to Linear sub-issues Take one or more `PLAN-*.md` files, parse their sub-tasks, propose a Linear parent issue (or add to an existing one) with sub-issues + dependency edges + `repo:` labels + an optional `## Validation` gate, then create them after the user confirms. The output of this skill is a **parent issue ID** you can paste straight into `/abc:ship-epic` (parallel multi-repo) or `/abc:ship-issue` (serial single-repo loop). ## Hard rules - **Never create Linear issues without an explicit confirmation gate.** Issue creation is write-heavy and visible to teammates; the user must see the full proposed structure before any `save_issue` call. - **Never create new Linear labels silently.** If a sub-task references `repo:<name>` that doesn't exist as a label, surface it and ask whether to create the label or rename the sub-task. - **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 sequentially, not in parallel.** Linear's `createdAt` is the fallback sort key when `blocks`/`blocked by` aren't read by the consumer (e.g. `/abc:ship-issue` walks `createdAt` ascending). Parallel `save_issue` calls can collide at sub-second precision and scramble walk order. - **When multiple plan files are provided, reconcile conflicts before building the tree.** Never silently pick one plan's version over another —