From devpowers
After a git push, find the PR for the current branch, watch CI checks through to completion via the GitHub MCP server, and surface unresolved review comments. On failure, report the failed checks with their run URLs so they can be triaged. Use after every git push, or when the user asks to check PR / CI / review status (e.g. "/check-pr", "/check-pr --comments-only", "check the PR", "is CI green?"). Uses the github MCP server bundled with this plugin (requires GH_TOKEN).
How this skill is triggered — by the user, by Claude, or both
Slash command
/devpowers:check-prThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a PROACTIVE GitHub PR assistant. After EVERY git push, automatically run this skill to verify CI and surface any unresolved review comments. If checks fail, triage them; if reviewers asked for changes, address the threads.
You are a PROACTIVE GitHub PR assistant. After EVERY git push, automatically run this skill to verify CI and surface any unresolved review comments. If checks fail, triage them; if reviewers asked for changes, address the threads.
/check-pr # full flow: PR lookup → CI watch → review comments
/check-pr --comments-only # skip CI watch, only surface unresolved review threads
This skill drives everything through the mcp__plugin_devpowers_github__* tools — the github MCP server bundled with this plugin (its .mcp.json).
mcp__plugin_devpowers_github__list_pull_requests is visible in your tool list, proceed.github MCP didn't connect — almost always because GH_TOKEN isn't set (it authenticates with Bearer ${GH_TOKEN}). Tell the user to export GH_TOKEN=<pat> (a long-lived PAT) and restart Claude Code (or run /reload-plugins), then re-invoke /check-pr. Stop until the server loads.Two cheap shell commands:
git remote get-url origin
git rev-parse --abbrev-ref HEAD
Parse owner/repo from the remote URL. Accept github.com[:/]<owner>/<repo>(.git) and proxied /git/<owner>/<repo> forms. If parsing fails, surface the remote URL to the user and stop — don't guess.
Call mcp__plugin_devpowers_github__list_pull_requests with owner, repo, state: "open", and head: "<owner>:<branch>". If the result is empty, tell the user no PR is open for <branch> — for branches that don't target main/master directly, no PR means no CI. Offer to create one with mcp__plugin_devpowers_github__create_pull_request only if the user explicitly asks; otherwise stop.
If multiple PRs come back (rare), pick the most recently updated and note the others.
Cache the PR number (<pr>) for the rest of the run.
Call mcp__plugin_devpowers_github__pull_request_read with method: "get_review_comments", owner, repo, pullNumber: <pr>. The response contains review threads with isResolved, isOutdated, isCollapsed flags and the comments inside each.
Filter to threads where isResolved == false && isOutdated == false. For each:
databaseId / id in the thread — this is what add_reply_to_pull_request_comment needs).If there are unresolved threads, render a compact summary block:
📝 N UNRESOLVED REVIEW THREAD(S)
ID: <root-id> File: <path>:<line>
Comment: <last comment body>
---
...
Also call mcp__plugin_devpowers_github__pull_request_read with method: "get" to read reviewDecision (APPROVED, CHANGES_REQUESTED, REVIEW_REQUIRED, or null) and surface it.
If invoked with --comments-only, stop here. Otherwise continue to Step 4.
Call mcp__plugin_devpowers_github__pull_request_read with method: "get_check_runs", owner, repo, pullNumber: <pr>. Each check run has name, status (queued / in_progress / completed), conclusion (success / failure / cancelled / skipped / neutral / timed_out), and html_url.
Classify the runs into three buckets:
status != "completed"status == "completed" && conclusion in {"failure", "cancelled", "timed_out"}Print a single SUCCESS block with the PR number, the list of passed checks, and re-run Step 3 (review comments) in case anything came in while CI was running.
Print a FAILURE block listing each failed check by name with its html_url. Then, for each failed check that is GitHub-Actions-backed (the check run's external_id is set and the workflow lives in this repo), fetch the job log through the MCP actions toolset.
Call mcp__plugin_devpowers_github__get_job_logs with owner, repo, job_id: <external_id>, return_content: true, and tail_lines: 30. It returns the tail of the job log directly — no curl, no gh. (It also accepts run_id + failed_only: true to pull every failed job in a run at once, if you'd rather batch.)
get_job_logs comes from the actions toolset, enabled by the X-MCP-Toolsets: all header in the plugin's bundled .mcp.json. If it isn't in your tool list, the plugin's github MCP didn't load — see Step 0. One-off fallback, using the same $GH_TOKEN the MCP server authenticates with: curl -fsSL -H "Authorization: Bearer $GH_TOKEN" -H "Accept: application/vnd.github+json" "https://api.github.com/repos/$OWNER/$REPO/actions/jobs/$JOB_ID/logs".
If a failed check isn't Actions-backed (third-party CI: CodeQL, external integrations), external_id won't map to a job ID. For those, the html_url is the only signal — ask the user to open it and paste relevant lines.
When you have logs, present a tight summary (failed step name + last ~30 lines of error output) rather than dumping the full log. The full log is large — quote selectively.
Do NOT loop polling on a CI failure — stop and let the user direct.
Arm a Monitor that polls the check-runs REST endpoint and emits only on state transitions. Stdout lines wake the session — no sleep, no polling in the main turn.
First, fetch the head SHA: call mcp__plugin_devpowers_github__pull_request_read with method: "get", pullNumber: <pr> and read head.sha. Confirm $GH_TOKEN is set (same token used in 4b); if not, surface that — it's the token the plugin's github MCP authenticates with too (see Step 0).
Then arm a persistent Monitor (substitute <owner>, <repo>, <sha>):
prev=""
while true; do
s=$(curl -fsSL \
-H "Authorization: Bearer $GH_TOKEN" \
-H "Accept: application/vnd.github+json" \
"https://api.github.com/repos/<owner>/<repo>/commits/<sha>/check-runs?per_page=100" || true)
cur=$(jq -r '.check_runs[] | select(.status=="completed") | "\(.name): \(.conclusion)"' <<<"$s" | sort)
comm -13 <(echo "$prev") <(echo "$cur")
prev=$cur
jq -e '.check_runs | all(.status=="completed")' <<<"$s" >/dev/null && break
sleep 30
done
Print a one-line "watching # via Monitor — will report when CI completes" status and end your turn.
When a notification arrives, re-run Step 4 (a single get_check_runs MCP call) for full classification and act per 4a or 4b. The Monitor exits on its own when all checks are terminal; no explicit stop needed. If the user cancels mid-watch, use TaskStop with the Monitor's task ID.
If Step 3 surfaced unresolved threads, address them ONLY (skip resolved/outdated ones).
Fix flow:
mcp__plugin_devpowers_github__add_reply_to_pull_request_comment(
owner, repo, pullNumber: <pr>,
commentId: <root-id>,
body: "[Agent] Fixed - <one line: what was fixed>"
)
Clarification flow (when the comment is ambiguous):
[Agent] Question: <your question> using the same tool — don't guess.Conventions:
[Agent] so it's distinguishable from human replies.add_reply_to_pull_request_comment (keeps the thread together) — do not open a new top-level review.isResolved == false && isOutdated == false threads.After pushing fixes, re-run /check-pr to verify the new CI run and pick up any new comments.
mcp__plugin_devpowers_github__get_job_logs (the actions toolset, enabled by the X-MCP-Toolsets: all header in the plugin's bundled .mcp.json). The only remaining shell touchpoint is the Step 4c Monitor, which polls the REST check-runs endpoint with the same $GH_TOKEN because a Monitor can't call MCP tools mid-loop.Monitor is session-bound. If the session ends before CI completes, the monitor dies; the next /check-pr will pick up wherever things are.git-commit, manual edits + push). /check-pr only observes and reports.npx claudepluginhub kolodkin/devpowers --plugin devpowersCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.