Triaging a Patrol issue

Turn one incoming issue into a recommendation a human can act on in seconds. You guess; the human decides. Output is a tight summary of what you confirmed vs what you assume — never a wall of text.

This skill is orchestration + a catalog of the issues that actually recur. The catalog lives in references/common-issues.md — read it every run; it's what lets you triage without re-reading dozens of past issues.

Hard rules

• Read-only. Do NOT comment, label, close, or edit the issue. Produce the recommendation (and a ready-to-paste reply the human may choose to send). The human applies labels and posts.
• Don't guess versions or facts. If the version triple, logs, or repro aren't in the issue, that absence is the finding (→ likely "Information needed").
• Reproduction beats theory. The strongest evidence for "Patrol bug" is a repro in Patrol's own dev/e2e_app or a reproducible example the reporter attached; the strongest evidence for "User issue" is that it only breaks in the reporter's project. Reproduce when it's cheap and would sharpen the verdict — and a device-free repro (a patrol_finders widget test, a CLI-only case) is exactly that cheap case: one flutter test/command, no device. Run it during triage instead of theorising.