client-doclisted

# Client document The reader is a **client who does not know what a test, an endpoint, or a migration is.** He is deciding whether this work is worth paying for and what he gets. Write for him. **This is not a spec.** The `spec` skill produces the technical contract for the bot and the developer — `docs/specs/`, EARS acceptance criteria, a red-test list, request/response shapes. It is the right artifact for building and the wrong one for a client. Bending one into the other is the exact failure this skill exists to prevent. ## What it never contains no tests or test plans · no acceptance criteria / EARS / clause IDs · no endpoints, routes, `FormRequest`, `JsonResource` · no schema, migrations, or queries · no architecture, layers, or class names · no man-days or developer hours · no internal code or status number as the opening of a sentence. If the reader needs any of that, the artifact he wants is a **spec**. Say so and switch, rather than producing a hybrid that serves neither. ## Structure Template: `${CLAUDE_SKILL_DIR}/../../templates/client-doc.md` — the problem it solves · what the client will be able to do · what is included now · what is left for later · how long it takes · what is needed from him · what happens next · what is still open. ## Style - **Prose, not a backlog.** Sentences and short paragraphs. Bullets only for genuinely enumerable things (what is in, what is out). A client reads prose; a wall of clauses reads as an invoice. - **No em dashes in