issue-triage

# Triage a GitHub issue Triage answers three questions in order: **is it real, is it new, and how urgent is it.** Labels and assignees come last. Applying labels without answering the first three is filing, not triage. ## 1. Read it as written Fetch the issue and its comments. Separate what the reporter **observed** from what they **concluded**. "The API returns 500 when I pass an empty array" is an observation. "The validation layer is broken" is a conclusion, and it is frequently wrong even when the observation is right. Triage the observation. Note what is missing: version, environment, reproduction steps, actual vs expected. You need these to judge severity, but ask for them only after step 2 — most issues that look under-specified turn out to be duplicates of a well-specified one. ## 2. Search for duplicates before anything else This is the step that gets skipped and the one that saves the most work. Search the issue's distinctive terms — an error string, a function name, a status code — rather than its title. Titles describe symptoms in the reporter's words; error text is stable across reporters. Search **closed** issues too: a bug closed as fixed and reported again means a regression, which is a different and more urgent finding than a new bug. When you find a duplicate, comment linking both directions and close the newer one, unless the newer report contains a better reproduction — in which case close the older and carry the good repro forward. ## 3. Reproduc...