Update contributing.md and pr template to include manual testing instructions (#10286)

Author: seemeroland

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

@@ -1,10 +1,10 @@
 ---
 name: review-pr-local
 specializes: review-pr
-description: Repo-specific review guidance for warp-external. Only the categories declared overridable by the core review-pr skill may be specialized here.
+description: Repo-specific review guidance for warp. Only the categories declared overridable by the core review-pr skill may be specialized here.
 ---
 
-# Repo-specific review guidance for `warp-external`
+# Repo-specific review guidance for `warp`
 
 This file is a companion to the core `review-pr` skill. It does not
 redefine the review output schema, severity labels, safety rules, or
@@ -22,13 +22,13 @@ 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
+## Behavioral or 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://user-images.githubusercontent.com/...`), 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 change is behavioral or UI-impacting and no screenshots or videos are attached in the description or comments, and the PR description does not justify why there was no manual testing, add an inline or summary-level comment requesting manual testing and evidence. Use wording such as: "Manual testing is required for changes that can be manually tested. Please include screenshots or a screen recording that show it working end to end, or justify why manual testing is not possible."
+- When required visual evidence is missing for a behavioral or UI-impacting change that can be manually tested, 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

.github/pull_request_template.md

@@ -8,14 +8,20 @@ Link the GitHub issue this PR addresses. Before opening this PR, please confirm:
 - [ ] The linked issue is labeled `ready-to-spec` or `ready-to-implement`.
 - [ ] Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).
 
-## Screenshots / Videos
-<!-- Attach screenshots or a short video demonstrating the change, where appropriate. Remove this section if it is not relevant to your PR. -->
-
 ## Testing
 <!--
 How did you test this change? What automated tests did you add? If you didn't add any new tests, what's your justification for not adding any?
+
+Manual testing is required for changes that can be manually tested, and almost all changes can be manually tested. If your change can be manually tested, please include screenshots or a screen recording that show it working end to end. 
+
+You can run the app locally using `./script/run` - see WARP.md for more details on how to get set up. 
 -->
 
+- [ ] I have manually tested my changes locally with `./script/run`
+
+### Screenshots / Videos
+<!-- Attach screenshots or a short video demonstrating the change, where appropriate. Remove this section if it is not relevant to your PR. -->
+
 ## Agent Mode
 - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode
 

CONTRIBUTING.md

@@ -140,11 +140,17 @@ cargo run            # build and run Warp
 
 Tests are required for most code changes:
 
+### Manual Testing
+Manual testing is required for changes that can be manually tested, and almost all changes can be manually tested. If your change can be manually tested, please include screenshots or a screen recording that show it working end to end in the PR description. 
+
+You can run the app locally using `./script/run` - see [WARP.md](WARP.md) for more details on how to get set up.
+
+### Automated Tests
 - **Bug fixes** should include a regression test that would have caught the bug.
 - **Algorithmic or non-trivial logic** needs unit tests.
 - **User-facing flows** should have end-to-end coverage under [`crates/integration/`](crates/integration/) whenever the behavior can be exercised that way. The bar is high-quality coverage of the changes you ship — with agent-driven development the expectation is more integration tests, not just coverage of P0 paths. If a flow is worth shipping, it's usually worth an integration test.
 
-Run unit tests with `cargo nextest run`. See [WARP.md](WARP.md) for more detail.
+Run unit tests with `cargo nextest run`.
 
 ## Code Style