Skip to content

[review.agent] Wrap review summary and inline comments in collapsible <details> blocks #35226

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kubaflo wants to merge 1 commit into from
Closed

[review.agent] Wrap review summary and inline comments in collapsible <details> blocks #35226

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 40 additions & 1 deletion .github/workflows/shared/review-shared.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -137,7 +137,46 @@ Before posting inline comments, validate **both**:

**Cap inline comments at 30** (the safe-output limit). If more than 30 findings, post the 30 most severe inline and include the rest in the review summary body.

The review body must include:
#### Collapsible formatting (required)

Wrap **both** the review summary body and every inline comment body in `<details>` blocks so reviewers see one-line headers in the timeline by default and only expand what's relevant. This keeps low-severity findings out of the way without filtering them.

**Review summary body** (passed to `submit_pull_request_review`) — must follow this exact structure:

Comment on lines +144 to +145
Copy link

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The instructions say the review summary body “must follow this exact structure”, but the next bullets require switching between <details> and <details open> based on the verdict. Consider rewording to explicitly allow that single conditional variation (e.g., “exact structure, with <details> open/closed depending on verdict”) so the orchestrator doesn’t treat <details open> as violating the required template.

Copilot uses AI. Check for mistakes.
```html
## 🤖 Expert Code Review

<details>
<summary>{verdictDot} <strong>{verdictLabel}</strong> — <a href="https://github.com/{owner}/{repo}/commit/{commitFull}"><code>{commitSha7}</code></a> · <strong>{prTitle}</strong></summary>

[full review body: methodology, overall assessment, findings table, discarded findings, test coverage, summary]

</details>
```

Where:
- `{verdictDot}` / `{verdictLabel}` is one of: `🟢 LGTM` (no 🔴/🟡 findings), `🟡 Changes Suggested` (any 🟡 MODERATE), `🔴 Changes Required` (any 🔴 CRITICAL), `🟠 Discussion Needed` (architectural concerns flagged).
- `{commitSha7}` is the 7-character short SHA of the head commit being reviewed; `{commitFull}` is the full SHA used in the link.
- `{prTitle}` is the PR title at the time of review.
- Use `<details open>` (open by default) when the verdict is 🔴 or 🟡 so reviewers see findings without an extra click. Use `<details>` (closed) for 🟢 LGTM.
Copy link

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The “open by default” guidance only covers 🔴 and 🟡 verdicts, but the template also defines 🟠 “Discussion Needed”. That case is currently unspecified and may end up closed by default; consider stating whether 🟠 should also use <details open> (likely) to avoid hiding important architectural/discussion notes.

Suggested change
- Use `<details open>` (open by default) when the verdict is 🔴 or 🟡 so reviewers see findings without an extra click. Use `<details>` (closed) for 🟢 LGTM.
- Use `<details open>` (open by default) when the verdict is 🔴, 🟡, or 🟠 so reviewers see findings or architectural discussion without an extra click. Use `<details>` (closed) for 🟢 LGTM.

Copilot uses AI. Check for mistakes.
- Do **not** include a timestamp or finding-count tally in the summary line.

**Inline comment bodies** (each `create_pull_request_review_comment` call) — must follow this exact structure:

```html
<details>
<summary>{severityDot} <strong>{severityLabel}</strong> — {one-line headline} ({N}/3 reviewers)</summary>

Comment on lines +168 to +169
Copy link

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inline comment summaries hardcode "({N}/3 reviewers)", but Step 2 explicitly allows a 2-reviewer fallback when only 2 sub-agents complete successfully. In that scenario the inline header would be inaccurate; consider making this "({N}/{totalReviewers} reviewers)" or omitting the denominator when fewer than 3 reviewers contributed.

Copilot uses AI. Check for mistakes.
[full finding body: explanation, references, recommendation]

</details>
```

Where `{severityDot}` / `{severityLabel}` is `🔴 CRITICAL`, `🟡 MODERATE`, or `🟢 MINOR`. Always closed by default — the summary line carries enough information to decide whether to expand.

#### Required body content

The review body inside the `<details>` block must include:
- All findings ranked by severity (🔴 CRITICAL, 🟡 MODERATE, 🟢 MINOR)
- Consensus markers (e.g., "3/3 reviewers", "2/3 reviewers") for each finding
- Methodology note: "3 independent reviewers with adversarial consensus"
Expand Down
Loading