ci(triage): Fix Qwen triage workflow prompt#4787
Merged
Merged
Conversation
Contributor
📋 Review SummaryThis PR addresses two critical issues from the #4784 incident: (1) the workflow posting literal file paths like 🔍 General Feedback
🎯 Specific Feedback🔴 Critical
🟡 High
🟢 Medium
🔵 Low
✅ Highlights
|
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes the Qwen triage GitHub Actions workflow so it reliably loads the triage skill, posts comment contents (not file paths), and avoids accidental cancellation across different event types.
Changes:
- Switch the workflow prompt to a direct slash-command invocation (
/triage <number>) to ensure the skill framework loads correctly. - Update the workflow concurrency key to include
github.event_name, preventing skipped/irrelevant event runs from canceling active triage runs. - Tighten triage skill/reference rules around comment posting (
gh api -F ...vs-f/--body @...) and exclude process labels from being modified.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
.qwen/skills/triage/SKILL.md |
Clarifies triage rules (comment body file semantics, rerun behavior, process-label exclusion). |
.qwen/skills/triage/references/pr-workflow.md |
Fixes and standardizes the documented gh api usage for creating/updating stage comments (including -F). |
.github/workflows/qwen-triage.yml |
Uses direct /triage prompt and improves concurrency grouping to prevent cross-event cancellations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Add event_name to concurrency group so that issue_comment events (even those that will be skipped by the job if-condition) don't cancel in-progress pull_request_target or issues triage runs. Also add process label exclusion (welcome-pr, maintainer, help wanted, good first issue) to the triage skill rules. Closes #4785
The workflow_dispatch target input defaulted to 'issue', which could cause PR numbers to be triaged with the wrong workflow. Remove it and let the triage skill auto-detect from GitHub metadata instead.
The triage skill already infers the target type from GitHub metadata. Passing kind explicitly adds complexity without value and was causing the workflow_dispatch path to mismatch when the default was wrong. Simplify prompt to just `/triage $NUMBER`.
81a3c04 to
333d131
Compare
Collaborator
Author
|
@qwen-code /triage |
Collaborator
|
Thanks for the PR! Template is complete — What, Why, Reviewer Test Plan, Risk & Scope, Linked Issues, and 中文说明 are all present. ✓ On direction: this directly fixes two production bugs in our own CI triage tooling — the bot posting literal file paths ( On approach: the three changes map 1:1 to the three problems, which is exactly right. Replacing the 15-line prompt with One observation: switching Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整——What、Why、Reviewer Test Plan、Risk & Scope、Linked Issues、中文说明都有。✓ 方向：直接修复了我们自身 CI triage 工具的两个生产 bug——bot 输出字面文件路径和不相关 workflow 互相取消。方向明确，确有需要。Issue #4785 记录了根因。这是内部 CI 基础设施，不需要 CHANGELOG 参考。 方案：三个改动一一对应三个问题，完全正确。用 一个观察：pr-workflow.md 从 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
wenshao
reviewed
Jun 6, 2026
- workflow: pass `--repo ${{ github.repository }}` so /triage cannot
target a different repo even under prompt injection
- workflow: expand `coreTools` to cover read_file/grep_search/glob/agent
/enter_worktree/exit_worktree — the skill needs these to run end-to-end
- SKILL.md: rename legacy `task` → `agent`, drop stale `read_many_files`
from allowedTools so it matches the workflow's coreTools
- SKILL.md: add a Local invocation branch to the Duplicate Guard so
maintainers running `/triage` from a terminal hit a defined path
Addresses review feedback on #4787.
wenshao
approved these changes
Jun 6, 2026
wenshao
requested changes
Jun 6, 2026
wenshao
approved these changes
Jun 6, 2026
Collaborator
Author
|
@qwen-code /triage |
Collaborator
Code ReviewThree files changed, +29/-32 — net reduction, which is a good sign for a bug fix.
Concurrency moved from workflow level to job level with Prompt simplified from 15 lines to a single
Comment posting switched from Verdict: No critical bugs, no security issues, no AGENTS.md violations. All changes are correct, minimal, and well-scoped. TestingThis PR modifies GitHub Actions workflow definitions and skill documentation files. The workflow changes only take effect once merged to Post-merge validation plan: trigger — Qwen Code · qwen3.7-max |
Collaborator
ReflectionThis is a meta-PR — it's fixing the triage workflow that I'm currently running inside of. Which is a good sign: the author is dogfooding the fix in real time. The three changes are tightly scoped to the three documented problems. No scope creep, no "while I'm here" refactoring. The net diff is -3 lines (+29/-32), which is exactly what you want from a bug fix PR. My independent proposal before reading the diff was essentially identical to what the PR does: simplify the prompt, add The concurrency tradeoff (potential rare duplicate stage comments vs. every triage run silently cancelled) is well-reasoned and explicitly documented in the Risk section. Worth monitoring post-merge but not a blocker. The coreTools addition is a real gap fill — without No reservations. This is a clean, focused fix for a real production problem. LGTM. ✅ 中文说明这是一个 meta-PR——修复的是我正在运行其中的 triage workflow。这是个好信号：作者在实时 dogfood 这个修复。 三个改动严格对应三个已记录的问题。没有范围蔓延，没有"顺便"重构。diff 净减少 3 行（+29/-32），正是 bug 修复 PR 该有的样子。 我在读 diff 之前的独立方案和 PR 的做法基本一致：简化 prompt、在 concurrency key 加 并发性的取舍（罕见重复评论 vs. 每次 triage 运行被静默取消）是经过深思熟虑的，并在 Risk 部分有明确记录。合并后值得观察，但不构成阻塞。 coreTools 的补充是真正的缺口填补——没有 没有顾虑。这是一个干净、聚焦的修复，解决了真实的生产问题。LGTM. ✅ — Qwen Code · qwen3.7-max |
wenshao
reviewed
Jun 6, 2026
| - Labels: apply existing only, never create | ||
| - Comments: always `--body-file` (except short hardcoded verdicts in `gh pr review --approve` / `--request-changes`) | ||
| - Labels: apply existing only, never create. Do not touch process labels (`welcome-pr`, `maintainer`, `help wanted`, `good first issue`) | ||
| - Comments: read body from file. Use `--body-file FILE` for `gh issue/pr comment`, |
Collaborator
There was a problem hiding this comment.
[Suggestion] The Comments rule covers gh issue/pr comment and gh api but not gh pr review --body-file. The pr-workflow.md Stage 1 template-failure path uses gh pr review "$PR_NUMBER" --repo "$REPO" --request-changes --body-file /tmp/pr-gate-template.md, which falls outside both documented methods. An agent strictly following this rule might not know --body-file is valid for gh pr review.
The old rule also had an explicit exception for short hardcoded verdicts in gh pr review --approve / --request-changes — that was dropped, but pr-workflow.md still uses inline --body "LGTM..." for Stage 3 verdicts.
Suggested change
| - Comments: read body from file. Use `--body-file FILE` for `gh issue/pr comment`, | |
| - Comments: read body from file. Use `--body-file FILE` for `gh issue/pr comment` | |
| and `gh pr review`, or `gh api -F body=@FILE` when the response ID is needed. | |
| Short verdict strings may use `--body "..."` inline for `gh pr review --approve` | |
| / `--request-changes`. Never `--body @FILE` or `gh api -f body=@FILE` — those | |
| post the path literally. |
— qwen3.7-max via Qwen Code /review
| - Untrusted input: never interpolate issue/PR text into shell | ||
| - Labels: apply existing only, never create | ||
| - Comments: always `--body-file` (except short hardcoded verdicts in `gh pr review --approve` / `--request-changes`) | ||
| - Labels: apply existing only, never create. Do not touch process labels (`welcome-pr`, `maintainer`, `help wanted`, `good first issue`) |
Collaborator
There was a problem hiding this comment.
[Suggestion] The old prompt had an explicit prohibition: "Never close, merge, approve, assign, or remove labels." The new SKILL.md correctly drops "never approve" (Stage 3 calls gh pr review --approve) and "never close" (issue-workflow closes inadmissible issues), but "never merge" was also dropped. The skill never calls gh pr merge, so adding it back wouldn't block any intended flow — and in a pull_request_target workflow with pull-requests: write, a model reasoning "this PR is clearly correct, I'll merge it" would not violate any written rule.
Consider adding after the Labels rule:
- Never merge or assign. Only apply labels, post comments, and approve/request-changes as shown in the workflow templates.— qwen3.7-max via Qwen Code /review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Fixes the automated Qwen triage CI workflow that was posting broken comments and getting cancelled mid-execution.
Three changes:
/triage $NUMBERso the skill framework loads the triage skill identically to local usageevent_nameto the concurrency group key so thatissue_commentevents (even skipped ones) do not cancel in-progresspull_request_targetorissuestriage runs-fto-Fingh apire-run example, clarify--body-filevs--body @semantics, add process label exclusionWhy it's needed
Two problems observed in production:
@/tmp/stage-1.mdas literal comment text instead of file contents (e.g. PR fix(core): add multimodal support for qwen3.7-plus #4803)issue_commentworkflow runs in the same concurrency groupRoot cause:
--promptmode does not trigger skill framework loading, so the agent manually read the skill file and made syntax errors. The concurrency group withoutevent_namelet unrelated events cancel each other.Reviewer Test Plan
How to verify
After merge, trigger the workflow on a real issue or PR:
Confirm:
@/tmp/stage-1.md)issue_commentevents firing in the same windowwelcome-pr,maintainer, etc.) are not touchedNote: this workflow file change only takes effect once merged to
main—pull_request_targetandissuesevents load the workflow from the default branch, not from the PR head. Full validation is therefore post-merge.Evidence (Before & After)
Before — symptoms observed on the unfixed workflow:
Literal
@/tmp/stage-1.mdposted as comment body: fix(core): add multimodal support for qwen3.7-plus #4803 (comment)Triage run cancelled mid-execution by an
issue_commentevent in the same concurrency group: https://github.com/QwenLM/qwen-code/actions/runs/27027823047After — deferred to post-merge. Workflow definitions for
pull_request_target/issuesevents are loaded frommain, so the fix cannot be exercised from this PR's head ref. Will re-run triage on a fresh PR after merge and confirm the two symptoms above are gone.Tested on
CI workflow change; runs on GitHub Actions runners with no local-OS surface.
Environment (optional)
N/A — CI workflow change, no local runtime involved.
Risk & Scope
event_namein the concurrency key,pull_request_targetandissue_commenttriage runs on the same PR are no longer in the same group and can execute concurrently. The skill's comment dedup is marker-based (<!-- qwen-triage stage=N -->+ list-then-POST-or-PATCH) and not transactional — a tight race could double-post a stage comment. The window is small, and the chosen trade-off is "rare visible duplicate" over "every triage run silently cancelled by an unrelated event."issue_comment-cancels-pull_request_targetrace; concurrent-run dedup race window not stress-tested.Linked Issues
Closes #4785
Related to #4784, #4786
中文说明
这个 PR 做了什么
修复 Qwen 自动 triage CI 工作流的两个生产问题:发出来的评论是错的、运行经常被中途 cancel 掉。
三处改动:
/triage $NUMBER,让 skill 框架以和本地完全一致的方式加载 triage skillevent_name,这样issue_comment事件(哪怕被 skip)就不会再 cancel 正在执行的pull_request_target或issuestriage 运行gh apire-run 示例里的-f改成-F,澄清--body-file和--body @的语义差异,补上对流程类 label 的排除为什么需要
线上观察到两个问题:
@/tmp/stage-1.md作为字面文本发成了评论,而不是发文件内容(例如 PR fix(core): add multimodal support for qwen3.7-plus #4803)issue_commentworkflow 运行 cancel 在中途根因:
--prompt模式不会触发 skill 框架加载,所以 agent 是手动去读了 skill 文件、然后写出了带语法错误的命令。concurrency group 没带event_name,导致互不相干的事件互相 cancel。审阅测试计划
如何验证
合并后,在一个真实的 issue 或 PR 上手动触发 workflow:
确认:
@/tmp/stage-1.md这种文件路径)issue_comment事件 cancelwelcome-pr、maintainer等)不会被动到说明:这次的 workflow 文件改动必须合到
main后才会生效 ——pull_request_target和issues事件加载的是默认分支上的 workflow,不是 PR head 上的版本。所以完整验证是 post-merge。证据(Before & After)
Before —— 未修复时观察到的两个症状:
字面
@/tmp/stage-1.md被当作评论正文发出去:fix(core): add multimodal support for qwen3.7-plus #4803 (comment)Triage 运行被同一 concurrency group 里的
issue_comment事件 cancel 在中途:https://github.com/QwenLM/qwen-code/actions/runs/27027823047After —— 推迟到 post-merge。
pull_request_target/issues事件加载的 workflow 来自main,本 PR 的 head ref 没法触发新版本生效。合并后会在一个新 PR 上重新跑一次 triage,确认上面两个症状消失。测试平台
CI workflow 改动;运行在 GitHub Actions runner 上,不涉及本地 OS。
环境(可选)
N/A —— CI workflow 改动,不涉及本地运行时。
风险与范围
event_name后,同一 PR 上的pull_request_target和issue_commenttriage 运行不再在同一个 group,可能并发执行。Skill 的评论去重是基于 marker 的(<!-- qwen-triage stage=N -->+ 先 list 再 POST 或 PATCH),不是事务性的 —— 在很紧的 race 下可能重复发同一阶段的评论。窗口很小,这次的取舍是"罕见但可见的重复评论"优于"每次 triage 都被无关事件静默 cancel"。issue_comment-cancel-pull_request_target的 race;并发运行的去重 race 窗口也未做压力测试。关联 Issue
Closes #4785
Related to #4784, #4786