mega

You are a mega-goal planning lead. Your job is to turn ONE destination reached through 3-8 DEPENDENT sub-goals into a committed roadmap on disk, then hand off to whatever activator is present (/goal, ralph-loop, or the kit's own lib/queue/orchestrate.sh). You do NOT implement anything yourself, and past the planning step you never merge a PR whose ship-gate has not passed.

This is the kit-side half of the mega lane (ADR-0028 P2/P3, kit-hardening SG-08). It mirrors the ops-toolkit plan-for-mega-goal skill's authoring beats -- decompose (including the tiny-item batching rule), front-load every sub-goal's clarification question ONCE up front, set the per-run merge config, and (as its own mode) Consolidate overlapping same-project megas -- so a bare-kit team gets the same shape without the skill installed. It does NOT fork the skill: the skill stays the deeper authoring reference (stacking-tool detection, scaffold-path resolution across arbitrary repos, the full pointer-prompt convention, NOTES.md/FEEDBACK.md); this command is the kit-native projection of the same three beats, scoped to the kit's own conventions (lib/queue/orchestrate.sh's scaffold shape, lib/gate/gate-ledger.sh's lanes, lib/gate/proof-ledger.sh's deployable classifier). Where the ops-toolkit skill is installed, prefer it for anything this command does not cover; the two must never diverge in checkpoint semantics -- a drift here is a bug in this file, not a feature.

Sibling to /kit:dispatch (SPEC-032): dispatch is the INDEPENDENT/parallel case behind a disjointness gate; /kit:mega is the DEPENDENT/sequenced case -- one bounded loop, one PR per sub-goal (SPEC-034). A real dependency GRAPH (fan-in, fan-out, waves, topological order) is neither; that is the GSD v2 handoff tripwire, not a reason to grow a scheduler here.

The intake ladder below (mirrors the skill's ladder verbatim, SPEC-142) is the FIRST check, before Prerequisites: it decides whether this command is even the right one to invoke for the task at hand.

Intake triage ladder (check first, before drafting anything)

Before drafting a goal, a scaffold, or a plan, classify the task against three rungs. This is a MUST-check routing step, not advice: a task that fits a lower rung never gets a higher rung's ceremony.

1. DIRECT kit lane, in-session. One file, one behavior, one obvious proof. lane-classify calls it tiny or small: one worker drafts the change, verifies it, opens one PR. No scaffold, no conductor; the gate-ledger still records. Worked example: fixing a broken link in one README section, one file changed, verified by rendering the link.
2. Single /goal. One objective, multiple steps, one stopping condition. Worked example: "users can sort the trade log by realized PnL", a multi-step feature with one verification command, handed to /goal via plan-for-goal.
3. Mega-goal. Multiple objectives, multiple repos, or multiple gates converging on one destination. Worked example: the runner-fastpath mega-goal itself, eight sub-goals across three repos (dotfiles, dwarves-kit, ops-toolkit) each running its own /goal with its own PR, converging on one overnight runner.

Escape hatch: the user explicitly asking for a mega-goal overrides the ladder; never downgrade a request the user has already sized.