user-manuallisted

# User Manual — Read the Code, Drive the UI, Ship a PDF Three passes, in this order, and the order is the point: 1. **Learn** the product from the codebase — routes, roles, what each screen is for 2. **Capture** every screen by driving the real app 3. **Write** the prose *against the captured screenshots*, then render **Never write the manual first.** Prose written before capture describes the UI you imagine, and every mismatch survives into a document a customer reads. Screens get renamed, buttons move, fields you were sure existed don't. ## Step 0: Scaffold ```bash ~/.claude/skills/user-manual/scripts/init.mjs docs/user-manual ``` Creates the working directory, `package.json`, `manual.config.json`, and an HTML skeleton wired to `assets/manual.css`. Then `npm install`. ## Step 1: Learn the product Read the codebase, don't ask the user to explain their own app: - **Routes** — the router config or file-based route tree. This is the chapter list. - **Navigation** — the sidebar or nav component gives you the user's mental model and the order chapters should follow. Follow the app's order, not the filesystem's. - **Roles and permissions** — who sees what. A manual that documents admin-only screens for an operator audience is worse than no manual. - **Forms** — field names, validation rules, required vs optional. This is where manuals earn their keep; it is what people actually look things up for. - **Empty and error states** — what users hit when something goes wro