explain-backlisted

# Explain Back ## The failure mode this fixes The most expensive bug in AI-assisted development isn't wrong code — it's code that *looks* right that nobody understands. The agent writes 80 lines, the human skims, says "looks good," and merges. Six weeks later it breaks and no one — human or agent — can say why it existed. `explain-back` inverts review. Before code is trusted, the agent must explain it back in plain language until the human confirms the model is correct. If the agent can't explain a line, that line is suspect. If the human can't follow the explanation, the code is too clever. Either way, you find out *now*, not at 3am. ## When to Use This Skill - Right after you (the agent) generate a non-trivial change, before declaring it done - When reviewing code an agent wrote and the diff "looks fine" but no one built a model of it - When onboarding to an unfamiliar file before changing it - When the human catches themselves about to approve something they can't explain - Before building new logic on top of existing code whose behavior is assumed, not known **Don't use when:** the change is a trivial rename, a config value, or a one-line typo fix. Reserve it for logic that someone will later have to reason about. ## Instructions Work through these phases in order. Do not skip to a fix or a "looks good" — the whole point is to surface the gap between what the code says and what everyone *thinks* it says. ### 1. Restate the intent (before reading the code closely)