usage-guidelisted

Create a usage guide or how-to-use guide for a software project written so simply that even a young child at a grade-1 reading level can follow it. Short sentences, common words, one idea at a time, lots of concrete numbered steps, and pictures. Produces a clean illustrated single-file HTML page (or Markdown). Use this whenever the user wants a usage guide, how-to, user manual, getting-started guide, quickstart, step-by-step instructions, or the simplest-possible explanation of how to use their project. Use it even if the user only says "explain how to use this like I'm five", "write the simplest instructions", or "a guide my non-technical users can follow". Not a concepts course (learning-track), not a Q&A or knowledge base (project-faq), not the design-rationale doc (architecture-and-decisions), not contributor onboarding (onboarding-companion). Enforce the reading level with the bundled readability check.
imrohitagrawal/project-doc-skills · ★ 0 · Web & Frontend · score 58

Install: claude install-skill imrohitagrawal/project-doc-skills

# Usage Guide Builder (grade-1 reading level) Build a guide that shows a reader **how to use the project**, written so simply that a young child could follow it. The reader wants to *do* a task, not understand the theory. Read `references/house-style.md` first, then apply the stricter simple-English rules here. **Diátaxis mode:** *how-to* (task-oriented). Each section helps the reader do one thing. Keep it distinct from a learning track (which teaches concepts) and an FAQ (which answers questions). --- ## Before you start (inputs, when to run, where it sits) **Inputs it needs.** A project that a user can already *do something* with, plus enough to name the real tasks: a README, the commands or the screens a user actually touches, and the project profile (`assets/project-profile.md`, copied to `docs/project-profile.md` — it sets `grade_target_usage_guide` and `scope_usage_guide`). The guide describes only tasks you can ground in the real interface; it does not invent steps. If a task cannot be grounded, say so rather than guess. **When to run it in a Claude-Code build.** *Not* on an empty repo, and *not* per commit. A usage guide needs a usable surface to point at, so run it once a user-facing path actually works (a working command or a screen a user can complete a task on) — in practice once the quickstart runs end to end — and **refresh it per release/milestone** whenever the steps a user follows change. Treat it like docs-as-code: it carries a last-reviewed date and i