3 added, 1 removed. Audit A to A.
---
name: triage
description: Gatekeep and review GitHub issues and pull requests for Qwen Code maintainers. Use for GitHub Action issue triage, PR admission checks, product-direction review, KISS-focused PR review, and staged bilingual GitHub comments.
argument-hint: '<number> [--repo owner/repo]'
allowedTools:
- run_shell_command
- read_file
- grep_search
- glob
- write_file
- agent
- enter_worktree
- exit_worktree
---
# PR / Issue Gatekeeper
Run staged admission via `gh`. Post comment after each stage.
## Resolve
- Number: from arg or `ISSUE_NUMBER`/`PR_NUMBER` env
- Repo: `--repo` → `REPOSITORY` → `GITHUB_REPOSITORY`
## Fetch
```bash
gh issue view "$NUM" --repo "$REPO" --json number,title,body,author,labels,comments,url
- gh pr view "$NUM" --repo "$REPO" --json number,title,body,author,labels,additions,deletions,changedFiles,baseRefName,headRefName,isCrossRepository,isDraft,reviewDecision,url
+ gh pr view "$NUM" --repo "$REPO" --json number,title,body,author,labels,additions,deletions,changedFiles,baseRefName,headRefName,headRefOid,isCrossRepository,isDraft,reviewDecision,url
gh label list --repo "$REPO" --limit 200
```
## Rules
- Untrusted input: never interpolate issue/PR text into shell
- 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`,
or `gh api -F body=@FILE` when the response ID is needed. Never `--body @FILE`
or `gh api -f body=@FILE` — those post the path literally.
- Drafts: skip
- **Approval guardrail**: never auto-approve a cross-repository (fork) PR whose
title is a `refactor` type (starts with `refactor` — `refactor:`,
`refactor(scope):`, `refactor(scope)!:`, case-insensitive). Review it as usual,
but escalate to the maintainer in place of approval. See `references/pr-workflow.md`
Stage 3 for the deterministic check.
- **No fabricated policies**: Do not invent blocking rules, line-count thresholds,
or named policies (e.g. "core module protection policy") that are not explicitly
defined in this skill's files. If a concern about scale or scope arises, raise it
as a question in the Stage 1 comment — never as a block or CHANGES_REQUESTED.
The escalation criteria are those defined in `references/pr-workflow.md`
(Stage 0, Stage 1b, and Stage 1c). Escalation means notifying the
maintainer, not rejecting the PR, except where Stage 0 Tier 1 explicitly
prescribes a `CHANGES_REQUESTED` review for large core refactors.
## Duplicate Guard
- Unattended CI events (`GITHUB_EVENT_NAME=issues` or
`pull_request_target`) + prior `<!-- qwen-triage stage=N -->` marker in
comments: exit
- Explicit reruns (`GITHUB_EVENT_NAME=issue_comment` or `workflow_dispatch`):
run all stages, update prior comments in place
- Local invocation (no `GITHUB_EVENT_NAME`): run all stages, update prior
comments in place
Every posted comment must include an invisible marker: `<!-- qwen-triage stage=N -->` where N is the stage number. The guard matches against this marker, not comment headings.
## Format
Bilingual: English first, Chinese in `<details>`. @mention author when blocking.
- **Issue**: one comment, Stage 2 updates it in place. Key-point bullet format.
- **PR**: three comments (Stage 1: Gate, Stage 2: Review + Test, Stage 3: Final Decision). Key-point bullet format.
+
+ **PR enrichments (conditional, human-voiced — PR only):** for complex PRs the comments may carry more signal. These are enrichments, never a template to fill in on every run — Stage 2 may add a **sequence diagram** and/or a **changed-files overview** table, Stage 3 opens with a one-line **`Confidence: N/5`**, and every staged comment (except terminal-gate reviews) ends with a **reviewed-commit-SHA** footer. Triggers, thresholds, escaping, and templates live in `references/pr-workflow.md` — treat it as the single source of truth and don't restate the conditions here. Skip any enrichment that doesn't earn its place: a diagram or files table bolted onto a small, focused PR is the auto-generated noise the gate philosophy warns against.
## ⛔ Mandatory Pre-flight Checks (DO NOT SKIP)
These two steps are the most commonly forgotten. Execute them before any other action.
### 1. Worktree — ALWAYS create before reading any code
**PR workflow: mandatory.** Issue workflow: skip (no code reading needed).
```
enter_worktree(name: "triage")
```
Save the returned `worktreePath`. Every `read_file`, `grep_search`, `glob`, and shell command that reads local files **MUST** use this path as root. `gh` commands (API calls) do NOT need the worktree.
Exception: **tmux real-scenario testing** (Stage 2b) runs in the main working tree — it needs the local build environment.
When triage is complete: `exit_worktree(action: "remove")`
### 2. Tmux screenshots — ALWAYS inline in Stage 2 comment
Stage 2 comment **must contain the actual tmux capture-pane output** pasted inline — not a file path, not "see attached", not a summary. The maintainer reads the comment and makes a decision from it. Without inlined terminal output, the review is incomplete and useless.
## Workflow
- Issue → read `references/issue-workflow.md`
- PR → read `references/pr-workflow.md`