What happened?

Bug Description

The automated PR triage system is incorrectly applying the status/need-issue label to all open PRs, even when they have valid issue references in their descriptions.

Current Behavior

• All PRs in the repository currently have the status/need-issue label
• PRs with clear issue references (like "Addresses: Add internationalization (i18n) support to Gemini CLI #6525") are still being labeled as needing issues
• The triage system runs every 15 minutes and continuously misapplies these labels

What did you expect to happen?

Expected Behavior

PRs that reference valid GitHub issues should not have the status/need-issue label applied.

Client information

Root Cause

The triage script in .github/scripts/pr-triage.sh only checks GitHub's closingIssuesReferences API field:

gh pr view "${PR_NUMBER}" --json closingIssuesReferences -q '.closingIssuesReferences.nodes[0].number'

This API field only populates when PRs use specific GitHub closing keywords:

• Closes Isolate onSelect/onHighlight actions within AuthDialog #1234
• Fixes Isolate onSelect/onHighlight actions within AuthDialog #1234
• Resolves Isolate onSelect/onHighlight actions within AuthDialog #1234

But it ignores other valid reference formats:

• Addresses: Add internationalization (i18n) support to Gemini CLI #6525
• Related to Isolate onSelect/onHighlight actions within AuthDialog #1234
• See Isolate onSelect/onHighlight actions within AuthDialog #1234
• Manual issue links like [#6525](https://github.com/google-gemini/gemini-cli/issues/6525)

Examples of Incorrectly Labeled PRs

• PR feat(i18n): Phase 1 - Extract strings + i18next foundation #8060: Clearly states "Addresses: Add internationalization (i18n) support to Gemini CLI #6525" but has status/need-issue label
• Multiple other PRs have issue references but don't use exact closing keywords

Suggested Solutions

Short-term fix:

Update the triage script to also parse PR descriptions for issue number patterns (#\d+)

Long-term fix:

1. Update PR templates to require "Closes #XXXX" format
2. Add documentation about proper issue linking syntax
3. Consider using regex parsing as fallback when closingIssuesReferences is empty

Login information

No response

Anything else we need to know?

Immediate action:

Consider manually removing incorrect status/need-issue labels from PRs that have valid issue references

Impact

• Blocks legitimate PRs from proper workflow
• Confuses contributors about whether their PRs are properly linked
• Makes it difficult to identify PRs that actually need issue links
• Potentially delays reviews and merges

Additional Context

This affects the entire contributor workflow and creates friction for both new and experienced contributors who are following reasonable issue-linking practices.

Labels

• kind/bug
• area/automation
• priority/p1 (affects all contributors)