Change Explainer

Teach a cold reader: assume they know ordinary programming and Git, but not the project or document's purpose, domain, architecture, vocabulary, or layout. Let an explicit statement of reader background override that default.

Build the explanation as a scaffold:

whole → area → concrete problem → change → mechanism

Teach the system change rather than language syntax, patch mechanics, or every edited line.

Output contract

• Return the complete explanation directly in the final response using Markdown.
• Do not create, save, or open an HTML page, Markdown document, diagram file, .change-explainer/ directory, or any other explanation artifact.
• Keep the workflow read-only. Invocation of this skill authorizes inspection, not edits to the repository or documents being compared.
• Do not mention the lack of an artifact unless it resolves ambiguity in the user's request.
• Use headings, bullets, tables, short code excerpts, or a compact text diagram only when they improve comprehension. Do not emit raw HTML or depend on collapsible UI.

Explanation principles