explain-back — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited explain-back (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
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.
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.
State, in one sentence, what this code is supposed to do — from the requirement, the PR title, or the conversation. Do not look at the implementation yet. This is the contract you'll check the code against.
"This function is supposed to deduplicate incoming webhook events so we never process the same payment twice."
Walk the code in small chunks. For each chunk, say in plain language:
Use no jargon the human hasn't used first. If you cannot explain why a chunk exists — only what it does — flag it explicitly as UNJUSTIFIED. Unjustified code is the #1 source of silent bugs and is the highest-value thing this skill finds. If an UNJUSTIFIED chunk turns out to have no callers or no observable effect, hand it to delete-this; if the explanation keeps stumbling over what something is called, route the fix to name-things.
Scale depth to risk, not line count. On a large diff, chunk at the function level and drop to line-level only where the assumptions concentrate — state changes, boundaries, error paths, anything touching money or auth. An explanation nobody reads defeats the skill exactly the way "looks good" does.
List every assumption the code depends on that is not enforced in the code itself:
event.id is always present" — is it?Each unenforced assumption is a kill-risk. Rank them.
Compare the explanation (steps 2–3) against the intent (step 1). Call out exactly where they diverge:
Present the explanation to the human and ask them to restate the intent in their own words — not a yes/no. "Is this right?" invites a lazy "yep"; "In one line, what did you expect this to do?" surfaces the mismatch.
Running unattended (no human in the loop)? Do not silently proceed. Emit the full explanation, the ranked ASSUMPTIONS, and any UNJUSTIFIED or DIVERGENCE findings as an explicit, logged block, and treat each unconfirmed high-risk assumption as a blocker to flag — not something to wave through. The point of the skill survives without a human: the gap still gets written down where the next reader will see it.
Do not propose a fix until the model is confirmed. A fix built on a wrong model is just a faster bug.
If a CONTEXT.md exists at the repo root, explain in its vocabulary — translate the code into the project's real domain nouns, not generic ones.
INTENT
<one sentence: what this is supposed to do>
EXPLANATION
[chunk 1] what / why / breaks-if-wrong
[chunk 2] ...
UNJUSTIFIED: <any code whose "why" you cannot state>
ASSUMPTIONS (ranked by risk)
1. <assumption> — enforced? <yes/no/where>
2. ...
DIVERGENCE FROM INTENT
<does more / does less / does different — be specific with line refs>
CONFIRM
"In one line, what did you expect this to do?" (restate, don't yes/no)| Anti-Pattern | Why it defeats the skill |
|---|---|
| Explaining what without why | "It calls .filter()" is narration, not understanding. The value is in the why. |
| Using the code's own vocabulary to explain the code | Circular. Translate into the domain, not back into the syntax. |
| Skipping straight to a fix | A fix on an unconfirmed model is a faster bug. Confirm first. |
| Accepting "looks good" as confirmation | The human must restate the intent in their own words, or it isn't confirmed. |
| Marking everything justified | If nothing is UNJUSTIFIED, you probably didn't look hard. Most real diffs have at least one. |
Code you can't explain back is code you don't own yet. Explain it back until you do — before you trust it, not after it breaks.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.