pr skill: body can faithfully describe a scope the branch doesn't have (branch ancestry contamination)

## The failure Real-world case (a 70-commit feature merge that shipped under a docs-only MR): 1. An agent cut a delivery branch (`docs/...`) with `git switch -c` **from a feature branch** instead of from the target branch. 2. The branch's *working-tree* changes were 8 docs files — but its *commit ancestry* carried the feature branch's entire history (60+ code commits). 3. The agent verified scope with `git status` / `git add -u` (working-tree view), never ran a diff against the target branch. 4. The PR body — written with this skill — accurately described the 8 docs files. The PR's actual diff against the target was 70 files including all feature code. 5. The human reviewed the body (not the Commits tab), merged, and the whole feature landed on the target branch under a docs MR. The skill's Evidence section covers *does the change work*; nothing covers *does the body describe what the diff actually is*. The gap sits between `pr` (document format) and guardrail-style skills (destructive-command blocking): branch ancestry contamination is caught by neither. ## Suggested fix Add a small scope-check step to the pr skill: before writing the body, derive the description from the branch's actual delivery against the target branch: ```bash git log ..HEAD --oneline # commits this PR will carry git diff ...HEAD --stat # files this PR will change ``` The Summary's file tree / commit list must come from these outputs, not from memory of what was changed. If either includes work outside the current task, the branch base is contaminated — recreate the branch from ` ` before writing anything. Happy to send a PR with this as a short `### Scope check` section if you think it fits.