← ClaudeAtlas

make-workplanlisted

Turn a DRP + architecture into a WORK PLAN (Markdown) — phases → milestones → checkbox tasks, each milestone with an explicit test gate. Use when the user asks to "plan the build", "make the work plan", or "break this into milestones".
dsivov/ONBOARDING · ★ 0 · AI & Automation · score 70
Install: claude install-skill dsivov/ONBOARDING
# make-workplan — the build plan (Stage 5) Produce `docs/<NAME>_WORK_PLAN.md` from `docs/templates/WORK_PLAN.template.md` (copied into the project by new-project; fall back to the ONBOARDING repo if absent). ## Build it from the DRP 1. Read the DRP's requirements + acceptance criteria and the architecture's components. 2. Group work into **phases** (`P0` foundations/contracts first, then thin-vertical, then engine, then surface/UI). Assign **milestones** (`M1…`) to the phases that ship a demonstrable slice. 3. For each phase: concrete **checkbox tasks** naming real files/paths, including the **test files**, each with a stable **`P<n>.<m>` id** so a milestone report can name exactly what it completed (§8). Paths must match the DRP/architecture **layout tree** (R10) — if a task needs a path the layout doesn't have, fix the layout, don't invent the path here. Lift the DRP's acceptance criteria into each milestone's **test gate**, and make every gate name the requirements it proves — `gate (M2): … — proves F3, F4` (R3). `P0` includes the environment task: the dependency manifest (`environment.yml`, `pyproject.toml`, `requirements.txt`, `package.json`) pinned to the agreed libraries. 4. **Give every numbered NFR a gate (R13).** Walk the DRP's §4 table: each target with a number needs a milestone that *measures* it, with its harness in `scripts/` (R2). Targets that can only be shown late (latency at peak, failover timing) get their own phase — `P4