redhat-developer / redhat-developer/rhdh-plugins

Add local review agent definition with pre-release package context

Open Beginner friendly
#4,799 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature fullsend ready-for-triage Review effort 1/5 triaged
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.