By name: rhdh-pr-review description: > Review pull requests: code-level analysis with inline comments, and live cluster testing for rhdh-operator PRs. Supports GitHub (GitLab planned). Use when asked to review a PR, review code, post review comments, test PR changes on a cluster, deploy PR images for testing, or do a full PR review. Also use when given a PR URL or number and asked for feedback, or when user mentions "review this PR", "PR review", "code review", or "test this PR on my cluster".
For cluster testing workflows, set up the orchestrator CLI:
RHDH=../rhdh/scripts/rhdh
What would you like to do?
Code Review
- Review PR code — Analyze a PR diff, generate findings, and post inline comments
- Review PR code (analysis only) — Analyze without posting (e.g., to review locally or post later)
Cluster Testing (rhdh-operator PRs)
- Test PR on cluster — Deploy PR operator bundle on a live RHDH cluster and verify changes
Combined
- Full review — Code review + post to GitHub + cluster testing
Wait for response before proceeding.
| Response | Workflow |
|---|---|
| 1, "review", "review PR", "code review", a PR URL or number | workflows/fetch-github.md → workflows/review-code.md → workflows/post-to-github.md |
| 2, "analyze", "analysis only", "review locally" | workflows/fetch-github.md → workflows/review-code.md (stop after findings) |
| 3, "test", "cluster", "deploy", "operator PR", "test on cluster" | workflows/fetch-github.md → workflows/review-operator-pr.md |
| 4, "full", "full review", "both" | workflows/fetch-github.md → workflows/review-code.md → workflows/post-to-github.md → workflows/review-operator-pr.md |
Routing rules
- PR URL or number with no other context: default to route 1 (code review + post).
- rhdh-operator PR detected (repo is
redhat-developer/rhdh-operator): suggest route 4 (full review) but let the user choose. - "review" without "post" or "cluster": route 1.
- All routes start with fetch. The fetch workflow produces a context artifact consumed by all downstream workflows.
Forge detection
Currently GitHub only. Detect from URL pattern or gh CLI availability.
When GitLab support is added: fetch-gitlab.md and post-to-gitlab.md will slot into the same pipeline. The analyze workflow (review-code.md) is forge-agnostic and needs no changes.
Context artifact (fetch → analyze / cluster test)
Produced by the fetch workflow, consumed by all downstream workflows:
context artifact
├── forge: "github"
├── repo: "owner/repo"
├── pr_number: 123
├── head_sha: "abc123..."
├── base_ref, head_ref, title, body, author, state, url
├── labels: [...]
├── files: [{path, additions, deletions}, ...]
├── total_additions, total_deletions
├── diff: "full unified diff"
├── linked_issues: [{number, title, body, labels, state}, ...]
├── jira_keys: ["RHIDP-1234", ...]
├── existing_comments: [{user, path, line, body, created_at}, ...]
├── existing_reviews: [{user, state, body}, ...]
└── ci_status: "pass" | "fail" | "pending" | "unknown"
Findings artifact (analyze → post)
Produced by the analysis workflow, consumed by the posting workflow:
findings artifact
├── pr: {repo, number, head_sha}
├── summary: "top-level review text"
├── event: "COMMENT" | "APPROVE" | "REQUEST_CHANGES"
└── findings[]
├── path, line, start_line
├── type: "suggestion" | "question" | "observation"
└── body: "comment text"
| Reference | Purpose | Load when... | Path |
|---|---|---|---|
| review-perspectives | Review perspective examples and signal hints | Running review-code.md |
references/review-perspectives.md |
| operator-pr-images | CI image extraction and validation | Running review-operator-pr.md |
references/operator-pr-images.md |
| github-reference | gh CLI patterns, PR queries | Running any GitHub workflow | ../rhdh/references/github-reference.md (if available) |
| rhdh-repos | RHDH ecosystem repository map | Cluster testing | ../rhdh/references/rhdh-repos.md (if available) |
| Skill | Purpose | Path |
|---|---|---|
| rhdh | Orchestrator, environment status, activity tracking | ../rhdh/SKILL.md |
Code review
- PR context fetched (metadata, diff, linked issues, existing comments)
- Review perspectives chosen based on PR content
- Findings verified against actual code at HEAD
- False positives dropped with reasoning shown
- Review draft presented to user with event type choice
- Review posted to forge (if posting route selected)
Cluster testing
See workflows/review-operator-pr.md <success_criteria> for the full checklist.
Full review
All code review criteria + all cluster testing criteria.