| name | watch-opencode |
| description | Watch a PR's OpenCode review and notify the user when it finishes. Polls the OpenCode workflow run (opencode-review.yml, or the /oc-triggered opencode-comment.yml) until it settles - following supersede when a new push cancels an in-flight review - then reads OpenCode's comment, summarizes its findings, and pings the user via their preferred method (default: a completion chime + treemux attention + an in-chat summary). Use when the user wants to be told when the OpenCode bot is done reviewing a PR, e.g. 'watch the opencode review and let me know when it's done', 'ping me when opencode finishes on PR 1485'. |
Watch OpenCode
Wait until the OpenCode bot has finished reviewing a pull request, then tell the user what it found. OpenCode runs as a GitHub Action (anomalyco/opencode/github) and posts its output as a top-level PR comment authored by github-actions[bot]. This skill blocks on the run in the background, so it costs almost nothing while waiting and wakes you exactly once - when OpenCode is done.
What "done" means here
OpenCode never literally writes "done". Each run posts one fresh issue comment with its findings (or a short "nothing to raise" note), so the authoritative completion signal is the workflow run status, not the comment text. Two workflows can produce that comment:
opencode-review.yml ("PR Review") - the automatic reviewer. Runs on every push (synchronize) and uses cancel-in-progress concurrency, so a new push cancels the in-flight review and starts a new one. This skill follows that chain and only reports the review of the current tip.opencode-comment.yml ("OpenCode Comment Trigger") - fires when someone comments /oc or /opencode; this OpenCode can also push commits.
The helper script handles both and resolves the most recent run automatically.
Steps
1. Resolve the PR
- If the user gave a PR number or URL, use it.
- Otherwise use the current branch's PR:
gh pr view --json number,url,headRefName,state.
- If there is no PR, tell the user and stop.
Store the PR number (call it PR).
Sanity-check that OpenCode will actually run: the review is skipped on draft PRs, bot-authored PRs, and fork PRs (see opencode-review.yml). If the PR is a draft, say so - OpenCode won't review it until it's marked ready.
Check for merge conflicts before launching the watcher. A PR that conflicts with its base has no computable refs/pull/N/merge ref, so pull_request-triggered workflows - the CI checks AND the OpenCode review - never run. The watcher would then block until its ~75-min timeout for a run that will never appear. Query the mergeability:
gh pr view <PR> --json mergeable,mergeStateStatus,baseRefName
If mergeable is CONFLICTING (equivalently mergeStateStatus is DIRTY), do not launch the watcher: tell the user the branch has conflicts with its base and that CI/OpenCode cannot run until they are resolved, and ask whether they want to resolve them (this skill is read-only and never resolves conflicts itself). mergeable is computed asynchronously by GitHub and is briefly UNKNOWN right after a push - if you get UNKNOWN, wait a few seconds and re-query once before deciding.
2. Launch the watcher in the background
Run the helper in the background (run_in_background: true) so it survives past a single turn and re-invokes you when OpenCode settles:
.claude/skills/watch-opencode/scripts/watch-opencode.sh <PR>
It blocks until the newest OpenCode run on the PR's branch is completed and no superseding run is pending, then prints one line:
OPENCODE_RESULT {"runId":..,"status":"completed","conclusion":"success","headSha":..,"url":..,"name":"PR Review"}
Notable conclusion values:
success / failure / cancelled - the run's real conclusion.none - no OpenCode run exists for this PR (draft / fork / bot PR, or nothing triggered it). Report that instead of waiting further.timeout - the safety backstop (~75 min) fired before it settled; re-launch or investigate.
Do not poll it yourself with sleep loops - the background process notifies you on exit. If you need a fallback heartbeat, ScheduleWakeup at a long interval (1200s+), but normally just wait for the completion notification.
3. Read OpenCode's comment
Once the watcher exits, fetch the newest github-actions[bot] issue comment on the PR - that's OpenCode's output for this run:
gh api "repos/{owner}/{repo}/issues/<PR>/comments" \
--jq '[.[] | select(.user.login=="github-actions[bot]")] | last | {body, html_url, created_at}'
- If
conclusion was success but the comment predates the run, the run may have posted nothing new - link the run (url) so the user can check logs.
- If
conclusion was failure, OpenCode errored (often an OpenRouter/model hiccup) and likely posted no findings - report the failure with the run URL, don't invent findings.
Read the comment body and distill it: the real bugs/security/perf/UX items (lines prefixed [BUG], [SECURITY], [PERF], [UX], [CONVENTION], etc.), separating genuine findings from a "nothing to raise" all-clear.
4. Notify the user
Notify via the user's preferred method if they named one (e.g. they said "ping me on Slack"); otherwise use the default:
- Completion sound (macOS):
afplay /System/Library/Sounds/Glass.aiff
- treemux attention so the sidebar flags this worktree: call
needs_attention with a one-line summary (the user may be on another worktree).
- In-chat summary: PR link, run conclusion, and OpenCode's key findings as a short bulleted list, with a link to the full comment (
html_url). If OpenCode raised nothing, say so plainly.
Set treemux status to done (or error if the run failed).
Notes
- Everything here is read-only on GitHub - the skill never comments, pushes, or re-triggers anything. It only observes.
- OpenCode posts a new comment per run, so "the latest
github-actions[bot] comment" is this run's output; older comments are prior reviews of earlier commits.
- If the user keeps pushing, the watcher keeps following the supersede chain and reports only once the tip's review settles - which is usually what "tell me when it's done" means.
