explanation-guidance

Project Context

• personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
• project .han/config.md: !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.

Explanation Guidance

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.

When this standard applies

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.

Step 1: Read the standard

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.