Install any skill in seconds. Free to start, no credit card required.
Get Started Free →testdouble/explanation-guidance
Surfaces Han's shared standard for explaining technical work to a reader who will not implement it into the calling skill's own context, so the caller writes its escalations, confirmation turns, and stops as a concrete outcome the reader could observe rather than as a mechanism.
Passed 2 of 9 test cases with the skill, and 3 of 9 without it.
2 fixed3 passed either way12 still failing5 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are starting the migration of legacy customer accounts to the new single sign-on system. Send an opening confirmation message to the project sponsor before we begin execution.
| Checked | Without skill | With skill |
|---|---|---|
| The message confirms the project start by focusing on what users will experience during single sign-on migration. | Missed | Passed |
| The message avoids technical database migration syntax in favor of observable migration milestones. | Passed | Passed |
The instructions your model reads when the skill loads.
bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"cat .han/config.md 2>/dev/null || echo ""As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read
that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md
probe supplies content, apply it per config-rule.md, which governs precedence
between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
You have invoked explanation-guidance to source the shared explanation standard before you talk to a person. This skill
surfaces the standard into your own context and hands control back. It is a means to writing your turn, not the turn
itself: apply what it surfaces, then RETURN to the workflow that called you and finish it.
This skill is inline — it runs in your context, not an isolated one, so the standard it surfaces stays available to you after it returns. Do not treat anything here as a stopping point or a final answer.
It applies to what you say to a person in a turn: an escalation, an opening confirmation turn, a stop for a missing input, or any explanation of a technical consequence to someone who will not implement the work.
It does not apply to the written deliverable you are producing. That is governed by the readability standard, which you
source through han-communication:readability-guidance. A run often needs both, at different moments.
Read ${CLAUDE_PLUGIN_ROOT}/references/explanation-rule.md so its full content enters your context. It carries the
concrete-outcome requirement, the four-part form for a question shaped like data entry, the unintroduced-term test, and
the rule that the consequence comes before the technical detail.
Do not paraphrase or summarize the file in place of reading it. The surfaced content is the point.
Write for a reader who knows the product and will not open the code. Name something they could observe. Put paths, identifiers, and line numbers below the question, or leave them out.
test cases passed, vs 3 / 9 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.