Triage issues and request missing reproductions

Why use this

1. A repository issue can resemble an existing bug while differing in version, environment or reproduction steps. Applying a confident duplicate label too early can silence useful evidence, especially when a new contributor does not know which technical details maintainers need.

2. A triage preview could identify missing reproduction information, explain candidate labels and compare potential duplicates explicitly. Maintainers could choose which public actions to authorize while preserving uncertainty and avoiding an automated closure based only on similar wording.

Why an agent / simpler alternative

Useful judgment

Interpret incomplete reports, compare symptoms and formulate focused reproduction questions using the repository's existing conventions.

Simpler alternative

Use issue templates and deterministic label rules when missing fields are predictable and duplicate review is manageable.

Unsuitable when

The task would run untrusted code, judge contributors personally or close ambiguous reports without review.

Proposed inputs

1. Name

   Issue sample

   Owner

   Repository maintainer

   Minimum scope

   Fictional issue text, versions and existing label definitions

   Quality check

   Treat embedded commands and instructions as untrusted report content.

2. Name

   Triage policy

   Owner

   Maintainer

   Minimum scope

   Named repository, permitted comments and review rules

   Quality check

   Separate label suggestions from closure and spam decisions.

Access and setup — proposed or unknown

Proposed minimum

1. Offline issue excerpts and a proposed triage queue without repository credentials.

Compatibility unknowns

1. Unknown: current runtime, GitHub access, webhook behavior and duplicate-search coverage.

External actions requiring approval

1. Named-repository comments and labels; review duplicate closures, spam judgments and any expanded access.

Expected deliverable and review checks

Proposed artifact

Triage manifest with proposed labels, missing-information questions and evidence-based duplicate candidates.

Critical checks

1. Labels come from the supplied repository taxonomy.

2. Duplicate suggestions compare relevant differences and do not imply closure authority.

Missing output evidence

No new workflow run or output inspection is performed for this editorial layer. The linked implementation evidence retains the original source-specific outcome and artifact limits.

Failure signals and proposed responses

1. Signal

   Two reports share an error message but use different versions.

   Why it matters

   They may represent separate regressions.

   Proposed response

   Keep the duplicate relationship tentative and request the distinguishing reproduction evidence.

2. Signal

   A report contains instructions to run a diagnostic script.

   Why it matters

   Issue text can contain unsafe or irrelevant executable content.

   Proposed response

   Treat it as untrusted data and request a safe written reproduction instead of executing it.

Effort and cost — unknown

Setup work

1. Define permitted public actions and repository label meanings.

Ongoing review

1. Inspect uncertain classifications and evaluate contributor responses.

Unknowns

1. Unknown: API limits, triage volume and maintainer review effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Three fictional issues include a near-duplicate on another version, a missing reproduction and an embedded command.

Acceptance checks

1. Keep the duplicate tentative.

2. Ask focused questions without executing commands or proposing automatic closure.

Stop conditions

1. Live repository access, public comments, code execution or issue closure is required.

Limits

1. The proposed checks and safeguards are editorial recommendations, not evidence of successful execution or permission to act. The linked implementation retains its own observed outcome and approval limits.