pr: explain each change as the user and owner experience it, and ask the author to confirm, not to author #69

Kind

Change to a skill

Component

pr (skill)

Experience

• Operator (the person running /freethinking:pr): for every group of changes they must write five answers, why, what it does not cover, what would break it, what was run, what a reviewer should question, and the skill is forbidden from drafting any of them. On a seven-group branch they stopped after two. It reads as being grilled, and the walkthrough gets skipped or answered with "trivial, no other questions".
• Owner (accountable for the branch): the walkthrough exists so they can speak to every change. Delivered as writing effort, it gets skimmed or opted out of, so the branch merges with less scrutiny than a read-and-confirm would have given.
• User (who reads the pull request and the merged history): bullets written in the author's shorthand under time pressure, or "Reason not provided by the author".

Motivating case

On plugin 0.5.1 to 0.15.0, 2026-10-08 to 2026-10-22, this repository and freethinkingit/inline-email:

• 2026-10-08: the author chose their own words over a grouped form ("we just go through the changes and I can describe them"). That became the five prompts.
• "pause - what do you mean the PR is left out?" (2026-10-16, 0.9.0), after a group's "what changed" ran to a paragraph of mechanism and was followed by the five prompts.
• "As the admin idk if I want to go through the Pr skill. I have to tweak this skill. it's too cumbersom now" (2026-10-19, 0.14.0), stopping after two of seven groups.
• "fixing image bugs. very trivial not other questions" (2026-10-21, 0.14.0) and "I just bumped the version it shouldn't be a big PR thing. we forgot to do it" (2026-10-22, 0.15.0).
• On the two spec branches since ([#47] Show each spec document as its path and a summary #49, [#50] Add strategy, hld and lld skills with a document reviewer #53), the author accepted a description drafted from the spec and the reports and shown in full, with one prose round for what those did not answer.

What the skill says today

skills/pr/SKILL.md: "An option the skill wrote is the skill's words, and the author is accountable only for words they wrote themselves, so the review prompts take no pre-filled answers." and "Do not propose an answer to any prompt: a reason you inferred from the diff, the commit messages or the ticket is not the author's, and the bullet has to be."

That sentence is the cause. #55 sizes the walkthrough to the change and #45 shortens it for a branch built from a ticked spec; neither changes it. This issue changes the premise, so it is decided on its own rather than folded into either.

Proposed behaviour

1. For each group, the skill writes the explanation itself, from the diff, the commits, the ticket, and the spec and reports where there are any: what changes for whoever uses the software (the user), what the owner now takes on (what it does not cover, what would break it, any risk on rollout), and what was run with the result. Mechanism comes after effect, as Explain problems and decisions as the operator, user and owner experience them #56 asks.
2. Then one question in prose: confirm, correct, or add. The author's confirmation is the accountability; a correction replaces the skill's words; "ask me the prompts" brings back the five for that group.
3. Where the skill cannot infer a why, it says so and asks that one prompt only. A why the author then declines to give keeps today's "Reason not provided by the author" marker.
4. The description says which bullets the author wrote and which they confirmed, in one line under Notes for reviewers, so a reviewer knows what kind of accountability each carries.
5. The two offers, the Closes question and the approval keep their shape.

Done when

An eval case under evals/skills/pr/ gives a branch with two groups and a ticket, and its graders confirm the first walkthrough message explains the first group by its effect on the user and the owner before the mechanism, asks one confirm-or-correct question, and does not list the five prompts; and a second case, with a change whose why the diff and ticket cannot give, confirms the skill asks that one prompt and keeps the marker when the author declines. The existing pr cases still pass.

Related: #45, #55, #56.