Help us improve
Share bugs, ideas, or general feedback.
From gh-ops
Self-reviews a GitHub PR via <PR_URL>: checks CI status, merge conflicts, diff noise, description consistency, commits, reviewability; identifies issues and suggests fixes.
npx claudepluginhub mh4gf/tqHow this command is triggered — by the user, by Claude, or both
Slash command
/gh-ops:self-review <PR_URL>This command is limited to the following tools:
The summary Claude sees in its command listing — used to decide when to auto-load this command
# Self-Review **Goal: Make the PR worth a reviewer's time.** Complete quality checks and prerequisite verification, then mark ready if everything passes. Not an exhaustive code review. Focus on "obvious issues you can catch before submitting" and "prerequisites for marking ready." ## Phase 1: Analysis (no changes) Collect findings only. Do not make fixes or post comments. ### 1. CI status check If failures/errors exist → check the job logs and identify the cause. **IMPORTANT: On CI failure, skip the remaining steps (3–8) and start fixing CI immediately.** Reviewing diffs or descrip...
/review-prReviews GitHub PR by number or URL using multi-agent verification across changes, posting structured feedback. Supports --no-interactive mode.
/reviewReviews a GitHub pull request: parses PR number or URL, fetches metadata and diff with gh CLI, gathers user context, produces structured review document.
/pr-reviewRuns a comprehensive PR review, posts results as comments, then independently assesses each finding to separate genuine issues from nitpicks and false positives.
/pr-feedbackClassifies PR review comments by priority (must/imo/nits/q), analyzes CI errors with 3-step root cause method, generates ordered response plans, and verifies fix quality.
/pr-enhanceAnalyzes git changes between branches, generates file lists, stats, categorizations, impacts, and comprehensive PR descriptions for efficient reviews.
/pr-feedbackClassifies PR review comments by priority (must/imo/nits/q), analyzes CI/build errors via 3-step root cause method, generates ordered action plan with fixes and verification steps.
Share bugs, ideas, or general feedback.
Goal: Make the PR worth a reviewer's time. Complete quality checks and prerequisite verification, then mark ready if everything passes.
Not an exhaustive code review. Focus on "obvious issues you can catch before submitting" and "prerequisites for marking ready."
Collect findings only. Do not make fixes or post comments.
gh pr checks $ARGUMENTS
If failures/errors exist → check the job logs and identify the cause.
IMPORTANT: On CI failure, skip the remaining steps (3–8) and start fixing CI immediately. Reviewing diffs or descriptions while CI is broken is wasted effort since CI fixes will invalidate them. After fixing and pushing, restart the self-review from the beginning.
gh pr view $ARGUMENTS --json mergeable,mergeStateStatus
mergeStateStatus is "DIRTY" and mergeable is "CONFLICTING" → conflicts exist.
IMPORTANT: On conflict detection, skip the remaining steps (3–8) and start resolving conflicts immediately. Reviewing diffs while conflicts exist is wasted effort. After resolving and pushing, restart the self-review from the beginning.
gh pr diff $ARGUMENTS
Look for:
If the diff is large (roughly 400+ lines) → note as a split candidate.
gh pr view $ARGUMENTS --json body,title
Check:
gh pr view $ARGUMENTS --json commits
Read the diff from a reviewer's perspective:
Identify places where a reviewer would ask "why?" — the ideal outcome is a zero-comment Approve.
Look for:
Record resolution for each:
${CLAUDE_PLUGIN_ROOT}/scripts/gh-unresolved-threads $ARGUMENTS
If unresolved comments exist → record as a finding. Handle via /gh-ops:respond-review $ARGUMENTS.
MUST: Present all findings to the user and discuss the resolution for each. Do not start fixing without agreement.
Report findings in this format:
| # | Category | Detail | Proposed action |
|---|---|---|---|
| 1 | CI failure | Log summary | Fix approach |
| 2 | Conflict | N files conflicting | Resolution approach |
| 3 | Noise | Location | Remove or justify |
| 4 | Unresolved comments | N threads | Handle via respond-review |
| ... | ... | ... | ... |
For items requiring judgment (value selection, naming, design decisions), provide precedent research and rationale.
If 0 findings → report that and finish.
Implement fixes per the agreed plan. For unresolved comments, follow /gh-ops:respond-review $ARGUMENTS.
After completing Phases 1–3, decide whether the PR can be marked ready for review.
IMPORTANT: If any concern remains, do NOT propose marking ready. Report the concern and wait for user instructions.
gh pr view $ARGUMENTS --json isDraft
If isDraft: false → report "This PR is already marked as ready" and end Phase 4.
If isDraft: true → proceed to the steps below.
Determine prerequisites for marking this PR ready based on task info, diff, and PR description. Confirm with the user.
Check:
If prerequisites exist → confirm status with the user. Block ready if any are incomplete.
Propose marking ready ONLY if ALL of the following are true:
Even when proposing ready, wait for user approval. Never auto-execute.
gh pr ready $ARGUMENTS