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 Everything in [`../../guidelines/writing-standards.md`](../../guidelines/writing-standards.md) applies — every sentence carries a fact, no preambles or wrap-ups, no filler vocabulary, no self-praise, no section kep