Immutable. This exact content is served forever at /api/v1/blob/7c7fa33ae7df9ebc.
--- 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,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`