docslisted

# docs Write docs a real person wants to read. Short, plain, built around someone trying to do a real thing. "Document feature X" is not the job. "Help someone do Y with X" is the job. Work in two phases. First plan the story: who reads this, what they want, and how many pages it should be. Then write. ## When to run Docs ship with the code. Run this skill at three moments, not only when asked. - Someone asks for docs. Write them. - Planning a feature or change in a repo. Before the plan is done, list which docs are new and which need updating. This doc-impact list is part of the plan, the same as the code changes. - Finishing an implementation. Write or update those docs before you call the work done. A change to how something behaves that ships no doc change is not finished. ## Find the docs first Before writing anything, find where docs live. 1. Look for a docs folder. Check `docs/` first, then `documentation/`, `content/docs/`, `site/`, `website/docs/`. 2. Found nothing? Ask the user where docs should go. Do not guess and do not create a folder on a hunch. 3. Open 2 or 3 existing pages near where the new content belongs. Read them for voice, tone, frontmatter fields, and structure. 4. Note which components the site already uses (steps, tabs, callouts, cards, accordions, code groups, and so on). Different sites have different ones. 5. Reuse those components to tell the story. If the site has a steps component, use it for walkthroughs. If it has tabs, use them for