watchlistlisted

# Watchlist Track upstream work the user is blocked on (issues, PRs, releases) and report movement. The state lives in `~/.claude/watchlist.json`. Each entry records why the user cares and what "resolved" looks like — read those fields before reporting, because raw GitHub state (open/closed) is often not the real question. Example: a PR may merge but only add CLI support, while the user is waiting for *server* support. **At a glance:** parse the argument into a subcommand (`check` / `add` / `remove` / `list`) → for a check, hit the GitHub API for every item in one Bash call, compare against each entry's `last_state`, and judge any movement against `waiting_for` → rewrite the JSON → report verdict-first. The core skill is the relevance judgment, not the raw open/closed. ## Subcommands Parse the argument string: - *(no args or "check")* — check every item, report changes, update stored state. - `add <github url or owner/repo#123> [note about why]` — fetch current state, ask nothing, infer `waiting_for` from the note/conversation, append to the JSON. - `remove <id or fragment>` — delete the matching entry (confirm if ambiguous). - `list` — print the table from stored data without hitting the network. ## How to check Use the GitHub REST API unauthenticated via curl (rate limit 60/hr is plenty; fall back to `gh api` if curl gets 403-rate-limited and gh is authenticated): ```bash # issues AND pull requests both work through the issues endpoint: curl -s -m 15 https://api.g