docs(skills): require screenshots or videos for UI-impacting PRs (#9701)

## Description
Updates the `review-pr-local` skill so the PR review agent analyzes the
PR description and comments for screenshots and videos when the change
is UI-impacting. If visual evidence is missing for a user-visible
change, the agent should ask for it (e.g. _"For faster review, please
upload screenshots or a video of the feature working end to end."_) and
treat the review as `Request changes`.

This addresses the Slack thread asking the agent itself to request
visual evidence on UI-impacting PRs and to make it (effectively)
blocking.

This is a new version of #9650, rebased on the current master branch.

## Linked Issue
- [x] N/A — skill-only change.

## Screenshots / Videos
N/A — docs-only change to a skill markdown file.

## Testing
Reviewed the rendered markdown locally; no code changes.

## Agent Mode
- [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode

_Conversation:
https://staging.warp.dev/conversation/ab81ec4d-60dc-4d12-a95e-51edfe581e0c_
_Run:
https://oz.staging.warp.dev/runs/019de151-a557-712a-ac02-58a8d4fb90ec_

_This PR was generated with [Oz](https://warp.dev/oz)._

Co-authored-by: Oz <oz-agent@warp.dev>

Author: captainsafia

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

@@ -22,6 +22,15 @@ skill marks as overridable.
 - In WarpUI code, flag inline `MouseStateHandle::default()` usage during render or event handling. Mouse state handles should be created during construction and then cloned/referenced where needed.
 - For user-facing UI changes, mention missing validation only when it is tied to a concrete risk or when the PR changes behavior that should be verified visually.
 
+## UI-impacting changes require visual evidence
+
+- If the PR changes anything user-visible (UI components, layout, styling, copy in surfaces users see, terminal/Warp app visuals, or other behavior a user can perceive), analyze both `pr_description.txt` and any PR comments available in the workflow context for attached screenshots, GIFs, or videos demonstrating the change end to end.
+  - Treat markdown image/video embeds (`![...](...)`, `<img ...>`, `<video ...>`), GitHub user-attachment links (e.g. `https://github.com/user-attachments/...`, `https://github.com/__user-images/...`), Loom links, and similar hosted media as valid evidence.
+  - The `Screenshots / Videos` section from `.github/pull_request_template.md` being present but empty does not count as evidence.
+- If the change is UI-impacting and no screenshots or videos are attached in the description or comments, add an inline or summary-level comment requesting them. Use wording such as: "For faster review, please upload screenshots or a video of the feature working end to end."
+- When required visual evidence is missing for a UI-impacting change, set the final recommendation in `summary` to `Request changes`, even if no other blocking issues were found. Call this out explicitly in the `## Verdict` section.
+- If the PR is clearly not user-visible (pure refactor, internal tooling, build scripts, server-only logic with no UI surface, tests, docs-only), do not request screenshots or videos.
+
 ## User-facing strings
 
 - Flag interpolated text that would read unnaturally at runtime or combine sentence fragments with the wrong casing.