groundworklisted

# groundwork - from idea to a parallelizable foundation Take a project idea or a large new area/epic to the point where parallel feature work can safely begin. One job: design the **minimum shared foundation** the first wave of features would collide on, land it first, and **carve the rest into disjoint work-items** that N worktrees can build at once without stepping on each other. This is the step above `/plan-grill`. `/plan-grill` grills one feature into a done-contract; groundwork sits over it - it shapes the whole idea, builds the substrate, then hands each carved work-item down to `/plan-grill` (feature) or `/diagnose` (fix). It runs after `/onboard` has wired the tool and the branching base, and before any single feature is grilled. Read `.better-dev/overrides.md` first (`.better-dev/bin/bd-mem read overrides`). A project's own stack, architecture conventions, or a house way of slicing work wins over any default below. **One fork after that read, before shaping starts, on every greenfield build ask.** Two routes reach a built product and they spend the user's own attention very differently: this skill's - a shared foundation, then carved work-items each grilled, reviewed, and merged with the user at every gate - or `/gauntlet`'s, a single loop prompt handed to a fresh session that then builds against a concrete bar for hours with almost no interaction. Put it to the user in one question, described in those terms rather than by skill name. A recorded override settles