track-whose-courtlisted

# Track whose court the ball is in ## Purpose A maintainer can reach you on any of several channels, and hand-checking one of them silently misses the rest. The failure mode is concrete: reporting an issue as "0 comments, untouched" when a committer had commented that day — in a channel you weren't querying. To answer "is anything waiting on me?" honestly, you have to sweep *all* the channels, then compare the last human commenter to yourself to decide whose turn it is. This ships as a runnable tool (`tools/check-status.sh`) so the sweep is complete by construction, not by memory. Scope note: the tool is wired for Apache Solr / Lucene / Jetty (GitHub + ASF JIRA + lists.apache.org). The *method* is general; the specific endpoints and the JIRA/ mailing-list steps are ASF-shaped, hence `scope: apache/solr`. ## When to use - Any "check status", "whose turn is it", or "anything waiting on me" request. - Before a stand-up-style summary of open PRs/issues. - Deciding nudge-vs-wait on a specific thread. ## When NOT to use You already know a specific claim needs proving before you post it — that's verify-before-a-committer-comment; this skill answers *whose turn*, not *is my claim true*. ## The practice (checklist) Check **all six channels** a maintainer can use, plus git diffs as a seventh: - [ ] 1. GitHub PR issue-comments — `gh api repos/<repo>/issues/<n>/comments` - [ ] 2. GitHub inline review-comments — `gh api repos/<repo>/pulls/<n>/comments` - [ ] 3. GitHub reviews (AP