npx claudepluginhub ai-builder-team/ai-builder-plugin-marketplace --plugin ash[review-aspects]# Comprehensive PR Review Run a comprehensive pull request review using multiple specialized agents, each focusing on a different aspect of code quality. All findings are written to a tracking file, validated, user-triaged, then posted as a single GitHub PR review. **Review Aspects (optional):** "$ARGUMENTS" --- ## Step 1 — Verify PR Exists and Gather Context This command requires an open PR. Run: If no PR is open, **stop immediately** and tell the user: > "No open PR found for this branch. Please open a PR first, then re-run /review-pr." Extract and store: - `PR_NUMBER` — the PR n...
/review-prRuns multi-perspective PR review using specialized agents for code, comments, tests, errors, types, and simplification. Aggregates, dedupes, ranks findings by severity.
/review-prRuns comprehensive PR review using specialized agents for code quality, tests, errors, types, comments, and simplification. Produces categorized issues summary with critical, important, suggestions, strengths, and action plan.
/review-prReviews GitHub pull request via CLI, checking correctness, security, performance, maintainability, testing; outputs verdict, severity-rated findings table, summary, and post option.
/review-prReviews a GitHub pull request for code quality, potential bugs, and improvements using the pr-reviewer agent. Accepts PR number or URL.
/review-prRuns comprehensive PR review using specialized agents for code quality, tests, errors, types, comments, and simplification. Produces categorized issues summary with critical, important, suggestions, strengths, and action plan.
/review-prReviews pull requests using 6-7 parallel specialized agents for code quality, security, tests, frontend, backend, and performance. Supports full, focused, or quick modes.
Run a comprehensive pull request review using multiple specialized agents, each focusing on a different aspect of code quality. All findings are written to a tracking file, validated, user-triaged, then posted as a single GitHub PR review.
Review Aspects (optional): "$ARGUMENTS"
This command requires an open PR. Run:
gh pr view --json number,title,url,headRefName,baseRefName,body
If no PR is open, stop immediately and tell the user:
"No open PR found for this branch. Please open a PR first, then re-run /review-pr."
Extract and store:
PR_NUMBER — the PR numberPR_TITLE — the PR titlePR_URL — the PR URLPR_BODY — the PR descriptionHEAD_BRANCH — the head branch nameBASE_BRANCH — the base branch name (e.g. main)Run the following to get commits on this branch excluding merge commits:
git log origin/main..HEAD --no-merges --oneline
Run the following to get all files changed relative to main:
git diff origin/main...HEAD --name-only
Also get the full diff for agent context:
git diff origin/main...HEAD
Store: list of commits, list of changed files, and the full diff text.
Check if .ignore/ exists at repo root. If not, create it:
mkdir -p .ignore
Create the file .ignore/pr-review-<PR_NUMBER>.md with this structure:
# PR Review: #<PR_NUMBER> — <PR_TITLE>
**Branch**: `<HEAD_BRANCH>` → `<BASE_BRANCH>`
**URL**: <PR_URL>
## PR Description
<PR_BODY>
---
## Commits (excluding merges from main)
<one line per commit: `- <sha> <message>`>
## Changed Files
<one line per file: `- path/to/file`>
---
## Findings
_Populated by review agents — see below._
---
## Validation Results
_Populated by validation agent._
---
## PR Comments Status
_Populated by PR comment agent._
Parse $ARGUMENTS for specific aspects: comments, tests, errors, types, code, simplify, all.
Default (no args or all): run all applicable agents.
Always run:
logical-bug-hunter (new — see below)code-reviewerRun if test files changed (files matching test_*, *.test.*, *.spec.*):
pr-test-analyzerRun if comments or docstrings were added/changed:
comment-analyzerRun if error handling, try/catch, or exception logic changed:
silent-failure-hunterRun if new types, interfaces, schemas, or Pydantic models were added:
type-design-analyzerAlways run last (polish pass):
code-simplifierLaunch all applicable agents simultaneously using the Task tool. Each agent must receive:
git diff origin/main...HEAD)Use subagent_type: general-purpose with this prompt:
You are a logical bug hunter reviewing a pull request.
PR Title: <PR_TITLE> PR Description: <PR_BODY> Changed Files: Full Diff:
<full diff>Your task:
- First, form a clear understanding of what this PR is trying to achieve holistically — read the PR title, description, and all changed code carefully.
- Then, hunt specifically for logical bugs: incorrect conditions, wrong comparisons, off-by-one errors, incorrect business logic, data being used in the wrong order, state mutations that break assumptions, race conditions, incorrect calculations, missing edge cases that the PR's own intent implies should be handled.
- Do NOT flag style issues, formatting, or things covered by linting. Focus only on logic correctness.
Return your findings as a numbered list. For each finding include:
- A one-sentence summary of the bug
- The file and line number (e.g.
services/finance.py:142)- A brief explanation of why it is a logical bug given the PR's intent
If you find no logical bugs, say so explicitly.
Use subagent_type: code-reviewer. Provide the full diff and PR context. Instruct it to return findings as a numbered list with file:line references.
Use subagent_type: pr-test-analyzer. Provide the full diff and PR context.
Use subagent_type: comment-analyzer. Provide the full diff and PR context.
Use subagent_type: silent-failure-hunter. Provide the full diff and PR context.
Use subagent_type: type-design-analyzer. Provide the full diff and PR context.
Use subagent_type: code-simplifier. Provide the full diff and PR context. Instruct it to return simplification suggestions as a numbered list only, not to make any edits.
After all agents complete, collect every finding from every agent and merge them into a single flat numbered list.
Numbering rules:
<N>. **[<agent-name>]** <one-sentence summary> — `<file>:<line>`
<brief explanation if agent provided one>
Update the tracking file — replace the ## Findings section placeholder with the complete numbered list.
Example:
## Findings
1. **[logical-bug-hunter]** Off-by-one in month range calculation causes January to be excluded — `services/finance.py:142`
The loop uses `range(1, month)` but should use `range(1, month + 1)` per the PR's stated intent to include the current month.
2. **[code-reviewer]** Missing authorization check on the new `/export` endpoint — `routers/finance.py:88`
Any authenticated user can export any organization's data; org-scoping is applied to all other endpoints in this file.
3. **[silent-failure-hunter]** Exception swallowed silently in batch processor — `services/batch.py:210`
The except block logs a warning but returns an empty list, hiding the real error from callers.
4. **[pr-test-analyzer]** No test coverage for the edge case where `monthly_data` is empty — `tests/test_finance.py`
The new aggregation logic has a branch for empty data but no test exercises it.
After the tracking file is written, launch a validation agent using subagent_type: general-purpose.
The validation agent must:
.ignore/pr-review-<PR_NUMBER>.md) to get all findings.git diff origin/main...HEAD) and PR context.subagent_type: general-purpose) to:
## Validation Results section of the tracking file with verdicts for every issue:## Validation Results
**Issue 1** [VALID]: Confirmed — `range(1, month)` indeed excludes the current month; the PR description explicitly says it should be included.
**Issue 2** [VALID]: Confirmed — no `require_same_org` dependency is present on the new endpoint unlike all surrounding endpoints.
**Issue 3** [INVALID]: The caller at `routers/batch.py:55` checks for an empty return and raises an HTTPException, so the error is not actually hidden from the client.
**Issue 4** [UNCERTAIN]: The empty-data branch exists but whether it needs a test depends on whether the data pipeline can produce empty results in production — could not determine from the diff alone.
The validation agent should not modify the Findings section — only write to Validation Results.
After the validation agent completes, tell the user:
"The validation agent has finished. Please open
.ignore/pr-review-<PR_NUMBER>.mdand delete any findings you consider invalid (you can use the Validation Results section as a guide). When you're done, come back here and let me know."
Use AskUserQuestion to wait for the user to confirm they have finished triaging.
After the user acknowledges they are done:
.ignore/pr-review-<PR_NUMBER>.md.## Findings section and collect all remaining items (some may have been deleted by the user).## Validation Results section to match the new numbering (remove entries for deleted issues, renumber references).Tell the user how many findings remain after triage.
Launch a PR comment poster agent using subagent_type: general-purpose.
The agent must:
.ignore/pr-review-<PR_NUMBER>.md to get the final numbered findings list.gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/files
Use gh repo view --json nameWithOwner -q .nameWithOwner to get {owner}/{repo}.file:line to a diff position (the line number within the unified diff patch, which is what GitHub's review API requires). The diff position is the line offset within the patch field of the file in the API response.
CRITICAL: Do ALL position mapping locally by parsing the patch string from the API response. NEVER post test comments, validation comments, or trial comments to the PR. The only API write should be the single final review in step 4.gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews \
-X POST \
-f body="Automated review via /review-pr" \
-f event="COMMENT" \
-f "comments[][path]=<file>" \
-f "comments[][position]=<diff_position>" \
-f "comments[][body]=**[<agent-name>]** <full finding text>"
Post one review containing all inline comments at once (not separate API calls per comment).## PR Comments Status section of the tracking file:## PR Comments Status
**Issue 1**: Posted as inline comment on `services/finance.py` line 142.
**Issue 2**: Posted as inline comment on `routers/finance.py` line 88.
**Issue 3**: Skipped — line 210 of `services/batch.py` was not part of the diff (context-only line).
**Issue 4**: Posted as inline comment on `tests/test_finance.py`.
After the PR comment agent completes, report to the user:
## PR Review Complete — #<PR_NUMBER>
**Findings after triage**: X issues
**Comments posted**: Y inline comments on the PR
**Skipped (not in diff)**: Z issues
Tracking file: .ignore/pr-review-<PR_NUMBER>.md
PR: <PR_URL>
When specific aspects are requested, still always run logical-bug-hunter and code-reviewer unless the user explicitly named other aspects without all.