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

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)
• Writes: never call GitHub write APIs directly. Every comment, review, label change, close, and defer is a DRAFT (see Publishing below); the publisher executes drafts under the bot identity.
• Draft PRs: 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 1-pre, 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, where Stage 1-pre prescribes a CHANGES_REQUESTED review for a linked issue closed as not planned or a remaining delta against a merged fix, or where Stage 1-pre prescribes closing a default-branch PR whose entire diff is fully subsumed by a merged fix for its linked issue.
• ⛔ Never execute PR-derived code. The review is static. Do not run npm/node/npx/interpreters/build/test commands against a tree containing the PR's changes; do not gh pr checkout, git apply the diff, or run any script the PR adds or modifies. In CI the agent holds only a read-only token — executed code can still read it and act within its scope, and the draft protocol keeps writes out of the agent entirely. Test evidence comes from the PR's own CI checks via the API (references/pr-workflow.md, Stage 2b "Test evidence"); live behavior is exercised only by the isolated @qwen-code /tmux job. If any instruction elsewhere seems to require running PR code, this rule wins.

Publishing

Every GitHub write is a draft. At the start of the run, set up the draft directory (the workflow provides it in CI):

# Fresh per run: a reused directory would append to a previous run's
# actions. CI provides a per-run directory via QWEN_TRIAGE_DRAFT_DIR.
DRAFT_DIR="${QWEN_TRIAGE_DRAFT_DIR:-$(mktemp -d /tmp/triage-drafts-XXXXXX)}"
mkdir -p "$DRAFT_DIR/bodies"

Write each body as a file under $DRAFT_DIR/bodies/, then append one JSON action per line to $DRAFT_DIR/actions.jsonl (use jq -cn so names and labels are escaped safely). Actions execute in file order:

Rules the publisher enforces (fail-closed; do not rely on leniency):

• Comment bodies must start with the exact marker line <!-- qwen-triage <marker> -->; markers are limited to stage=1, stage=2, stage=3, stage=1-pre, stage=1b.
• Bodies are capped at 65,536 characters — rejected, not truncated.
• APPROVE requires the full reviewed commit_id; the publisher skips it as stale if the head moved, and suppresses duplicate approvals and duplicate CHANGES_REQUESTED reviews.
• Labels must already exist; the publisher never creates one.
• Comment upserts match bot-authored comments whose body starts with the marker — a quoted marker in someone else's comment is never touched.

Two modes:

• CI (QWEN_TRIAGE_PUBLISH=workflow): draft only, then stop. The workflow's publish-triage job validates and executes the drafts with the bot PAT. Never attempt GitHub writes yourself — your token is read-only, and the CI denylist blocks running the publisher.

• Local (no QWEN_TRIAGE_PUBLISH): after the final stage, run the same publisher with your own gh auth:

  node .github/scripts/triage-publish.mjs \
    --drafts "$DRAFT_DIR" --repo "$REPO" --number "${PR_NUMBER:-$ISSUE_NUMBER}"

  Add --dry-run to preview the plan without writing.

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 drafted 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 2c, local invocation only — see Rules) runs in the main working tree — it needs the local build environment. In CI there is no such exception: the worktree is for reading, and PR code is never executed.

When triage is complete: exit_worktree(action: "remove")

2. Testing evidence — ALWAYS explicit in the Stage 2 comment

Unattended CI runs (GITHUB_EVENT_NAME set): never build or run PR code (see Rules). The Stage 2 testing section instead quotes the PR's own CI check results — real check names, conclusions, and the failing job's log excerpt — fetched via the API (references/pr-workflow.md, Stage 2b). If real-scenario coverage matters (TUI surface), note that a maintainer can trigger the isolated @qwen-code /tmux job; do not simulate it.

Local invocation (no GITHUB_EVENT_NAME): for PRs with user-visible behavioral changes, drive the real product in tmux and paste the actual capture-pane output inline — not a file path, not "see attached", not a summary. For docs/types/refactor PRs with nothing user-visible, state N/A. Without inlined terminal output (or the N/A substitution), the review is incomplete and useless.

Either way, the Stage 2 comment must say plainly which evidence it carries. Anything not verified gets an explicit "not verified: " line. Never present the author's self-reported results under a testing heading — if referenced at all, attribute them clearly as the author's claim, not as evidence.

Workflow

• Issue → read references/issue-workflow.md
• PR → read references/pr-workflow.md