Describe a pull request

Turn the actual change into a reviewer map: why it exists, what users gain, how the implementation works, where risk lives, and how to verify it. An explicit invocation authorizes creating or updating the task's pull request; repository git-safety rules still govern commits and pushes.

1. Resolve the target and preserve the worktree

Read PR targeting and diff acquisition, then follow its decision table.

Capture the repository, PR number and URL, state, base and head refs, current branch/worktree state, and output diff mode. Prefer an explicitly supplied PR. Otherwise use the current branch's PR or create one from clearly task-owned work during this step. Ask the user to select a target only at the ambiguity branch defined in the reference.

This step is complete only when one PR target is unambiguous, every task-owned change is included, unrelated changes remain untouched, and the exact diff source is recorded.

2. Build an evidence ledger

Collect PR and repository metadata, the complete changed-file inventory, additions/deletions, commits, and the complete diff. Read enough surrounding code to identify ownership and runtime effects; account explicitly for binary files, generated files, submodules, renames, and patches omitted by GitHub. Read the ticket and task artifacts when present, and derive the task slug and ticket link from evidence rather than naming guesses alone.

Record evidence for: