Add pr-context-synthesis skill

[AryanGodara]

What this is

A primitive for producing a tight 1–3 paragraph what / why / how synthesis of a single PR (or PR-shaped change). Stays anchored to the actual diff and refuses vague verbs.

Ships with /pr-synthesis <N|owner/repo#N|url>, a slash command that fetches title, body, linked issue, and diff and prints the synthesis verbatim.

Why split out

Extracted from #4351 because the synthesis primitive is reusable beyond a single review report — incident-investigation skills like pr-blame-walk need the same shape per candidate. Splitting keeps the contract small.

Files

• docs/skills/pr-context-synthesis.md — rules + output shape.
• .claude/commands/pr-synthesis.md — slash command wrapping the procedure.

Reviewing this in isolation

The skill body is self-contained — see the new "How to invoke" and "Example" sections. The intro names two consumers (/review-pr and pr-blame-walk); both land with #4351, so those links resolve once that PR merges. Rules and Shape stand on their own.

How to try it

/pr-synthesis 4371

Worked sample output (run against the real PR #4371) is in the skill file's Example section.

[gemini-code-assist]

Code Review

This pull request introduces a new Claude command for PR synthesis and a corresponding skill definition. The changes establish a structured process for generating concise summaries of pull requests by fetching data from GitHub. Feedback highlights a brittle approach to identifying linked issues, suggesting the use of GitHub's native API fields instead. Additionally, a contradiction was identified between the command's behavior and the skill's rules regarding how to handle drift between the PR description and the actual diff.

[gemini-code-assist]

Manually parsing the PR body for linked issues using keywords like Fixes #N is brittle. A more robust approach is to leverage GitHub's built-in issue linking by using the closingIssuesReferences field from the gh pr view API. This ensures you are using the same mechanism that GitHub uses to link PRs and issues.

To implement this, you'll need to add closingIssuesReferences to the --json fields in the gh pr view call on line 32. Then, you can iterate over the structured data to get issue details.

Suggested change

	Parse the PR body for `Fixes #N` / `Closes #N` / `Resolves #N` (case-insensitive) and fetch each linked issue:
	```bash
	gh issue view <N> -R <owner>/<repo> --json title,body,labels,state
	```
	gh issue view <issue.number> -R <issue.repository.owner>/<issue.repository.name> --json title,body,labels,state

[gemini-code-assist]

There is a contradiction between this rule and the implementation described in .claude/commands/pr-synthesis.md.

This file says to raise a finding with Action: update the PR description....
However, .claude/commands/pr-synthesis.md (line 57) states that in case of a drift, the skill should note it in the synthesis as "description claims X; diff shows Y".

The latter seems more appropriate for a synthesis skill, which should report facts rather than take actions. The consumer of the synthesis can then decide whether to raise a finding. I recommend aligning this rule with the implementation.

Suggested change

	2. **Watch for description-vs-diff drift.** `<pr_text>` must describe `<diff_summary>`'s *current* state, not the author's iteration history. If a claim is no longer true of the diff, raise a finding with `Action: update the PR description to match the current diff`. Do **not** flag the absence of a changelog of removed/superseded behaviour — that belongs in commit history, not the description.
	2. Watch for description-vs-diff drift. <pr_text> must describe <diff_summary>'s current state, not the author's iteration history. If a claim is no longer true of the diff, note it in the synthesis (e.g., "description claims X; diff shows Y"). Do not flag the absence of a changelog of removed/superseded behaviour — that belongs in commit history, not the description.