Change Explainer

Teach the change, not just the patch mechanics.

The goal is to help a reviewer or maintainer understand:

• what problem or purpose the change seems to address
• what changed at the design, responsibility, or contract level
• what the relevant part of the system now does after the change
• how the important edits fit together into one technical decision
• how control flow, data flow, ownership, or contracts changed
• what tradeoffs, risks, or maintenance consequences matter
• what mental model the reader should carry forward

This is primarily an explanatory skill, not an implementer tutorial. Do not explain syntax, line-by-line execution, or how to write the code unless the user explicitly asks. Do not turn it into a formal code review by default. Offer opinions only when the change appears to introduce a material issue or an important tradeoff the user should know about.

First-Class Inputs