Explain Change

Help the owner of a completed change genuinely understand it before merging. Present an explainer of what the system now observably does differently; that explainer is the deliverable. The quiz is an optional mechanism on top — a misunderstanding detector, not a mastery gate: its only job is to surface missing or wrong understanding fast and cheaply.

Boundaries

• Explain only. Never judge code quality, never edit code or comments, never run the code.
• If something looks buggy or suspicious while reading, note the observation in one line and suggest a code review; do not develop it into review findings.
• If confusion stems from unclear code rather than from the change itself, say so and suggest a documentation or simplification pass; do not fix the code here.
• If the user wants proof the change works, suggest runtime verification; this skill checks the user's understanding, not the code's correctness.

Workflow

1. Resolve the target diff. The diff is the ground truth.
   • Default to the current branch plus working tree against its merge base with the default branch.
   • Accept an explicit commit range, PR, staged changes, or file set when the user names one.
   • If the resolved diff is empty, report that there is nothing to explain and stop.