pr-summary

Constraint:

• Apply @rules/php/core-standards.mdc
• Apply @rules/git/general.mdc
• Apply @rules/jira/general.mdc when the target is a JIRA issue
• Apply @rules/reports/general.mdc — the published comment must be written in the language of the source assignment (Czech assignment → Czech comment; English assignment → English comment). Code identifiers stay verbatim per the rule's Scope clarifications.
• If the current project uses Laravel, also apply @rules/laravel/laravel.mdc, @rules/laravel/architecture.mdc, @rules/laravel/filament.mdc, and @rules/laravel/livewire.mdc
• Focus on the "why" and business impact, not on implementation details — but keep enough technical context (which integration, payload, table, endpoint, etc.) that a developer can still follow what changed.
• Do not include code snippets, file paths, line numbers, or diff fragments. The summary is for humans, not for static analysis.
• GitHub target only — always credit the real change author(s) (the JIRA non-technical comment omits the Authors line entirely; this metadata applies to the GitHub PR comment / linked-GitHub-issue mirror). Credit the real change author(s), not the agent or identity running the CR / publishing step. Extract authors from git commit history (git log --pretty='%an <%ae>' base..HEAD | sort -u) and from PR metadata (author.login and commits[].author.login returned by skills/code-review-github/scripts/load-issue.sh). When the target is GitHub, prefer @github-handle; when the target is JIRA, prefer the JIRA-account display name returned by the JIRA loader, otherwise fall back to the git Name <email>. Multiple authors are listed comma-separated in commit order. Never silently drop the Authors line — when authorship cannot be determined, write "Authors: unknown — git history did not yield a recognisable identity".
• Always flag changes that are reachable only behind a test / opt-in parameter (feature flag, ENV switch, query-string parameter, request header, A/B variant, beta toggle, allow-listed account). When the diff shows a guard such as config('feature.x'), env('SOMETHING_ENABLED'), GrowthBook / Unleash / LaunchDarkly check, a query-string ?debug=, a request header gate, or a hard-coded allow-list, surface the exact toggle and the value required to reach the change: on the GitHub target as an "Available behind" line; on the JIRA target folded into How to test step 1 (which enables the toggle before the tester proceeds). Omit it only when the change is reachable by every user unconditionally.
• Every comment opens with a TL;DR. Both targets render a TL;DR section at the top of the body (directly below the {assignment_verdict} slot when one is rendered): one or two sentences, in the assignment language, naming what changed and why in plain language — the user-visible outcome, not the implementation. It must stand on its own, so a reader who stops there still knows what shipped. It is never omitted and never conditional. Keep it to two sentences: a TL;DR that grows into a paragraph is a Summary of changes, which the GitHub target already carries below and the JIRA target deliberately does not.
• Output depends on the target tracker:
  • GitHub target — output the three required sections plus the two metadata lines defined in templates/pr-summary-github.md: TL;DR, Authors, the conditional Available behind, Summary of changes, and How to test. No categories, no breaking-changes section, no testing-notes section.
  • JIRA target — output only TL;DR and How to test plus the conditional embedded blocks (see below). The JIRA non-technical comment stays intentionally minimal: no Authors line, no Summary of changes section, no Available behind metadata line. When the change is reachable only behind a test parameter, fold that toggle into How to test step 1 instead of a separate line. The JIRA audience gets a two-sentence TL;DR and exactly how to test the change, and nothing else unless the wrapper passes a clarifying-questions or assignment-compliance block.
• No leaked markup on JIRA. When the target is JIRA, the rendered body must contain only JIRA Wiki Markup — never a Markdown control character that JIRA would show as literal text. Before publishing, scan the body and convert / reject any **bold** / __bold__ (→ *bold*), #/##/### ATX headings (→ h1./h2./h3.), `code` (→ {{code}}), fenced ``` blocks (→ {code}…{code}), - / + bullets (→ *), and Markdown links [label] + (url) (→ [label|url]) per @rules/jira/general.mdc. The reader must never see a raw ** or #.
• Embedded blocks (consolidation contract — issue #498): when the calling CR wrapper passes extra markdown blocks (the Clarifying questions block and/or the Assignment Compliance block returned by @skills/assignment-compliance-check/SKILL.md), append them verbatim after How to test and before the template's signature footer. Each embedded block must already be in the target tracker's markup (GitHub Markdown for GitHub, JIRA Wiki Markup for JIRA — the wrapper converts before passing). A Clarifying questions block arrives already filtered by the wrapper per @rules/code-review/general.mdc Clarifying Questions — Answered-Question Suppression & Severity Gate (issue #758) — questions the tracker thread already answered and the diff implements are gone, only Critical / Moderate ones remain, and no severity label or count is attached; append it as received and never re-rate, re-order, or annotate it. The resulting comment is published once per linked tracker target — that single consolidated comment is the only non-technical artifact a CR run posts on each linked issue or JIRA ticket. When no embedded blocks are passed, the template renders without that slot exactly as before.
• Assignment / Functional verdict (top banner — affirmative exception, issue #737): whenever the calling CR wrapper passes an Assignment Compliance embedded block — i.e. a tracker is linked and @skills/assignment-compliance-check/SKILL.md ran — render a single prominent verdict line at the very top of the comment (the {assignment_verdict} slot), in the assignment language, stating the Goal met outcome and pointing to the Assignment Compliance detail below: on a gap run, the non-compliance line naming the gap count N; on a clean run, the fully affirmative report naming the total acceptance-criteria count N. This guarantees the reader sees whether the assignment was met without scrolling to the appended block. Derive N from the passed block's Goal met verdict and the count of Not met / Partial / Divergent entries (gap run) or the total acceptance-criteria count (clean run). When no Assignment Compliance block is passed (no tracker is linked), omit the slot entirely. Rendering the positive line on a clean run is the deliberate, narrow affirmative exception to the report-only-what-needs-action convention (@rules/code-review/general.mdc Two-part CR output — Technical & Functional review), scoped to this banner alone.