OpenTagViewer: Skill for Claude Code

Watching a PR through to a verdict

A pushed PR is not finished work. It is work awaiting a verdict that gh can read — so read it, and say what happened. Offer this every time a PR is pushed, unless told otherwise.

Arm a Monitor. Do not poll in a loop, and do not go idle waiting. The notification arrives on its own; keep working on the next thing in the meantime.

The trap this skill exists for

A monitor that emits nothing looks exactly like a monitor watching something that has not happened yet. Silence is not success. One was armed on PR #97 here, produced nothing for its whole lifetime, and exited 0 — and the PR's status was found by hand, while the monitor was still believed to be running.

So: run the poll body once in the foreground first, and see it print. One Bash call. If it prints nothing there, it will print nothing for the next half hour either.

# Prove it emits BEFORE arming anything.
PR=99
gh pr view "$PR" --json statusCheckRollup --jq \
  '.statusCheckRollup[] | select(.status == "COMPLETED") | "\(.name): \(.conclusion)"'

First check whether this PR gets checks at all

An empty rollup is not "too early" — it may mean nothing will ever run.

gh pr view <n> --json statusCheckRollup,baseRefName \
  --jq '{base: .baseRefName, checks: (.statusCheckRollup | length)}'

Two independent reasons it comes back zero, and the second one is invisible in the diff:

• Path filters. Every workflow here is filtered (app/**, scripts/**, gradle/**, pyrightconfig.json, .flake8), so a PR touching only docs, .gitattributes, .claude/, or .github/ itself produces nothing.
• A base that is not main. Every workflow is pull_request: branches: [ "main" ], so a stacked PR gets no checks whatsoever, however much application code it touches. This is the one that catches you out: the obvious test — "does the diff touch a filtered path?" — says yes, and still nothing runs. Seen on #105, which changed app/** heavily and had a rollup of zero because it was based on the branch of #104.