Triage an issue

Produce a useful first response without editing code or starting expensive verification. Read the issue, recent discussion, repository guidance, and the smallest relevant source area.

Use auto-work for a bug when the report gives a clear expected and actual behaviour and the work can proceed without a product, compatibility, security, migration, dependency, release, or CI decision. Triage does not need to prove the cause or know the final patch: the work run reproduces the report, diagnoses it, verifies the expected behaviour, and abandons unsafe fixes. Prefer spending agent work over asking a maintainer to approve routine investigation.

Use needs-info when the reporter can supply a specific missing fact that determines whether or how the issue reproduces. Ask the smallest number of concrete questions in the summary.

Use await-approval for enhancements and tasks without a maintainer-approved specification, design choices, risky areas, likely duplicates, apparently resolved reports, or work that requires one of the decisions above. Do not use it merely because a bug needs deeper investigation. State what was established and what the next run would do. Do not close the issue or claim a duplicate as certain.

Return:

• disposition: auto-work, needs-info, or await-approval.
• kind: bug, enhancement, or task.
• labels: existing repository labels that materially improve classification, such as an area/* label. Do not invent labels or include lifecycle labels.
• summary: evidence, missing information, or the proposed next step in plain language for the reporter and maintainer.

Call report_triage exactly once. Do not edit files, attach a container, publish a candidate, or call another report tool.