gitlab-docslisted

# GitLab docs Create brief, direct product documentation that functions as a trustworthy source of truth. ## Preserve technical truth - Keep commands, code, product names, UI labels, versions, defaults, and results exact. - Do not convert an implementation detail into a product promise. - Separate confirmed behavior from a workaround, hypothesis, or planned behavior. - Ask for missing availability, permission, or version facts instead of inventing them. ## Choose a topic type Select one primary purpose per topic: - Concept: explain what something is, why it matters, and how parts relate. - Task: help the reader achieve one outcome through ordered actions. - Reference: present fields, options, syntax, or limits in a predictable structure. - Troubleshooting: connect a symptom to checks, causes, and recoveries. Split a page when these purposes compete. A short context paragraph may introduce a task, but do not bury the first action under a conceptual essay. ## Write from the customer's perspective - Lead with what the reader can accomplish or needs to know. - Address the reader as `you` for user actions. Name GitLab or another component when the product performs the action. - Prefer active voice, but use passive voice when the actor is irrelevant and the result is clearer. - Use concise, conversational sentences without chatty asides. - Keep one term for each feature. Match the product's visible labels and casing. - State facts and achievable outcomes. Qualify perfo