audience-checklisted

Re-read the README — or whichever front-door doc the user names — as **several different readers in turn**, not as the author. The author knows what every line means; a first-time reader does not. The job is to surface where a specific audience gets confused, under-served, or bounces, and to propose concrete fixes. This is an INTERNAL dev skill (not shipped to consumers). It complements the `readme-brevity` and `docs-quality` rules: those govern length/polish; this checks whether the content actually lands for who it's for. ## How to run it 1. **Read the target doc in full** (default: `README.md`; honor a path the user gives). Also skim the docs it links to, so "the README promises depth the doc doesn't deliver" is checkable. 2. **For each persona below, do a cold read** — adopt that reader's goals, vocabulary, and patience. Ask their questions, not yours. 3. **Produce the report** in the format at the end. Be specific: quote the exact line, name the exact fix. Vague notes ("could be clearer") are useless. ## The personas Run all of these unless the user scopes to a subset. ### 1. Claude Code user (the primary audience) Already lives in Claude Code; skimming on a laptop between tasks. Wants the WOW in the first screen and a copy-paste install in seconds. - Does the first screen land what vigiles does and why they'd care? - Is the install path (`npx vigiles init`, the agent prompt) above the fold and obviously runnable? - Does it speak their language (hoo