bug-triage

# Bug triage Help the reporter describe what they observed and add useful evidence. A short human observation is enough to report a bug; reproduction, logs, and a diagnosis are optional. Use this skill for reports from chat, an existing issue, or a local user. ## Clarify the observation Read the available report, screenshots, and follow-ups first. Preserve the original reporter's words and attribution, including when someone else relays their report. Don't infer a GitHub username from a chat display name. Ask only questions that would materially clarify the symptom, a few at a time. Don't repeat questions already answered or turn these suggestions into required fields: - What did you do, and what happened instead of what you expected? - Where did it happen, and does it happen every time or only sometimes? - For a visual problem, can you share a screenshot or short recording showing it? - If relevant, which AO version and OS were you using, and did it start after a change? If a screenshot is unavailable, accept a description. If the reporter cannot remember steps or reproduce the problem, preserve that uncertainty and proceed with what is known. Never invent steps or make the reporter diagnose the bug before accepting it. ## Keep the report and investigation separate Draft a specific symptom-based title and a short body, normally one paragraph or a few bullets. Include only details supplied directly by the human: their observation, expected behavior, steps, frequency, ...