redhat-developer / redhat-developer/rhdh-plugins
Add local review agent definition with pre-release package context
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 48
- Forks
- 120
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 337
Description
What happened
PR #4710 polished the AI Catalog UX across multiple boost workspace packages (~10K line diff, Sep 11–16 2026). The fullsend review agent ran 13 times (8 successful), producing substantive reviews across 9 runs. It consistently flagged three HIGH severity breaking-api findings: (1) subpath export renamed from ./boost-translations-module to ./translations (inline comment), (2) three entity-card extension IDs renamed without migration docs, and (3) changeset missing breaking-change enumeration. The PR author dismissed all three because the boost plugin is unreleased — zero downstream consumers could be affected. The workspace's specifications/CURRENT.md explicitly documents that all packages are at 0.x versions and several are development scaffolding only.
What could go better
The review agent applied standard breaking-change heuristics to a pre-release package, producing three false-positive HIGH findings that required manual dismissal. This happened because: (1) no local review agent definition exists — .fullsend/rhdh/agents/review.md is absent, unlike code.md and fix.md which have local overrides with repo-specific guidance; (2) the review agent has no skills configured (code/fix agents get the rhdh-coding skill); and (3) the workspace AGENTS.md and specifications/CURRENT.md both document release status, but the review agent has no mechanism to discover or act on this context. The false positives wasted reviewer attention and could erode trust in severity calibration over time. Confidence is high — the dismissal rationale is explicit in the PR thread, and the release scope is clearly documented in CURRENT.md. Issue #4507 covers release workflow context but does not address pre-release package detection, making this a distinct gap.
Proposed change
Create .fullsend/rhdh/agents/review.md following the pattern of existing code.md and fix.md in the same directory. The file should instruct the review agent to: (1) check specifications/CURRENT.md in the affected workspace to determine which packages are released vs pre-release before assessing breaking-change severity; (2) treat API surface changes in 0.x or unreleased packages as informational rather than HIGH severity findings; (3) reference the workspace AGENTS.md for domain conventions including the specification-driven development model and openspec contract references. This follows the established local-override pattern and gives the review agent the same level of repo context that code and fix agents already receive through their local definitions.
Validation criteria
On the next 3 boost workspace PRs that include API surface changes (extension ID renames, subpath export changes, or translation key removals), the review agent should not classify them as HIGH severity breaking-api findings for packages that are unreleased or at 0.x versions per CURRENT.md. If HIGH severity is used for such changes, it should reference a specific downstream consumer impact, not a generic breaking-change heuristic.
Generated by retro agent from https://github.com/redhat-developer/rhdh-plugins/pull/4710
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare .fullsend/rhdh/agents/code.md and fix.md, then read workspace AGENTS.md and specifications/CURRENT.md for the release-status and review conventions. Add the local review agent definition with the requested pre-release guidance, and validate it against the stated API-change cases so unreleased or 0.x packages are not marked HIGH without downstream impact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, typescript
- Domain
- developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100