docs-style-tonelisted

# docs-style-tone — Style and Tone Analysis ## Workflow 1. **Gather the docs** — get the list of pages in scope and read their content. If a semantic/graph search tool over the markdown is available (self-hosted `markdown-lsp`, or a connected Docsbook workspace), prefer it — it's faster and cheaper than scanning files; otherwise read the files directly with `grep`/`find`. Prioritize Tier 1 pages (quick-start, pricing, auth, install) first. Sample a few pages across different types (tutorial, reference, how-to) to calibrate general style before flagging specifics. 2. **Apply checklist** — check voice and person, filler and marketing words, sentence length and structure, headings, and terminology consistency. Apply tone expectations per page type. 3. **Produce report** — return one JSON issue object per finding, sorted by severity. ## Guardrails - Do not edit any documentation files — surface findings only. - Ask whether the project has a style guide before starting — analyze against that if yes, use defaults if no. - Flag passive voice in instructions; passive in reference pages may be intentional — ask the user about the strictness level. - "Simply", "just", "easily" — flag for review, not removal — context determines whether they're condescending. - Terminology inconsistency is only a problem when the same concept has multiple names — precise technical synonyms used in appropriate contexts are not flagged. ## Inputs This skill needs two things, by whatever means are av