Pull Request Briefing

Build the briefing from the current PR, full diff, linked context, checks, and review conversation. Do not treat the description as verified implementation. Resolve the exact host, owner, repository, and PR number from the user's URL or an unambiguous local remote before querying; never rely on the number alone.

Read relevant artifacts on linked issues through vp-github when they contain requirements, design decisions, or verification evidence. Retain the artifact version and source revision when relevant; compare plans and claims with the current diff and checks. A PR cannot own an issue artifact directly. Mark an inaccessible artifact as missing context without inventing its contents or expanding access.

Apply vp-clear-writing to the briefing. Use vp-design-reasoning when a behavior model or trade-off needs explanation; choose a decision tree for conditional behavior, a flow for handoffs, or a table for comparisons only when it helps answer the reader's question. Keep the problem, result, material risks, evidence limits, and next action understandable without opening links.