doc-stylelisted

# Documentation Style ## Naming structure ```yaml --- name: a name that captures the project type: the actual audience or use case --- ``` ## Tone Maintain my original voice. Drop marketing fluff. Use facts, brevity, and direct language. Never claim a feature, result, benchmark, release, user, or level of stability that the repository cannot prove. Say "planned", "under acceptance", or "experimental" when that is the truthful state. ## First-screen rule The first screen must answer four questions without scrolling far: What is it? Who is it for? What painful problem does it remove? What proof can the reader inspect now? Use one sharp sentence, one short explanation, and the strongest available proof: a demo, screenshot, passing workflow, benchmark, release, or reproducible command. Do not begin with history, philosophy, or a large feature list. ## Content structure ### Intro — what is it? A brutalist two- or three-sentence breakdown of what the project is, who it serves, and why it exists. ### Quick start Positioned immediately after the introduction. Provide the shortest, reproducible path to execution: Install: Single shell command. Run: Minimal invocation command. Result: Expected outcome or output. Keep detailed screenshot walkthroughs below this section to prevent slowing down technical users. ### The problem Describe the concrete failure in the existing workflow. Prefer an observable problem over an abstract ambition. ### How does it work? Tech