docs(agents): clarify user-visible PR review feedback (#2910)

Agents will often give a ton of feedback, but it can be hard to quantify the
impact of the issue the feedback is about.

This change updates the PR review feedback template to be more human-readable,
rooting any concerns in user-visible behavior when appropriate, and comparing
the new behavior to old behavior so that PR authors can make a determination of
whether they want to accept or reject the feedback.

Signed-off-by: Kris Hicks <khicks@nvidia.com>

Author: krishicks

.agents/skills/review-github-pr/SKILL.md

@@ -102,15 +102,38 @@ Read through the full diff (and the PR description if available). Produce a summ
 <short fenced code snippets that illustrate the most important changes -- max 3 snippets>
 
 ### Potential Concerns  <- omit if none
-- <risk or issue worth discussing>
+- **<concise user-visible behavior>** — Before this PR, <affected persona>
+  experienced <previous behavior>. With this PR, <new concerning behavior>, so
+  <user-visible impact>. Details: `<file>:<line>`.
 ```
 
 **Guidelines for the summary:**
 
 - **Overview**: State what changed and why. Pull context from the PR description if available.
 - **Key Design Decisions**: Focus on _why_ something was done a particular way, not _what_ changed. Include `file_path:line_number` references. Examples: choice of algorithm, new abstraction introduced, API contract change, migration strategy.
 - **Notable Code**: Include only the most instructive or surprising snippets. Keep each snippet under 15 lines. Always include the file path above the code block.
-- **Potential Concerns**: Only include if there are genuine risks — missing error handling, breaking changes, performance implications, security issues. Do not fabricate concerns.
+- **Potential Concerns**: Only include genuine risks that warrant a change or a
+  deliberate accept/reject decision. Describe each concern in terms of observable
+  behavior for the affected persona, such as a sandbox creator, sandbox user,
+  operator, administrator, SDK consumer, or developer maintaining the system.
+  Always compare the previous behavior with the new concerning behavior and state
+  the resulting user-visible impact. Prefer the compact form: "Before this PR,
+  `<persona>` experienced `<old behavior>`. With this PR, `<new behavior>`, so
+  `<impact>`." Add only the minimum file and line references needed to substantiate
+  the finding.
+  - Use the PR base as the normal previous-behavior baseline. Review older history
+    only when the change is fixing or extending an earlier feature and that history
+    is necessary to explain the behavioral contract. In that case, describe the
+    relevant transitions explicitly: "Before `<commit>`, ... After `<commit>`, ...
+    With this PR, ...".
+  - Translate internal failure modes and race conditions into what the affected
+    person would observe. Internal implementation details belong in the trailing
+    file and line references, not in place of the behavior description.
+  - Do not assign P0/P1/P2 or similar priority labels. The behavioral comparison
+    and impact should give maintainers enough context to accept or reject the
+    suggested change.
+  - Do not fabricate concerns or claim a behavioral regression without evidence
+    for both the prior and proposed behavior.
 - **Agent infrastructure**: When the PR changes behavior, commands, or development workflows, use the `sync-agent-infra` maintenance map to check that related skills were updated. When it adds, removes, or renames skills or crates; changes workflow relationships or skill coverage; modifies issue or PR templates; or changes agent cross-references, apply the full consistency checklist. Report missing companion updates or drift under **Potential Concerns**.
 
 ## Step 5: Output