docs: add PR description conventions to CLAUDE.md and git-workflow

Author: Quenty

CLAUDE.md

@@ -70,6 +70,7 @@ When fetching web pages for API documentation, only fetch from official Roblox d
 - **Moonwave docstrings**: `--[=[ @class ClassName ]=]` at the top of each file
 - **Strict typing**: Use dot syntax with explicit `self` for methods. See `docs/conventions/luau.md` for full patterns.
 - **Conventional commits**: `feat(scope):`, `fix(scope):`, `chore(scope):`. Messages describe impact, not reasoning.
+- **PR descriptions**: 1-3 plain sentences describing what changed from the user's perspective. No markdown headers, checklists, or badges. See `docs/conventions/git-workflow.md`.
 - **No co-authorship**: Do not include `Co-Authored-By` on Nevermore commits (open source repo).
 - **Squash before pushing**: Use `git rebase -i` to craft clean commit history. See `docs/conventions/git-workflow.md` for full guide.
 - **`:: any` casts**: Used sparingly at boundaries. Prefer fixing upstream types over casting.

docs/conventions/git-workflow.md

@@ -58,25 +58,14 @@ PR descriptions are for reviewers and future readers browsing git history. They
 **Good** — says what changed from the user's perspective:
 
 ```
-Test and deploy results now appear on the GitHub Actions run summary
-page in addition to PR comments.
+Test and deploy results now appear on the GitHub Actions run summary page in addition to PR comments.
 
-Also reorganizes the GitHub reporter code into `reporting/github/`
-with shared formatting and a separate API module.
+Also reorganizes the GitHub reporter code into `reporting/github/` with shared formatting and a separate API module.
 ```
 
-**Bad** — restates the diff:
+Keep descriptions to 1-3 sentences of plain prose. No markdown headers, checklists, or "generated by" badges. If a PR needs a long explanation, that's usually a sign it should be split up.
 
-```
-- Add `GithubJobSummaryReporter` that writes batch test/deploy results
-  to `$GITHUB_STEP_SUMMARY`
-- Refactor GitHub reporter code into a `reporting/github/` subfolder
-  with shared formatting extracted into `formatting.ts`
-- Wire up the new reporter in `batch test`, `batch deploy`, and
-  `post-test-results` commands
-```
-
-Keep descriptions to 1-3 sentences. If a PR needs a long explanation, that's usually a sign it should be split up.
+The best PRs include a demo — a screenshot or short video showing the change in action. This is especially valuable for UI changes, new CLI output, or CI improvements where the effect isn't obvious from code alone.
 
 ## Branching