planning-the-worklisted

# Planning the work Splitting work into units answers **what** gets built. It does not answer how the pieces run, and the second question is where a plan actually fails: units sized well, ordered by nothing, each started wherever the last one finished. This skill owns one artifact — **the table** — and the criterion for it being settled. It does not run a unit, and it does not decide whether the work should exist. ## Find the plan before asking for it A request saying the breakdown is here almost always means it is in the repository — a plan document, a milestone list, an issue body — and the first move is to go and read it. Asking whoever sent you to paste what is already on disk spends their turn and reports an absence you never checked. If it genuinely is not there, say **where you looked** before saying it is missing. An unchecked absence and a real one read identically, and only one of them is a finding. ## The table One row per unit. Every column is required before any unit starts. | Column | What it holds | |---|---| | **unit** | a stable identifier other rows can depend on | | **deliverable** | what exists at the end that did not before | | **tier** | which tier of `ledger:qualifying-a-request` this unit is, decided per unit rather than inherited from the request | | **site** | where it runs: on the main line, or delegated to a fresh worker | | **depends_on** | the units that must finish first — an explicit empty list when none | | **acceptance** | the criteri