Rhdh pr review
Skill redhat-developer/rhdh-skills/skills/plugins/rhdh-pr-review
Reviews Red Hat Developer Hub pull request code on GitHub in rhdh, rhdh-operator, rhdh-plugins, or community-plugins. Use for a GitHub PR URL or number, "review this PR", analysis-only review, or posting inline comments. For label and merge-readiness triage of the overlay PR backlog, use /rhdh-overlay.From its SKILL.md
npx -y skills add redhat-developer/rhdh-skills --skill rhdh-pr-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 16 stars16 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.7 KB, as published. Nobody here has run it
RHDH Pull Request Review
Keep forge I/O at the edges: fetch produces the PR context, analysis works from that context and checked-out code alone, and posting sends only findings already verified against the head SHA.
Route by outcome
| Outcome | Workflow sequence |
|---|---|
| Code review and post | workflows/fetch-github.md → workflows/review-code.md → workflows/post-to-github.md |
| Analysis only | workflows/fetch-github.md → workflows/review-code.md; stop after the edited draft |
A bare PR URL or number defaults to code review and post.
Review invariants
/code-reviewis required on every draft-review path, including analysis-only. If it is missing, stop, say thatcode-reviewis missing, name/setup-rhdh-skills install, and do not substitute a local two-axis review.- Every
/code-reviewrun also dispatches Adversarial. Team, worktree, and draft steps live inworkflows/review-code.md. - Present the complete edited draft before stating any post operation. An explicit request to post is intent, not approval of the exact write.
Write gate
Fetch and analysis are read-only. Posting a GitHub review is an external write:
invoke the named skill mutation-gate and follow the gate it owns rather than
restating it here. Creating or removing a local git worktree is not that gate.
A review operation's target pins the head SHA. An earlier confirmation of findings approves no write. Report each outcome with the review URL, the verification done, and any recovery still owed.
What each stage carries forward
Every stage passes its result to the next in conversation. The field names are defined once, where they are produced:
| Stage | Result | Defined in |
|---|---|---|
| Fetch | PR context: repository, changeRequest, files, diff, linkedIssues, jiraKeys, existingComments, existingReviews, ciStatus, specSource | workflows/fetch-github.md |
| Analysis | Review draft: changeRequest, summary, verdict, findings, edited, worktreePath | workflows/review-code.md |
Completion
Complete when the report names the head SHA reviewed, has presented the
/code-review Standards and Spec reports, and presents the edited draft.
On the post route, also give the outcome of every approved write with its
target.