explainlisted

# Explain for a non-technical reader Turn a technical outcome into an explanation that a smart, non-technical reader can follow: a customer, a business partner, or a future reader who has forgotten the details. This workflow is read-only: it explains. It never edits, fixes, reviews, or re-runs anything. Do the work in the current task rather than delegating it. The outcome being explained lives in this task's conversation, and a delegate started from a fresh brief cannot see it. ## Resolve the subject Take the subject, the intended reader and any length limit from the user's invocation. If no subject is supplied, use the most recent substantive outcome in the current task: the last review report, plan edit, set of code changes, command output, test run or error. If the task contains nothing to explain yet, ask what to explain and wait; do not pick a file, a recent commit or the repository itself as a stand-in. If the invocation names a path that does not exist or cannot be read, say exactly that and stop. Do not substitute a similarly named file, and do not silently fall back to the previous outcome. If the subject is ambiguous, state the assumption in one line before the explanation and proceed. Explain only the named subject: unrelated uncommitted edits, other commits and other files are excluded. Scope any diff to the subject's paths or commits; if they cannot be separated, say which parts were included and why. ## Ground the explanation in the artefact Before writ