planlisted

# /abc:plan — Draft a PLAN-*.md fast Produce a structured plan document within a few tool calls — no extended clarifying-question loop. The output is shaped so that: - `/abc:scaffold-sub-issues` (Linear) or `/abc:scaffold-sub-issues-gh` (GitHub Issues) can turn the sub-tasks into a parent + sub-issues. Pick the scaffold by tracker — the PLAN grammar is identical for both. - `/abc:ship-epic` / `/abc:ship-epic-gh` (later) can read the sub-issue dependency graph and ship them in parallel. The exact grammar these consumers parse — sub-task block fields, the relations sentinel, and where the validation gate attaches — is single-sourced in [`plan-format.md`](./plan-format.md). The skeleton below emits that grammar; keep them in sync. ## Hard rules - **Write first, refine in place.** Within the first 3-5 tool calls, produce a draft `PLAN-<slug>.md` on disk. Then iterate via the file, not via Q&A. The user has explicitly said extended clarifying questions before any deliverable are an anti-pattern. - **Always include the obvious adjacent sections** on the first pass: context, approach, sub-tasks (with repo + dependencies), open questions, validation. Even if a section is one line, write it — easier to delete than to retroactively add. - **Never commit the PLAN file or push it.** It lives locally until the user decides where to keep it. - **Use `repo:<name>` notation per sub-task** so the scaffold can map it to a `repo:<name>` label and `/abc:ship-epic[-gh]` can resolve it to a w