@yiliang114 same goal, discuss and merge one of them. #4577

Excited to get AI doing this for us

Current state after the latest update:

• This draft is now a supplement to the existing triage workflow on main, not a standalone replacement for all issue triage.
• Qwen Triage still runs on new issues.opened events, same-repository non-draft PR intake, explicit @qwen-code /triage, and manual workflow_dispatch.
• The issue follow-up bot remains a separate lightweight workflow for related-issue lookup, missing-information requests, invalid/spam handling, and lightweight labels.
• The PR no longer tries to remove automatic full triage from newly opened issues. The two issue workflows are allowed to coexist because their responsibilities differ.
• The latest commits also tighten PR triage safeguards: same-repository non-draft PRs only, no actions: write, no guessed maintainer mentions, fewer skill reference files, and complete coordination markers in comment templates.

I updated the PR body to match this scope. Older comments that described the temporary pre-adjustment event split should be treated as outdated.

PR scope reduced and title/body updated to match the current 2-file diff (workflow hardening only).

All review threads resolved:

• Fixed in current revision: fork PR guard, actions: 'write' removal, cancel-in-progress conditional, timeout bump, maxSessionTurns removal, Stage 1a terminal gate clarification
• Pre-existing / out of scope: competing issues: opened trigger with qwen-automated-issue-triage.yml (exists on main already, not introduced here)
• Stale: all SKILL.md / workflow-overview.md / issue-followup-bot.yml comments — those files are no longer in this PR
• Follow-up noted: adding ready_for_review to the PR trigger types list (natural companion to the draft == false guard)

Evidence for the current scope

Adding the concrete runs/reviews that motivated the current 3-file diff:

Additional cleanup/hardening included in the same small diff:

• qwen-triage.yml now triggers on ready_for_review, so draft PRs skipped at opened are triaged once they become reviewable.
• qwen-triage.yml keeps pull_request_target limited to same-repository non-draft PRs, reducing the privileged workflow surface for fork PRs.
• qwen-triage.yml drops the unused actions: write permission.
• qwen-triage.yml removes event_name from the concurrency group so manual /triage, PR events, and issue events for the same target do not run as separate groups.

The current PR intentionally does not merge issue follow-up, scheduled issue triage, release labeling, or label cleanup. Those are separate workflow-policy questions.

@qwen-code /triage

Thanks for the PR @yiliang114!

Template looks good ✓ — all required sections present and filled in properly.

On direction: this is solid CI hygiene. The problems are real and well-evidenced — turn-cap exit code 53 killing triage mid-run, 10-minute timeout too tight for full Stage 2/3, bot comments racing with concurrency. These are the kind of production-warts fixes that only surface after the workflow has been running for a while. Clearly aligned with the project's triage automation investment.

On approach: the scope is tight — 2 files, +29/-9, each change traceable to a specific observed failure. The cancel-in-progress expression intentionally mirrors the job if (minus the redundant github.repository check, since concurrency is workflow-scoped), and the inline comment explains the design choice. The fork guard on pull_request_target is a good security tightening. Removing the unused actions: write permission is clean.

One thing worth confirming: with cancel-in-progress now gated on maintainer association for issue_comment events, any non-maintainer @qwen-code /triage comment will be silently ignored (job if rejects it AND cancel-in-progress stays false). That's the correct behavior — just flagging it so it's an intentional decision, not an accidental gap.

actionlint passes clean on the PR version of the workflow. ✓

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

Two files changed, both straightforward. No correctness bugs found.

.github/workflows/qwen-triage.yml — The diff is well-structured. The cancel-in-progress expression is the most complex change, and it correctly mirrors the job if conditions minus the github.repository guard (redundant inside concurrency since the group is workflow-scoped). The inline comment explains this intentional divergence. The ready_for_review trigger addition closes a real gap where draft-opened PRs were silently missed. The fork guard (head.repo.full_name == github.repository) on pull_request_target is correct security hardening — fork PRs can still be triaged manually via maintainer @qwen-code /triage comment. Removing actions: 'write' and maxSessionTurns: 25 are both clean subtractions with clear justification.

.qwen/skills/triage/references/pr-workflow.md — The "terminal gate exception" clarification is a useful addition. It prevents the confusing behavior where a template failure would post both a CHANGES_REQUESTED review AND a Stage 1 comment. The wording is clear and the placement right after the comment table is logical. The adjustment to the "save this comment's ID" paragraph correctly distinguishes template failures (already stopped in 1a) from direction escalations.

Validation

$ actionlint qwen-triage.yml  # PR version
# exit 0 — clean

$ git apply --check  # diff from gh pr diff
# clean — patch applies without conflicts

Tmux Testing

N/A — this is a CI-only workflow change with no user-visible CLI behavior to demonstrate. The changes affect GitHub Actions trigger conditions, concurrency groups, and timeout settings. There is no terminal interaction to capture.

$ actionlint qwen-triage.yml  # PR 版本
# exit 0 — 通过

$ git apply --check  # 来自 gh pr diff 的 diff
# 干净 — patch 无冲突地应用

— Qwen Code · qwen3.7-max

Reflection

This PR solves real, well-documented production problems with the triage workflow. The diff is small (+29/-9), each change traces back to a specific observed failure, and the code review found no bugs.

The concurrency/cancellation logic is the trickiest part and it's handled correctly — the cancel-in-progress expression intentionally mirrors the job if minus the redundant repository check, with an inline comment explaining why. The fork guard and ready_for_review trigger are both genuine improvements. The pr-workflow.md clarification prevents a confusing double-output on template failures.

The existing CHANGES_REQUESTED review decision on this PR appears to be from a prior iteration. The current revision addresses all previously raised concerns — scope was reduced from a broader rewrite to focused hardening, all review threads were resolved, and the author has been responsive throughout.

My independent assessment: this is the right fix at the right scope. Nothing to cut, nothing to add.

Approving. ✅

— Qwen Code · qwen3.7-max

Re: maxSessionTurns — intentionally not adding it back. The 30-min workflow timeout is the single execution bound. Turn limits caused premature exit (code 53) before Stage 2/3 could complete, which was the original problem this PR fixes. The cost tradeoff is acceptable given the timeout acts as the hard stop.

Re: PR body — updated to reflect the reverted qwen-code-pr-review.yml scope.

@qwen-code /triage