explain-change
Explain Change
Give the user an evidence-backed mental model. Stay read-only for explanation- only work; a walkthrough is not permission to fix or publish.
Resolve the base, head, and scope. Refresh evidence for a named PR; include relevant committed and working-tree changes for a local request. Ask only when competing scopes would materially change the answer.
Read the diff and enough entrypoints, callers, tests, and decision records to explain old and new behavior. Consult intent when rationale or a boundary matters, not as a mandatory repository tour. Accepted decisions govern within host permissions and explicit safety constraints; verify PR descriptions and handoffs.
Lead with changes for the user, developer, or operator. Group files conceptually and use an example when it clarifies behavior. Explain material contract, data, ownership, failure, compatibility, and operational consequences; omit irrelevant surfaces unless asked about them.